Re: Module autounload proposal: opt-in, not opt-out

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Mon, 8 Aug 2022 09:09:11 +0200
> From: Martin Husemann <martin%duskware.de@localhost>
> 
> On Sun, Aug 07, 2022 at 11:08:47PM +0000, Taylor R Campbell wrote:
> > Some modules might still be unsafe to unload, which is a bug -- but at
> > least this way accidentally creating the wrong network interface or
> > opening the wrong device won't set a ten-second time-bomb for the
> > system like I occasionally stumble upon in the status quo.
> 
> I think that all modules that we deliver and declare safe for *autoload*
> should require to be actually tested, and a basic test (for me) includes
> testing auto-unload. That does not cover races that slip through "casual"
> testing, but should have caught the worst bugs.
> 
> So the error in the cases you stumbled in is the autoload and keeping the
> badly tested module autoloadable but forbid its unloading sounds a bit
> strange to me.

If you want to limit autoloadable modules to those that can be safely
auto-unloaded, then we also need to have predefined lists, like we
have for the exec modules now, for each of the following (and more)
categories of autoloadable modules:

- if_xyz.kmod, when you do `ifconfig xyzN create'
- xyzfs.kmod, when you do `mount -t xyzfs ...'
- xyzdev.kmod, when you open /dev/xyzdevN and there's an entry in
  sys/conf/majors for it
- npf_alg_xyz.kmod, when you configure npf with an ALG xyz

I'm OK with that but it's more work, and -- without auditing and
testing _all_ of those possibilities to put them into the predefined
safe lists -- will have a much bigger immediate negative impact on
autoloadable functionality than my incremental proposal.