[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191114170953.GB10980@openwall.com>
Date: Thu, 14 Nov 2019 18:09:53 +0100
From: Solar Designer <solar@...nwall.com>
To: lkrg-users@...ts.openwall.com
Subject: Re: module loading / systemd bug report / suggestion / my Debian packaging rationale
On Thu, Nov 14, 2019 at 08:00:37AM +0100, Adam Zabrocki wrote:
> On Wed, Nov 13, 2019 at 10:30:00AM +0000, Patrick Schleizer wrote:
> > The /etc/sysctl.d mechanism could be used. If I had to bet, I'd bet it
> > is processed by systemd even before module loading. So module arguments
> > would be load just at the right time before LKRG module load. Even the
> > /usr/lib/modules-load.d mechanism might allow to pass sysctl parameters,
> > I don't know yet.
>
> Fair point.
Actually, I think the above is confused.
sysctl's only work _after_ the module has been loaded. The
corresponding sysctl names are unknown to the kernel before the module
is loaded, so attempts to set them (if "/etc/sysctl.d [...] is processed
by systemd even before module loading") would fail, and be lost (not in
any way queued to apply after module load, as Patrick seemed to imply).
The combination of /usr/lib/modules-load.d and /etc/sysctl.d would only
work right for our purpose if modules are loaded first and sysctl
settings are applied next, but this might leave a lengthy time window
when the module is loaded with the non-overridden settings.
I doubt the /usr/lib/modules-load.d mechanism can be used "to pass
sysctl parameters". As I understand, the module loading is done via
modprobe, so module options can be specified via /etc/modprobe.d - and
that's even better than sysctl's, because module options take effect
right away.
We should have module option equivalents for all of our sysctl's that
make sense to be overridden right away.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
