Re: Question about pseudo filesystems

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

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.