Re: try_module_get and friends

[Jon Masters <jonathan@jonmasters.org>]

On Wed, 2008-03-05 at 16:14 -0500, Steven Rostedt wrote:
> On Wed, 5 Mar 2008, Frank Ch. Eigler wrote:
> > > There's a theoretical potential for the system to crash in -rt when
> > > unloading a module. Simply because interrupts are threads.
> > >
> > > Some device has an interrupt handler that is called and preempted.
> > > At that moment the module for that device is unloaded. [...]
> > > Since the code for the interrupt handler no longer exists... KABOOM!
> >
> > Perhaps you can identify those modules that have asked for interrupts,
> > and block only them from unloading.  Or, would it be outrageously
> > expensive to increment the module refcount while one of its interrupt
> > handlers is running?
> 
> Actually this whole thing is theoretical. Since the device would have to
> free the irq before unloading and interrupt desc->lock protects races like
> this. Then there is the question of softirqs and tasklets. And random
> passing of pointers. But this can also happen in mainline since tasklets
> and softirqs can run in a thread.
> 
> We need to look deeper. I'm not sure there is an issue here.

I can poke some more and look at what actually happens on module unload
(for now I think a quick test script loading/unloading modules in a loop
should show us whether this is enough of a problem in reality), but I do
want to point out that I was never concerned with interrupt handlers
themselves - only the assumptions mainline makes about "interrupt
context" use of pointers without an explicit try_module_get.

Rusty didn't have a simple answer either, so I'll poke.

Jon.