I am trying to understand how to protect efficiently against
module removals when a device driver is in use.
This issue came up some time ago when trying netmap
loaded as a module.

--- Summary of the current mode of operation (as i understand it): ---

When a device is compiled as a module, all devfs calls in
sys/fs/devfs/devfs_vnops.c are protected by setting
dev->si_threadcount (within dev*_refthread()) for the duration of the call.

This is implemented using devfs_fp_check()/dev_relthread() which
in turn, for the module case, updates the dev->si_threadcount under
dev_lock() which is a single shared mutex, devmtx .

The above is problematic for driver modules that do a lot of I/O
using poll, ioctl, read or write, because of the system-wide contention
on devmtx

To mitigate the contention, statically compiled modules have the
SI_ETERNAL attribute that prevents the lock (major contention point)
and si_threadcount update.

--- Alternative ?

I was hoping to make the protection mechanism cheaper by only
increasing  dev->si_threadcount on devfs_open() without calling
dev_relthread() ), and then decreasing si_threadcount on defvs_close() .
This way the reference is active for the lifetime of the file descriptor
without needing to track individual high-frequency calls.

This is probably not enough because there could be mmap handlers,
which remain active even after the device is closed.

However I do not think the current devfs_fp_check() suffices either,
and so drivers that have their own mmap code in a module that can be
unloaded must already implement their own mechanism to protect
against unloading.
In fact, this could be achieved easily by making these drivers use
dev_refthread() to hold a refcount while active.

Would the above work ? Anything missing ?


 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
 TEL      +39-050-2217533               . via Diotisalvi 2
 Mobile   +39-338-6809875               . 56122 PISA (Italy)
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to