Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4201921imw; Tue, 19 Jul 2022 01:45:08 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uNXIGbFhCjESb2Fod27Km9NPB4TeDi4Mb9DZu9EgSXB2i/MQw3ReqiaT/D2HxKmo5yf7Ek X-Received: by 2002:a05:6402:1659:b0:43a:1735:e1ce with SMTP id s25-20020a056402165900b0043a1735e1cemr42931867edx.196.1658220308468; Tue, 19 Jul 2022 01:45:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658220308; cv=none; d=google.com; s=arc-20160816; b=b8w1wP2+BqIgzM+ViVIzLnkteOD1l7DB//b7HYzXUiwkJLsy3G6sacJODxzC/nL30Z rZErGv1F1pb50joVC87UBnVqKL2NtubG0jpVddB+FU0pMO9hexAqeb8hTQ8isldiSDuX 9jj255qlBfi+m5ipB1G0trtkwjOMgYZxZiOlXZedj4g8vkZ7SOO6hm6jmr4huarImQI8 FDcWUH+bDaVwQgSXpwJIZjDNUtlyoUPNIVdZQ0CNqe5qmiD8SKnp7VqCscKqrVgy3BFm yIp7jZhncdpN4t+1FEQoBLi9d43cq7hPjhk8GIJrohqfj2tk2uZWeRAAo07tOPIqfFA/ zpug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/eqc8C2YttlByFBthEIEYCYux1DkeFmhc8p302py+JQ=; b=hx31mNKjsBTOm284YZKM+3iTy8JTd4OhFg+k75vTHV+TThn7k89OyJVUsAlra7/xPx hH4HyC233JkdgXCLxAb99kjuj3snLT8Sk5kHA55aaXrInxUZ09LFP26MOvlupBYwIB/C wY5SAuW8nGu3kbKpVlb2yeAsBBEWKGX+zrytE5doGvuc1b/1kKmcbV8yv4Z05sr97oYb iDNNWmGyaYUw+CGs2tkgkSv8Z+OwbJMPg7KduhwMoR/Xuiya92thKX4U7cekkbb0UVcZ AW9Ng6OSDRTvYtojC8Gly+YxuAd4/cqRh1oqByY9N7bsNXTeANitW5A46ufIDAKDO/6s hFLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=m4e7c+KH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qf2-20020a1709077f0200b0072ee40a72b0si19107108ejc.173.2022.07.19.01.44.43; Tue, 19 Jul 2022 01:45:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=m4e7c+KH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236905AbiGSIep (ORCPT + 99 others); Tue, 19 Jul 2022 04:34:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234753AbiGSIen (ORCPT ); Tue, 19 Jul 2022 04:34:43 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5ED9C3CBD8 for ; Tue, 19 Jul 2022 01:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/eqc8C2YttlByFBthEIEYCYux1DkeFmhc8p302py+JQ=; b=m4e7c+KH4aAqqStqt06zkYNXRY lEXXrmMmM5tlF94gY/d6RGMkSGF41RoifCM34cDAtQ39iXgq/NPwhAbMIz8FtRSSgeyotDsNJISL6 lSoJrVMPI1MbeC5XwDNuS4AOaksDMVipQZTofXUsrN8+BwHsmgvYF0o65otMBhCvNf9xsH8AUe1r9 9PS4wgx+Xcy+OrZOZjJVivtuSCJ5GTKItWn6BUO9UnEOG4jiZ3U8GZoL5vRS7eykrqWTQb4nwBVYs LQUxoRpp2WnPrcywn3AXI97FAJNYUkOBZGp+on0CqplVwii3XSYhh9RQNqDVxcXa6c1VWFVOPGFbA PtFGARUQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDigE-00DT4n-Vc; Tue, 19 Jul 2022 08:34:11 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 1223A9802A7; Tue, 19 Jul 2022 10:34:09 +0200 (CEST) Date: Tue, 19 Jul 2022 10:34:08 +0200 From: Peter Zijlstra To: Alexei Starovoitov Cc: Thomas Gleixner , LKML , X86 ML , Linus Torvalds , Tim Chen , Josh Poimboeuf , Andrew Cooper , Pawan Gupta , Johannes Wikner , Alyssa Milburn , Jann Horn , "H.J. Lu" , Joao Moreira , Joseph Nuzman , Steven Rostedt , Alexei Starovoitov , Daniel Borkmann Subject: Re: [patch 37/38] x86/bpf: Emit call depth accounting if required Message-ID: References: <20220716230344.239749011@linutronix.de> <20220716230954.898341815@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 18, 2022 at 10:30:01PM -0700, Alexei Starovoitov wrote: > On Sat, Jul 16, 2022 at 4:18 PM Thomas Gleixner wrote: > > @@ -1431,19 +1437,26 @@ st: if (is_imm8(insn->off)) > > break; > > > > /* call */ > > - case BPF_JMP | BPF_CALL: > > + case BPF_JMP | BPF_CALL: { > > + int offs; > > + > > func = (u8 *) __bpf_call_base + imm32; > > if (tail_call_reachable) { > > /* mov rax, qword ptr [rbp - rounded_stack_depth - 8] */ > > EMIT3_off32(0x48, 0x8B, 0x85, > > -round_up(bpf_prog->aux->stack_depth, 8) - 8); > > - if (!imm32 || emit_call(&prog, func, image + addrs[i - 1] + 7)) > > + if (!imm32) > > return -EINVAL; > > + offs = 7 + x86_call_depth_emit_accounting(&prog, func); > > It's a bit hard to read all the macro magic in patches 28-30, > but I suspect the asm inside > callthunk_desc.template > that will be emitted here before the call > will do > some math on %rax > movq %rax, PER_CPU_VAR(__x86_call_depth). > > Only %rax register is scratched by the callthunk_desc, right? > If so, it's ok for all cases except this one. > See the comment few lines above > after if (tail_call_reachable) > and commit ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall > handling in JIT") > We use %rax to keep the tail_call count. > The callthunk_desc would need to preserve %rax. > I guess extra push %rax/pop %rax would do it. The accounting template is basically: sarq $5, PER_CPU_VAR(__x86_call_depth) No registeres used (with debugging on it's a few more memops).