Re: Locking strategy for device deletion (also see PR kern/48536)

[David Brownlee <abs%absd.org@localhost>]

On 7 June 2016 at 11:28, Paul Goyette <paul%whooppee.com@localhost> wrote:
> Can anyone suggest a reliable way to ensure that a device-driver module can
> be _really_ safely detached?
>
> The module could theoretically maintain an open/ref counter, but making this
> MP-safe is "difficult"!  Even if the module were to provide a mutex to
> control increment/decrement of it's counter, there's still a problem:
>
> Thread 1 initiates a module-unload, which takes the mutex
>
> Thread 2 attempts to open the device (or one of its units), attempts to
> grab the mutex, and waits
>
> Back in thread 1, the driver's module unload code determines that it is safe
> to unload (no current activites queued, no current opens), so it
> goes forward and unmaps the module - including the mutex!
>
> If the unload code releases the mutex, then thread 2 resumes, at an address
> which has been unmapped, leading to all sorts of bad-stuff(tm).
> (And, if the unload code doesn't bother to release the mutex before
> destroying it, then thread 2 stalls indefinitely.)
>
> There currently doesn't seem to be a safe way to unload driver modules.
>
>
> Any good MP-safe suggestions?

Other than having the mutex be for a nullable pointer to the device
which persists after driver detach and is reattached when the driver
reattaches, which adds an extra pointer dereference for every use...
:/