[lkml]   [2002]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: simple handling of module removals Re: [OKS] Module removal
On Fri, 5 Jul 2002 15:48:17 +0200, 
Pavel Machek <> wrote:
>Keith Owens wrote
>> Modules can run their own kernel threads. When the module shuts down
>> it terminates the threads but we must wait until the process entries
>> for the threads have been reaped. If you are not careful, the zombie
>> clean up code can refer to the module that no longer exists. You must
>> not freeze any threads that belong to the module.
>Look at the code. freezer will try for 5 seconds, then give up. So, in
>rare case module has some threads, rmmod will simply fail. I believe
>we can fix rare remaining modules one by one.

There is no failure path for rmmod. Once rmmod sees a use count of 0,
it must succeed. Which is why both Rusty and I agree that rmmod must
be split in two, one piece that is allowed to fail and a second piece
that is not.

BTW, freeze_processes() silently ignores zombie processes. The test is
not obvious, it is hidden in the INTERESTING macro which has an
embedded 'continue' to break out of the loop. Easy to miss.

>> You must not freeze any process that has entered the module but not yet
>> incremented the use count, nor any process that has decremented the use
>> count but not yet left the module. Simply looking at the EIP after
>Look how freezer works. refrigerator() is blocking, by definition. So
>if all processes reach refrigerator(), and the use count == 0, it is
>indeed safe to unload.

signal_wake_up() - sets TIF_SIGPENDING for other task
resched_task() - calls preempt_disable() for this cpu
smp_reschedule_interrupt() - now on another cpu
resume_kernel - on other cpu

With CONFIG_PREEMPT, a process running on another cpu without a lock
when freeze_processes() is called should immediately end up in
schedule. I don't see anything in that code path that disables
preemption on other cpus. If I am right, then a second cpu could be in
this window when freeze_processes is called

if (xxx->func)

where func is a module function. There is still a window from loading
the function address, through calling the function and up to the point
where the function does MOD_INC_USE_COUNT. Any reschedule in that
window opens a race with rmmod. Without preemption, freeze might be
safe, with preemption the race is back again.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.065 / U:9.324 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site