Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/opencrypto



Some modules get auto-loaded by the syscall mechanism. We already have a mechanism to determine if any lwp's are currently executing these syscalls, and if yes we prevent auto-unload.

For device-driver modules, there is currently no equivalent mechanism. They get auto-loaded from code in specfs/vfsops as a result of trying to access the block/char device. We would need to specify exactly what constitutes a "reference" and then keep track. Is it only "open" that creates a reference? Someone mentioned that it might be possible to read/write without opening the device... Also need to consider what happens when the device is cloned ...

There is a refcount in the struct module, and a generic module_hold() / module_rele() mechanism to manipulate. But it is currently used only for tracking inter-module references (ie, dependencies) as far as I can see. It could be used here, but as currently implemented (linear search for module name) it's probably too expensive.

I'm not sure how we would handle "miscellaneous" modules...  :)




On Fri, 24 Jan 2014, Christos Zoulas wrote:

In article <7458.1390534472%splode.eterna.com.au@localhost>,
matthew green  <mrg%eterna.com.au@localhost> wrote:

Log Message:
Implement in-module ref-counting, and do not allow auto-unload if there
are existing references.

Note that manual unloading is not prevented.

OK christos@

XXX Also note that there is still a small window where the ref-count can
XXX be decremented, and then the process/thread preempted.  If auto-unload
XXX happens before that thread can return from the module's code, bad
XXX things (tm) could happen.

in this case, please simply disallow unload for this module always.
if the race is fixed, it can be enabled again.

I think that most module unloads suffer from this race, any ideas how to
fix it?

christos


!DSPAM:52e2a490250671524318036!



-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------


Home | Main Index | Thread Index | Old Index