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.
It's a leak alright!

The problem I run into is that the RCU walk and refwalk have different
contexts. Currently the KF_RCU_PROTECTED on
bpf_iter_path_ancestors_rcu_new and the KF_SLEEPABLE on
bpf_iter_path_ancestors_new

Unfortunately, if you wanted to make one set of iterator kfuncs for both
APIs you'd have to make the assumption that the inner loop
always runs under the non-sleepable KF_RCU_PROTECTED conditions, the
strictest of the two iteration modes. (KF_RCU_PROTECTED context is stricter subset
of KF_SLEEPABLE context)

So it would just be KF_RCU_PROTECTED regardless of whether it's RCU
walk or refwalk... so no sleepable dentry xattr kfuncs would be
possible.

There's nothing wrong with that (callers can break out of loop and do
sleepable work) but it is a tradeoff. And you couldn't carry the
acquired references to the paths outside the loop.

So I admittedly designed it as two APIs that leak the rcu/ref context,
but share the backend API. (the vfs_walk_* stuff)

Christian do you have any thoughts on this? I agree, as little
RCU/refwalk details should be exposed as possible.

> Landlock still passes flags == 0, so nothing in the kernel walks in
> rcu mode.
> Patches 1-3 fix a real race and don't need bpf.
> Send them to Christian, Al and Mickael on their own.
> 
Will do.

> > 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?
Not a whole lot. bpf_path_d_path maybe.

> 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.
> 
I submitted two verifier fixes earlier here [1] one for the linking
the trusted field lifetime to the parent field and one for the MEM_RCU.

[1] https://lore.kernel.org/bpf/20261014173039.3666415-1-utilityemal77@gmail.com/

Justin
> pw-bot: cr