Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling

On Fri Jul 31, 2026 at 10:48 PM CEST, Paul Moore wrote:
> On Fri, Jul 31, 2026 at 4:16=E2=80=AFPM Kumar Kartikeya Dwivedi
> <[email protected]> wrote:
>> On Fri Jul 31, 2026 at 10:01 PM CEST, Paul Moore wrote:
>> > On Fri, Jul 31, 2026 at 3:20=E2=80=AFPM Kumar Kartikeya Dwivedi
>> > <[email protected]> wrote:
>> >> On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote:
>> >> > On Fri, Jul 31, 2026 at 2:50=E2=80=AFPM Kumar Kartikeya Dwivedi
>> >> > <[email protected]> wrote:
>> >> >> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote:
>> >> >> > On Fri, Jul 31, 2026 at 2:18=E2=80=AFPM Kumar Kartikeya Dwivedi
>> >> >> > <[email protected]> wrote:
>> >> >> >> On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote:
>> >> >> >> > On Fri, Jul 31, 2026 at 12:32=E2=80=AFPM Kumar Kartikeya Dwiv=
edi
>> >> >> >> > <[email protected]> wrote:
>> >> >> >> >> On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote:
>> >> >> >> >> > On Fri, Jul 31, 2026 at 11:44=E2=80=AFAM Kumar Kartikeya D=
wivedi
>> >> >> >> >> > <[email protected]> wrote:
>> >> >> >> >> >> 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 <pa=
[email protected]> wrote:
>> >> >> >
>> >> >> > ...
>> >> >> >
>> >> >> >> Yes, I understand you feel it should be placed under security/.=
 You are entitled
>> >> >> >> to your opinion.
>> >> >> >>
>> >> >> >> No, I do not think the newly added kfunc is a big enough layeri=
ng violation such
>> >> >> >> that we need to do it ASAP, disregarding everything else outlin=
ed above. I am
>> >> >> >> sure you see that too. There are several other instances of sim=
ilar kfuncs.
>> >> >> >>
>> >> >> >> Therefore, please attempt to meet me halfway here.
>> >> >> >
>> >> >> > I'm happy to work with you, and/or anyone else, who wants to wor=
k on
>> >> >> > finding a way to test kfuncs that live in security/bpf_lsm_kfunc=
s.c.
>> >> >>
>> >> >> Right, and for that file to exist, you need to get everyone (FS, B=
PF folks) to
>> >> >> agree on whether placing all such kfuncs there makes sense. It is =
not for both
>> >> >> of us to decide on our own. So let's revisit this whole topic once=
 you've done
>> >> >> that exercise.
>> >> >
>> >> > The kfunc that David has proposed must be located in
>> >> > security/bpf_lsm_kfuncs.c, similar to the VFS kfuncs and
>> >> > fs/bpf_fs_kfuncs.c.  If you read David's bpf_init_inode_xattr() kfu=
nc
>> >>
>> >> Sigh.
>> >>
>> >> I now went and read the archives, and Christian already told you no b=
efore [0],
>> >> which I missed in my first read. So two people whom this code affects=
 already
>> >> objected to your proposal.
>> >
>> > As mentioned previously, David's kfunc has nothing to do with the VFS.
>> > Look at the code if you haven't already and you'll see what I mean.
>> > The only relevance to the VFS is the fact that "inode" and "xattr" are
>> > used in the name; David's currently proposed kfunc is an LSM kfunc,
>> > not a VFS kfunc.
>>
>> I am sorry, I read it and I don't see why it is an LSM kfunc. It is abso=
lutely a
>> VFS kfunc, that is using LSM APIs to some end. The LSM specific bits are=
 already
>> in security/.
>
> [...]
>
>> > If you find yourself required to abide by Christian's comment, despite
>> > this not being a VFS kfunc, that's fine, but this puts us at a
>> > stalemate and David will need to find another approach for his work.
>>
>> Paul, let me remind you of another email you sent [0], in which you cont=
radict
>> yourself. I don't know what caused you to get confused over the month.
>>
>> In it, you tell David to move *LSM* bits into security_lsmxattr_add(), w=
hich has
>> been done in patch 2. Thus, by your own characterization, it means the r=
est is
>> *not LSM* code.
>>
>> Quoting you verbatim:
>> > As I said previously, if you absolutely insist on the kfunc being in
>> > the VFS kfunc file, the LSM specific bits need to be abstracted out
>>                         ^^^^^^^^^^^^^^^
>> > into an LSM function.
>>
>> You yourself made the point in that same email that the kfunc can stay i=
n the
>> current file once LSM bits were moved out, and your request was honored.
>>
>> At this point, anybody reading this thread will only see your position a=
s a way
>> to undermine David's work and waste everyone's time, such that you can g=
rind an
>> axe against BPF folks. It's a repeating pattern.
>
> It seems foolish to speculate on what *everyone* reading this thread
> might be thinking, but since the discussion has decayed to the point
> where we are spelunking archives for quotes, let me provide my comment
> from David's v5 patchset where I explain myself:
>
> "I'm sorry David, now that I'm seeing this function again, especially
> with the LSM specific bits extracted into a LSM function, this absolutely
> belongs somewhere under security/.  It's only callable from within a
> BPF LSM callback and all it does outside of some BPF pointer boilerplate
> is call right back into a LSM helper function."

I think you keep forgetting that you cannot unilaterally decide this. Both =
VFS
and BPF people have told you that it does not make sense. What was clearly =
LSM
specific code has been moved under security/ already.

It's all BPF code otherwise, and topical for the VFS subsystem, hence it sh=
ould
stay there. That is why it's a VFS kfunc. The rest of the kernel calls LSM =
APIs
and hooks, but it does not make them LSM code.

It needs to be reviewed by VFS and BPF maintainers. Yes, it's only called f=
rom
BPF LSM callbacks, but plenty of kfuncs for those are already outside secur=
ity/.

The right way to do address that is to get people who added and maintain th=
at
code to agree with you, not take the work of unsuspecting contributors host=
age
to meet your goals, and threatening to block their work.

And to set expectations, it is clear people do not agree with your stated m=
ove.
When everyone tells you that you are wrong about something, sometimes, it i=
s
helpful to revisit your position.

>
> You are welcome to view that however you like.  I saw the v5 patchset
> and the nature of the kfunc became painfully obvious to me so I
> changed my opinion.

I think you have difficulties in recognizing that a piece of code can be
cross-cutting, and affect several subsystems at once. The code that was cle=
arly
belonging to LSMs was already moved in patch 2. The unrelated stuff is wher=
e it
has belonged in the past already, so that it can be reviewed by the right f=
olks.

The best course of action IMO is channeling your version from 1 month ago, =
where
you saw things more clearly, and help everyone move forward with this by la=
nding
the first two patches once you think they are in good shape. We will then t=
ake
the rest through BPF tree. It will be a better, more productive outcome for=
 everyone.

If you cannot do that, let's agree to disagree and not waste each others' t=
ime.
We will work on figuring out some other way to help David.