Re: kernel crashes because crypto unloading?

[Paul Goyette <paul%whooppee.com@localhost>]

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?

> 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.)

> 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?

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?


-------------------------------------------------------------------------
| 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  |
-------------------------------------------------------------------------