On Tue, 25 Sep 2007, Tejun Heo wrote: > 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.
You haven't fully answered Jon's question. Suppose module_unload_inhibit_cnt is nonzero, so the task adds itself to the module_unload_wait queue, changes to TASK_UNINTERRUPTIBLE, and calls schedule. There's nothing to prevent somebody else from waking the task back up before the original inhibition has been lifted. Alan Stern - 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/
