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. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
