Re: [BUG] bpf, lsm: new first argument in 7.4 inode hooks silently breaks BPF LSMs

[Paul Moore]

On Thu, Nov 12, 2026 at 6:00 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
> On Mon, Nov 9, 2026 at 7:08 AM roblabla <linux@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > Thanks for the replies!
> >
> > > LSMs that need to provide a stable API must provide an abstraction
> > > layer between the LSM hook callbacks and their stable API.  The LSM
> > > framework is not responsible for the stability of individual LSM APIs.
> >
> > Understood, that lines up with my expectations. I think the biggest
> > thing here would not necessarily be stability guarantees, but rather to
> > make sure that the eBPFs fail to load when the compatibility is broken.
> > But that's probably a problem for the eBPF side, and not LSM, I assume.
> >
> > > So, in short, would it be possible to send a follow up to Daan's
> > > commit and move `struct mnt_idmap *idmap` to the end of LSM argument
> > > list?
> >
> > If this is possible, that'd be nice so that we avoid this breakage in
> > the short term, since the change isn't in a released kernel yet.
>
> can you please send a patch proposing that and we can continue
> discussion there? please cc me so I can follow along

Considering the original patch was submitted, reviewed, and merged
with the BPF LSM being the only user (none of the existing in-tree
LSMs use the idmap parameter at present), I'm a little surprised this
wasn't brought up earlier.

Beyond that, from a style perspective, I think I prefer the idmap at
the front of the parameter list in most (all?) of the hooks where it
was added.  I'm not interested in moving it at this point in time.

-- 
paul-moore.com