From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=185.125.25.12 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792521486; b=0YIxVVVtUT3ZYJErwmiqtj5PhGgu4lw1LJ4KI/NpVjCGbzRoqZiwCiKRxwqZSMzVAh5M D1gzKnBeFqhgLn3AGwRXLKbbciz4r3aOKUtQXQumaHQC2kJXSzDxbHwvPo8b2aNaw0Xgc ZYOivg8kX2ethnYqfjkWQ4P2RmGte2tNGKRmLe6mqKpYhtisg8Cd0KEq6yCiaIH2nKtLO 038/NP9QsaovOPxdW2SVbxfFbCsOD7sbaSDSuUkkhmkYNWnGcJ5zMvLjpXgIJWhvAbKbD aXU37VQgdVfyd/XQ913TfuXqgJpskFyuh7D882OGkhJACesK004wepxvXxaOEyamr1Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792521486; h=DMARC-Filter:Received:DKIM-Signature:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:In-Reply-To: X-Infomaniak-Routing; bh=Pr5tsmnntCf16xoQZruQvjUzk9vMB//UroElAOAsHX4=; b=zDsFUKSu2GOY4WXtkpHSJiyDIMFDfxgcLRG5zMj75o1YlKAwFz/2pDR74pdzeOHR1zuB Ts0v3fo4FXpggPUWh18PZ6DrUJcZtSWrHFjUGM5Wv+ztGs7BhXmL1lwJB3qOCKBVjbCxA JpCVXO19rRYogC+d5ZHfAnYbM3ZXg7WMPLBaEyrbeQq9Tg7H5VSWoCXUxsCpzggBPytaY aYnmCbpE8fYvjx+sQ+8EBguYZoLaT/M8UL8hUqgvNk6ocI1hdaDTQ97/tv1ceuUM1w2eh lsHTXKJOe/yf3VK0y6DXGf0OHxK8n6ndDVrih4h6juMuYS9F0m9C9Ll/Dt7AAFHdTNg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass header.d=digikod.net header.i=@digikod.net header.a=rsa-sha256 header.s=20191114 header.b=yMdKCsMo; arc=none smtp.remote-ip=185.125.25.12 Received: from smtp-190c.mail.infomaniak.ch (smtp-190c.mail.infomaniak.ch [185.125.25.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF194606A31B for ; Tue, 20 Oct 2026 18:38:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BF194606A31B Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=digikod.net header.i=@digikod.net header.a=rsa-sha256 header.s=20191114 header.b=yMdKCsMo Received: from smtp-3-0001.mail.infomaniak.ch (smtp-3-0001.mail.infomaniak.ch [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4j8Lkw5pMbznjT; Tue, 20 Oct 2026 20:38:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1792521480; bh=Pr5tsmnntCf16xoQZruQvjUzk9vMB//UroElAOAsHX4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=yMdKCsMolUavEVmgMhSTA49ormN3OEV/fDdxYmqsA7HkJHcEwxL/HPA/yAlAw+0iF dmtOdiH0jvq4OUTMreoubhxD7uszI5MrBlsbriJHkXED08zJUO8HpGLFBjDQkh5KSX INXyii7ZadMPi2U+U2FE2AjiSBHRz0+UMrO9R1HA= Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4j8Lkt4K95zMPV; Tue, 20 Oct 2026 20:37:58 +0200 (CEST) Date: Tue, 20 Oct 2026 20:37:57 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Justin Suess Cc: Alexei Starovoitov , Christian Brauner , Alexander Viro , Jan Kara , NeilBrown , Daniel Borkmann , Andrii Nakryiko , Song Liu , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?Q?G=C3=BCnther?= Noack , Paul Moore , James Morris , "Serge E . Hallyn" , Martin KaFai Lau , Eduard Zingerman , Yonghong Song , John Fastabend , Kumar Kartikeya Dwivedi , Jiri Olsa , Jeff Layton , Amir Goldstein , Mateusz Guzik , Shuah Khan , Tingmao Wang Subject: Re: [PATCH bpf-next v1 00/11] fs: unified VFS ancestor walk for Landlock and BPF Message-ID: <20261020.eiP2Kohshahj@digikod.net> References: <20261013164800.2906577-1-utilityemal77@gmail.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Infomaniak-Routing: alpha On Tue, Oct 20, 2026 at 10:05:54AM -0400, Justin Suess wrote: > On Sat, Oct 17, 2026 at 01:02:40AM +0000, Alexei Starovoitov wrote: > > On Tue, Oct 13, 2026 at 12:47 PM Justin Suess wrote: > > > The structure is unchanged from the RFC [2]: a stepwise engine private > > > to namei.c, a callback front-end for in-kernel callers (Landlock > > > is converted, fixing the follow_up() race Al reported, hence the > > > Fixes: tag on patch 3), and open-coded BPF iterators over the engine in > > > referenced and rcu flavors, with bpf_path_ancestors_legitimize() > > > escalating from the latter to the former mid-walk. Patch 1 is carried > > > from Song's series. See the RFC cover for the full background and API > > > listing. > > > > Song's series stopped at > > "It is a conceptual dead-end to expose these two modes via separate APIs > > and leak this implementation detail into non-core code. It will not > > happen as far as I'm concerned." > > VFS_WALK_RCU, -ECHILD to the caller, two bpf iterators and the > > legitimize kfunc are that leak. > Following up on this, plan is I'll submit v2 of the verifier fixes > series and get that finished first. > > Then after that I'll do a redesign around a single iterator > implementation that decides the walk type and abstracts away the details. > It will be KF_RCU_PROTECTED and callers will need to break out of the > loop to do sleepable work. They'll be able to acquire the path > references with a kfunc to take them out of the loop. > > That drops the __uninit iterator changes and the legitimize kfunc as > well. > > > Landlock still passes flags == 0, so nothing in the kernel walks in > > rcu mode. > Mickaël would you be interested in the hybrid walk conversion as part > of this series? Or prefer sleepable walk be retained for now and > converted later? I would prefer a standalone series for VFS and Landlock that also include (with dedicated patches) the RCU optimization proposed by Tingmao. That would prove that it works end-to-end with the RCU optimization, and that would be easier to review and merge. Then a series dedicated to BPF could leverage this work. > > Justin > > Patches 1-3 fix a real race and don't need bpf. > > Send them to Christian, Al and Mickael on their own. > > > > > Verifier fixes propagating the RCU-ness to trusted fields can be done, > > > but it's best as a separate series where the idea can be examined more > > > closely. Then marking the dentry as trusted will allow you to use the > > > dentry xattr kfuncs. Nothing in this series strictly depends on having > > > a trusted dentry, nor will marking it trusted require changes in this > > > API. See my follow up [4]. > > > > Then what can a prog do with a position? > > pos->dentry is untrusted now. > > Marking it trusted will require changes. > > d = pos->dentry is not linked to pos. It will stay trusted after > > bpf_path_put(pos). > > pos of the rcu iterator points into bpf stack. > > MEM_RCU propagation fixes neither. > > What next() should return depends on how the verifier tracks it. > > Let's do the verifier part first. > > > > pw-bot: cr >