Messages in this thread |  | | | Date | Tue, 25 Sep 2007 08:18:10 +0900 | | From | Tejun Heo <> | | Subject | Re: [PATCH 1/4] module: implement module_inhibit_unload() |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |