[RFC PATCH 07/29] lsm: rework lsm_active_cnt and lsm_idlist[]

Kees Cook kees at kernel.org
Thu Apr 10 22:25:26 UTC 2025


On Thu, Apr 10, 2025 at 06:04:38PM -0400, Paul Moore wrote:
> On Wed, Apr 9, 2025 at 7:06 PM Kees Cook <kees at kernel.org> wrote:
> > On Wed, Apr 09, 2025 at 02:49:52PM -0400, Paul Moore wrote:
> 
> ...
> 
> > > diff --git a/security/lsm_init.c b/security/lsm_init.c
> > > index edf2f4140eaa..981ddb20f48e 100644
> > > --- a/security/lsm_init.c
> > > +++ b/security/lsm_init.c
> > > @@ -22,8 +22,8 @@ static __initdata const char *lsm_order_cmdline;
> > >  static __initdata const char *lsm_order_legacy;
> > >
> > >  /* Ordered list of LSMs to initialize. */
> > > -static __initdata struct lsm_info *lsm_order[MAX_LSM_COUNT + 1];
> > >  static __initdata struct lsm_info *lsm_exclusive;
> > > +static __initdata struct lsm_info *lsm_order[MAX_LSM_COUNT + 1];
> >
> > I don't care either way, but why re-order these? Just local reverse
> > xmas-tree?
> 
> Sure?
> 
> Honestly can't say for certain, at this point in the development
> process I had somewhat resigned myself to having a mess of a patchset
> so I figured this was an opportunity to make it look "nice" (er?) in
> my mind, and I suppose at that point that looked better to me ... ?

Understood. I think I ordered the original way because I was hopefully
we'd remove "exclusive" soon, and it felt better to remove it from the
end of a list of variables. *shrug* yay code vibes

-- 
Kees Cook



More information about the Linux-security-module-archive mailing list