[RFC PATCH 27/29] lsm: consolidate all of the LSM framework initcalls

[Kees Cook]

On Thu, Apr 10, 2025 at 09:21:46PM -0400, Paul Moore wrote:
> On Wed, Apr 9, 2025 at 7:52 PM Kees Cook <kees at kernel.org> wrote:
> > On Wed, Apr 09, 2025 at 02:50:12PM -0400, Paul Moore wrote:
> > > The LSM framework itself registers a small number of initcalls, this
> > > patch converts these initcalls into the new initcall mechanism.
> > >
> > > Signed-off-by: Paul Moore <paul at paul-moore.com>
> > > ---
> > >  security/inode.c    |  3 +--
> > >  security/lsm.h      |  4 ++++
> > >  security/lsm_init.c | 14 ++++++++++++--
> > >  security/min_addr.c |  5 +++--
> > >  4 files changed, 20 insertions(+), 6 deletions(-)
> 
> ...
> 
> > > @@ -503,7 +508,12 @@ early_initcall(security_initcall_early);
> > >   */
> > >  static int __init security_initcall_core(void)
> > >  {
> > > -     return lsm_initcall(core);
> > > +     int rc_sfs, rc_lsm;
> > > +
> > > +     rc_sfs = securityfs_init();
> > > +     rc_lsm = lsm_initcall(core);
> > > +
> > > +     return (rc_sfs ? rc_sfs : rc_lsm);
> > >  }
> > >  core_initcall(security_initcall_core);
> >
> > Hrm. Given these aren't really _lsm_ hooks, maybe just leave this out. I
> > worry about confusing the lsm inits with the lsm subsystem's core inits.
> 
> I'm not too concerned about that, and I do prefer it this way.

Sounds good to me. And with an eye toward trying to minimize which kinds
of init calls we have in the future, I think it'll just get cleaner over
time.

-- 
Kees Cook