On Thu, Mar 9, 2023 at 3:48 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Thu, Mar 9, 2023 at 2:18 PM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
> >
> > Linus observed that the pervasive passing of selinux_state pointers
> > introduced by me in commit aa8e712cee93 ("selinux: wrap global selinux
> > state") adds overhead and complexity without providing any
> > benefit. The original idea was to pave the way for SELinux namespaces
> > but those have not yet been implemented and there isn't currently
> > a concrete plan to do so. Remove the passing of the selinux_state
> > pointers, reverting to direct use of the single global selinux_state,
> > and likewise remove passing of child pointers like the selinux_avc.
> > The selinux_policy pointer remains as it is needed for atomic switching
> > of policies.
> >
> > Suggested-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > Signed-off-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
> > ---
> > security/selinux/avc.c | 197 ++++-----
> > security/selinux/hooks.c | 549 ++++++++++---------------
> > security/selinux/ibpkey.c | 2 +-
> > security/selinux/ima.c | 37 +-
> > security/selinux/include/avc.h | 29 +-
> > security/selinux/include/avc_ss.h | 3 +-
> > security/selinux/include/conditional.h | 4 +-
> > security/selinux/include/ima.h | 10 +-
> > security/selinux/include/security.h | 171 +++-----
> > security/selinux/netif.c | 2 +-
> > security/selinux/netlabel.c | 17 +-
> > security/selinux/netnode.c | 4 +-
> > security/selinux/netport.c | 2 +-
> > security/selinux/selinuxfs.c | 208 ++++------
> > security/selinux/ss/services.c | 346 +++++++---------
> > security/selinux/ss/services.h | 1 -
> > security/selinux/status.c | 44 +-
> > security/selinux/xfrm.c | 20 +-
> > 18 files changed, 651 insertions(+), 995 deletions(-)
>
> It looks like this patch was a bit too big for the mailing list; I'm
> trimming my reply to get this discussion on the list.
>
> I strongly dislike merging patches that haven't hit the list, but I do
> recognize that this is a bit of an unusual case. Have you tried
> breaking this up into two (three?) patches? I imagine that should be
> possible, although I worry that the time required to do that would be
> prohibitive given the change itself.
>
> If that doesn't work, an alternative might be to file a PR against our
> kernel subsystem mirror on GitHub and posting a link to the PR here.
> I don't want to encourage this as a general way of submitting SELinux
> kernel patches, but I could make an exception here.
>
> https://github.com/SELinuxProject/selinux-kernel
I'm open to suggestions but didn't see an obvious way to split it in a
manner that keeps everything in a working state after each patch.
checkpatch.pl didn't complain about the size - not sure if that is a
change in policy. Created a PR here:
https://github.com/SELinuxProject/selinux-kernel/pull/64
