Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Aug 2017 10:49:51 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>, freebsd-current@freebsd.org
Cc:        Hans Petter Selasky <hps@selasky.org>, Andriy Gapon <avg@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: order of executing MOD_LOAD and registering module sysctl-s
Message-ID:  <1501692591.90400.142.camel@freebsd.org>
In-Reply-To: <2718016.8bPh6cqhGc@ralph.baldwin.cx>
References:  <62e7ab4d-8956-545e-b204-4fb63cfe5fbf@FreeBSD.org> <c73441ae-e623-3828-d10e-74947c78240b@selasky.org> <2718016.8bPh6cqhGc@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2017-08-02 at 08:49 -0700, John Baldwin wrote:
> On Wednesday, August 02, 2017 12:39:36 PM Hans Petter Selasky wrote:
> > 
> > On 08/02/17 12:13, Andriy Gapon wrote:
> > > 
> > > 
> > > As far as I understand a module initialization routine is
> > > executed via the
> > > sysinit mechanism.  Specifically, module_register_init is set up
> > > as the sysinit
> > > function for every module and it calls MOD_EVENT(mod, MOD_LOAD)
> > > to invoke the
> > > module event handler.
> > > 
> > > In linker_load_file() I see the following code:
> > >                          linker_file_register_sysctls(lf);
> > >                          linker_file_sysinit(lf);
> > > 
> > > I think that this means that any statically declared sysctl-s in
> > > the module
> > > would be registered before the module receives the MOD_LOAD
> > > event.
> > > It's possible that some of the sysctl-s could have procedures as
> > > handlers and
> > > they might access data that is supposed to be initialized by the
> > > module event
> > > handler.
> > > 
> > > So, for example, running sysctl -a at just the right moment
> > > during the loading
> > > of a module might end up in an expected behavior (including a
> > > crash).
> > > 
> > > Is my interpretation of how the code works correct?
> > > Can the order of linker_file_sysinit and
> > > linker_file_register_sysctls be changed
> > > without a great risk?
> > > 
> > > Thank you!
> > > 
> > > P.S.
> > > The same applies to:
> > >                  linker_file_sysuninit(file);
> > >                  linker_file_unregister_sysctls(file);
> > > 
> > Hi,
> > 
> > Not sure if this answers your question.
> > 
> > If a SYSCTL() is TUNABLE, it's procedure can be called when the
> > sysctl 
> > is created. Else the SYSCTL() procedure callback might be called
> > right 
> > after it's registered. I think there is an own subsystem in
> > sys/kernel.h 
> > which takes care of the actual SYSCTL() creation/destruction -
> > after the 
> > linker is involved.
> sysctl nodes are created explicitly via linker_file_register_sysctls,
> not via
> SYSINITs, so you can't order them with respect to other init
> functions.
> 
> I think Andriy's suggestion of doing sysctls "inside" sysinits (so
> they are
> registered last and unregistered first) is probably better than the
> current
> state and is a simpler fix than changing all sysctls to use SYSINITs.
> 

But if module sysctls are registered last then the ones flagged as
CTLFLAG_TUN won't have their tunable values populated before the
MOD_LOAD handler runs, is that going to cause trouble?  It would suck
to have to handle things differently in a driver depending on whether
you're compiled into the kernel or kldload'd interactively.

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1501692591.90400.142.camel>