Jonathan Corbet wrote: > Hi, Tejun, > > I was just looking over these changes... > >> + /* Don't proceed till inhibition is lifted. */ >> + add_wait_queue(&module_unload_wait, &wait); >> + set_current_state(TASK_UNINTERRUPTIBLE); >> + if (atomic_read(&module_unload_inhibit_cnt)) >> + schedule(); >> + __set_current_state(TASK_RUNNING); >> + remove_wait_queue(&module_unload_wait, &wait); >> + >> + mutex_lock(&module_mutex); > > Maybe I'm missing something, but this looks racy to me. There's no > check after schedule() to see if module_unload_inhibit_cnt is really > zero, and nothing to keep somebody else from slipping in and raising it > again afterward.
The unloading can proceed once module_unload_inhibit_cnt reaches zero. An unloading thread only has to care about inhibition put in effect before unloading has started, so there's no need to check again. > Given your description of this tool as a "sledgehammer," might it not be > easier to just take and hold module_mutex for the duration of the unload > block? That would be easier but... * It would serialize users of the sledgehammer. * It would block loading modules (which is often more important than unloading them) when things go south. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
