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

[Alexei Starovoitov]

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.
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.

> 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