But it can. There's no point in disallowing it, is there ?
> Al, the problem we've hit with the netdevice drivers is that they are
> registered and appear in the namespace _when their refcount is zero_.
> That is, register_netdevice() is called from within the context of the
> module constructor. (Well, that's just one of the problems..)
>
> So netdevice methods such as open(), do_ioctl(), set_multicast_list(),
> etc can be and are called when the module refcount is zero.
With the grab-all-CPUs patch, you can arbitrarily call functions with
refcount == 0, as long as they don't go to sleep and
Not a problem, as long as they increase the module use count before going
to sleep (and are called out of process context).
> I think the 'grab all other CPUs' trick solves a lot of the problems.
> It seems to be a sensible thing to do when you're unloading kernel text
> anyway. But there remains the possibility that someone has done a
> shedule() from within the context of a zero-refcount module :(
Yes. schedule() out of a zero-refcount module is a bug. In fact, it's
quite easy to make it a BUG() as well:
struct module *lookup_module(unsigned long pc)
{
struct module *mod;
for(mod = &kernel_module; mod; mod = mod->next) {
if((pc >= (unsigned long)mod) && (pc < (unsigned long)mod+mod->size))
return mod;
}
return NULL;
}
in schedule():
if((mod = lookup_module(__builtin_return_address(0))) && (atomic_read(&mod->uc.usecount) == 0))
BUG();
Phiilpp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/