Re: [PATCH bpf-next v1 00/11] fs: unified VFS ancestor walk for Landlock and BPF

[Mickaël Salaün]

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 <utilityemal77@xxxxxxxxx> 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
>