Re: kernel crashes because crypto unloading?

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

On Sun, Jan 19, 2014 at 11:16:27AM -0800, Paul Goyette wrote:
> On Sun, 19 Jan 2014, David Laight wrote:
> 
> >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....
> 
> Yeah, the process/thread resumes execution in address space that may 
> well have been deallocated and resused for something else.  :(
> 
> >open/close (well probably the vnode) needs to hold a reference count
> >against the device.
> 
> And, in the case of a cloning device, it should hold a ref-count on the 
> master?

A quick guess is that the vop_lookup (or whatever that namei calls)
needs to allocate a reference to the module when the function pointers
are all setup.  I don't think it can wait until vop_open() since I
suspect that netbsd allows read/write without open (SYSV does).
In any case the holding the reference for the lifetime of the vnode
makes all file accesses safe.

A cloning open may not need to do anything special.
If the closed device can be in a different module then it would
(probably) need to be implemented by switching the vnode in the FILE
structure - and the 2 vnodes would have their own references.
(Again I only know how SVSV did clone opens!)

> >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.
> 
> Again, :(  (And of course, the module would need to force the thread to 
> exit before the module can allow itself to be  unloaded.)

Look at how linux solved it for kernel threads.

> >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.
> 
> Any suggestions on how to actually make this happen?

For things accessed by fd, the vnode can hold the reference.
For system calls maybe just remember the system call each lwp is in,
and when trying to unload check all the lwp individually.
Ans misc systems needs to be ref-counted by whatever calls into them.

> Here we have a user-land that has no clue about kernel modularity.  It 
> simply opens up /dev/crypto which causes the module to be auto-loaded.
> 
> What code, in this case, would create a reference to the module?  And 
> what code would remove that reference?

For /dev/cropto open() and close().

        David

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