On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote: > On Fri, Jul 31, 2026 at 11:17 AM 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 =). > > 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 in 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 security/ and route the rest (3-4) through bpf-next after the merge window. We need them 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/[email protected]/ > >> -- >> paul-moore.com
