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

[Justin Suess <utilityemal77@gmail.com>]

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@gmail.com> 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?

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