[PATCH bpf-next 3/4] bpf: Introduce path iterator

Song Liu song at kernel.org
Thu May 29 21:07:31 UTC 2025


On Thu, May 29, 2025 at 1:15 PM Al Viro <viro at zeniv.linux.org.uk> wrote:
>
> On Thu, May 29, 2025 at 12:46:00PM -0700, Song Liu wrote:
>
> > > Basically, you are creating a spot we will need to watch very carefully
> > > from now on.  And the rationale appears to include "so that we could
> > > expose that to random out-of-tree code that decided to call itself LSM",
> > > so pardon me for being rather suspicious about the details.
> >
> > No matter what we call them, these use cases exist, out-of-tree or
> > in-tree, as BPF programs or kernel modules. We are learning from
> > Landlock here, simply because it is probably the best way to achieve
> > this.
>
> If out-of-tree code breaks from something we do kernel-side, it's the
> problem of that out-of-tree code.  You are asking for a considerable
> buy-in, without even bothering to spell out what it is that we are
> supposed to care about supporting.
>
> If you want cooperation, explain what is needed, and do it first, so that
> there's no goalpost shifting afterwards.

We have made it very clear what is needed now: an iterator that iterates
towards the root. This has been discussed in LPC [1] and
LSF/MM/BPF [2].

We don't know what might be needed in the future. That's why nothing
is shared. If the problem is that this code looks extendible, we sure can
remove it for now. But we cannot promise there will never be use cases
that could benefit from a slightly different path iterator. Either way, if we
are adding/changing anything to the path iterator, you will always be
CC'ed. You are always welcome to NAK anything if there is real issue
with the code being developed.

Thanks,
Song


[1] https://lpc.events/event/18/contributions/1940/
[2] https://lwn.net/Articles/1018493/



More information about the Linux-security-module-archive mailing list