From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-226.mta0.migadu.com [91.218.175.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6280343DEC9 for ; Wed, 16 Sep 2026 07:52:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789545168; cv=none; b=Ixe26+wDFMOKrhgjHJl7Zsjdoue+bcmYK1p2GHtwoLj9k7pLgskuBFVo0UTmwW+uljag8+Md8ObObUa+xHJIsQW5KO4QACpjlPYDEWKXUywhOWwgnqM9EOD+c/4JXjuJQAzTcPNMxBHKPhQ49mu3RlMo8g0qT478VNt9/fcAASo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789545168; c=relaxed/simple; bh=AGXORyCsk913kO+VsFSEHaTAWEdeNo95eaqf+tbuC7g=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=pGQhsUpLrweyvyhG6+mkhjZTITDiZqeo6PehYTzhsuQPZTdGa3LDlJFPgIijF9OrKkOEXXoOLbevQdDlivci/ynnMDAlWyGUIZd8awP40WpBjy/ob/5LZIdHY0+icPVw1JyjvrLkvupxygiWRuqLEk0W3H0LXjM5rQk7jrNSxEU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=cWyFe70O; arc=none smtp.client-ip=91.218.175.226 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="cWyFe70O" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=AGXORyCsk913kO+VsFSEHaTAWEdeNo95eaqf+tbuC7g=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789545151; v=1; x=1790149951; b=cWyFe70OeV2xQGvwFQjwL6/lsjhK3XyqtfJ8LfMHNln2rd+f6l5w4FHSIDbsmB5i2lngP09W ALzjCoJo3EM51fC8+cFPdkmfmOhhMzXPDdbfViihDU0d8knX24RPjC8Ydsd8cE1XA98mhCa2dMg w1dNFVdBOTErBCpvmfbOeAzs= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 4d980cb76d01b755; Wed, 16 Sep 2026 07:52:31 +0000 X-Mizu-Trace-ID: 4d980cb76d01b755 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 16 Sep 2026 07:52:26 +0000 Message-Id: From: "Florent Revest" To: "Alexei Starovoitov" Cc: "bpf" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "KP Singh" , "John Fastabend" , "Leon Hwang" , "Junseo Lim" , "Sechang Lim" , "Puranjay Mohan" , "Xu Kuohai" , "Ilya Leoshkevich" , "Hari Bathini" , "Christophe Leroy" , "Naveen N Rao" , =?utf-8?q?Bj=C3=B6rn_T=C3=B6pel?= , "Pu Lehui" , "Tiezhu Yang" , "Hengqi Chen" , "LKML" Subject: Re: [PATCH bpf v2 1/2] bpf: Skip detached progs in trampoline images that are still in use X-Mailer: aerc 0.17.0 References: <20260912095924.866254-1-florent.revest@linux.dev> <20260912095924.866254-2-florent.revest@linux.dev> In-Reply-To: On Wed Sep 16, 2026 at 5:29 AM UTC, Alexei Starovoitov wrote: > On Tue, Sep 15, 2026 at 11:39=E2=80=AFAM Florent Revest > wrote: > > > > > > Ah yeah, I tried to address that in the cover letter. Basically, if we = patch > > all the nops, tasks running in the old image could skip some progs that= are > > still attached. For fexit, that's already what happens with ip_after_ca= ll but > > for fmod_ret it would be new and this would cause for example an LSM pr= og's > > verdict to get skipped when another prog gets attached to the same hook= . That's > > why I thought that patching only the detached prog's nop would be bette= r and > > needed these extra pointers. But it's a bit of an edge case and I don't= have a > > strong opinion on it. > > Hmm. Not sure I agree with your reasoning. > fmod_ret progs are called _before_ orig_call. > So fentry+fmod_ret are in the same category. > Adding/removing a prog to the trampoline causes regeneration > of the trampoline. > So cpus may execute different numbers of progs already. > The race is inevitable. > With 'patch all nops in old tramp' approach the only > additional race is some of the fentry/fmod_ret progs > will get skipped in old tramp. > > If the concern of a tiny window where old tramp is started > to be destroyed, then fentry prog is called and we patched > another fentry, but tramp will continue and execute orig_call, > then, yes, I see the issue, but it's a lot more subtle. > If I understood the concern correctly then let's add > another 'jump over the call' nop in addition to > 'patch nops in front of all progs' and > let's patch 'jump over the call' _first_. > This way fentry/fmod_ret progs can never miss > execution of orig_call. They can be invoked "unncessarily". > They may execute though orig_call will not fire. > but that's an acceptable race. Better than not executing > fmod_ret while letting orig_call to go through. > > This is still simpler implementation than link-list all all extra book ke= eping. My concern wasn't orig_call running but rather progs that are still attache= d getting skipped. Say, fentry progs A and B are attached to a function and a task is sleeping in A. Someone attaches C, the old image gets all its nops patched, the task wakes up and skips B even though B was never detached. But it's a narrow window and it needs an attach/detach on that function to = race with, so if you're OK with that behavior I'll respin v3 with your simpler version.