Re: [PATCH v4 bpf-next 2/2] selftests/bpf: Add is_kernel parameter to LSM/bpf test programs

[Paul Moore]

On Wed, Mar 5, 2025 at 12:08 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
> On Wed, Mar 5, 2025 at 8:12 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On Tue, Mar 4, 2025 at 10:32 PM Song Liu <song@xxxxxxxxxx> wrote:
> > > On Tue, Mar 4, 2025 at 6:14 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > > On Tue, Mar 4, 2025 at 8:26 PM Blaise Boscaccy
> > > > <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > > Paul Moore <paul@xxxxxxxxxxxxxx> writes:
> > > > > > On Tue, Mar 4, 2025 at 3:31 PM Blaise Boscaccy
> > > > > > <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > ...
> >
> > > Do we need this in the LSM tree before the upcoming merge window?
> > > If not, we would prefer to carry it in bpf-next.
> >
> > As long as we can send this up to Linus during the upcoming merge
> > window I'll be happy; if you feel strongly and want to take it via the
> > BPF tree, that's fine by me.  I'm currently helping someone draft a
> > patchset to implement the LSM/SELinux access control LSM callbacks for
> > the BPF tokens and I'm also working on a fix for the LSM framework
> > initialization code, both efforts may land in a development tree
> > during the next dev cycle and may cause a merge conflict with Blaise's
> > changes.  Not that a merge conflict is a terrible thing that we can't
> > work around, but if we can avoid it I'd be much happier :)
> >
> > Please do make the /is_kernel/kernel/ change I mentioned in patch 1/2,
> > and feel free to keep my ACK from this patchset revision.
>
> My preference is to go via bpf-next, since changes are bigger
> on bpf side than on lsm side.

Fine by me, the patch has my ACK already.

-- 
paul-moore.com