Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
"Kumar Kartikeya Dwivedi" <[email protected]> Fri, 31 Jul 2026 17:44:35 +0200
| Newsgroups | org.kernel.vger.linux-integrity,org.kernel.vger.bpf,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-security-module,org.kernel.vger.selinux |
|---|---|
| Message-ID | <[email protected]> |
On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote: > On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Moore <[email protected]>= wrote: >> >> >> Okay, it looks like there was some confusion/misunderstanding. >> >> My understanding of Kumar's comments was that he was referring to the >> exisiting LSM related kfuncs that are located in fs/bpf_fs_kfuncs.c, >> not necessarily the new kfunc you are proposing in this patchset. >> Kumar is welcome to correct either one or both of us, if we read that >> wrong :) >> > > Yes, after another reading, that does appear to be the case =3D). > > We'll need v7 anyway to fix the ocfs-related UAF the bot found. > Since there is confusion, let me clear it up. I meant it for all of them. I don't think it makes sense to keep this one i= n security/ when others are in fs/bpf_fs_kfuncs.c. That confusing limbo state= is worse than just placing it where others already are. As I already said, the discussion around whether all of them they should go= in security/ is orthogonal and should be done separately; it isn't productive = to repeatedly bring it up in the context of this patch set. I honestly don't get the urgency; it will be a mechanical change if we need= to make such changes. The worst outcome would be stalling David's work over it= . As for landing this stuff, we can let Paul take the patches touching securi= ty/ and route the rest (3-4) through bpf-next after the merge window. We need t= hem to go through BPF CI anyway to ensure nothing breaks. >> However, regardless of Kumar's intent, speaking as the LSM maintainer, >> my stance on this is that the kfunc you are proposing must live in >> security/bpf_lsm_kfuncs.c to be acceptable. >> > > Ack, will do this in v7. > > The Landlock series currently up for discussion [1] is proposing > placing its kfuncs in a new kernel/bpf/bpf_lsm.c. Should these maybe > go there? > > [1] https://lore.kernel.org/bpf/20260731022047.189137-1-utilityemal77@gma= il.com/ > >> -- >> paul-moore.com