[lkml]   [2002]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Question about pseudo filesystems
Daniel Phillips wrote:
> Locking
> has been arranged by module.c such that this won't increase during the
> course of the cleanup_module call. The module exit routine does:
> if (module->count)
> return module->count;
> return clean_up_whatever();

If any code within the module does `MOD_DEC_USE_COUNT; return;', you
have a race condition.

That's why nowadays you shouldn't see this. The main reference points
to a module are either function calls from another module (already count
as references), or a file/filesystem/blockdev/netdevice: these all have
an `owner' field now, so that the MOD_DEC_USE_COUNT can take place
outside their modules.

If you do still see MOD_DEC_USE_COUNT in a module, then there's a race
condition. Some task calls the function which does MOD_DEC_USE_COUNT,
and some _other_ task calls sys_delete_module(). Lo, the module is
cleaned up and destroyed by the second task while it's in the small
window just before `return' in the first task.

Given that, you need to either (a) not call MOD_DEC_USE_COUNT in the
module, and use the `owner' fields of various structures instead, or (b)
something quite clever involving a quiescent state and some flags.

Note that (b) is not trivial, as you can't just do
`wait_for_quiescent_state()' followed by `if (module->count)': it's
possible that someone may call MOD_INC_USE_COUNT after the quiescent
state has passed, but before you finish cleaning up.

-- Jamie

ps. I'm not sure what "SCM" means, so can't comment on that.
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:28    [W:0.083 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site