Re: kernel crashes because crypto unloading?

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Jan 19, 2014 at 09:49:42AM -0800, Paul Goyette wrote:
> On Sun, 19 Jan 2014, Paul Goyette wrote:
> 
> >I would have expected config_cfdata_detach() to fail (with EBUSY) if the 
> >device was still open by someone.  So I'm not sure who/what still owns 
> >allocations from the module's memory pool.
> 
> Hmmm, I guess I misunderstood something.  It seems that there is no 
> protection against detaching a device even when it is currently open.
> 
> A quick-and-dirty program that simply opens /dev/crypto and sleeps shows 
> that the module gets unloaded.
> 
> I'm not sure at this point if the crypto(4) driver should implement a 
> ref-count, or if a more generic solution should be created within the 
> autoconf(9) framework.

The module can't do its own refcounting.
Think about what happens in the 'close' code on the last close.
The driver will decrement the ref count to zero.
The process gets pre-empted.
The driver gets unloaded.
The process resumes....

open/close (well probably the vnode) needs to hold a reference count
against the device.

There is a another race as well.
If a loadable kernel module creates a kernel thread, then it has to
request a module reference for that thread.
When the thread exits it must do so by calling into the kernel requesting
that the thread exit AND that the module reference count be reduced.

Most of the time you should be able to assume that the code calling
into the module holds a reference (possibly indirectly) that ensures
the module won't go away.

        David

-- 
David Laight: david%l8s.co.uk@localhost