Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kernel crashes because crypto unloading?

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    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index