I don't get that. The sequence is:
- turn off preemption
- unhook call points
- synchronize_kernel
- ...
which doesn't leave any preemption hole that I can see, so I can't comment
on a couple of the other points until you clear that one up.
> > > Now, there remains a subtle problem with the try_inc_mod_count
> > > approach in general. It is the "spurious failure" problem, where
> > > eg. a notifier cannot inc the module count, and so does not call the
> > > registered notifier, but the module is still being initialized *OR* is
> > > in the middle of an attempt to remove the module (which fails, and the
> > > module is restored to "life").
> >
> > For pure counting-style modules, it's easy to avoid this problem: the module
> > is placed in the can't-increment state if and only if the current count is
> > zero, and from that point on we know the unload will either succeed or fail
> > with an error.
>
> Still a race between the zero check and the can't-increment state
> setting.
But that one is easy: the zero check just takes the same spinlock as
TRY_INC_MOD_COUNT, then sets can't-increment only in the case the count
is zero, considerably simpler than:
> This is what my current code does: rmmod itself checks (if
> /proc/modules available), then the kernel sets the module to
> can't-increment, then checks again. If the non-blocking flag is set,
> it then re-animates the module and fails, otherwise it waits.
and leaves no window for spurious failure. The still-initializing case is
also easy, e.g., a filesystem module simply doesn't call register_filesystem
until it's completely ready to service calls, so nobody is able to do
TRY_INC_MOD_COUNT.
> BTW, current patchset (2.5.43):
Thanks, I'll read them all on the 21st ;-) The other thing I need to read
closely is Roman's strategy for changing the module format, and the weird
linker connections.
> ...The second is the "die-mother-fucker-die"
> version, which taints the kernel and just removes the damn thing. For
> most people, this is better than a reboot, and will usually "work".
Is there a case where removing a module would actually help? What is
the user going to do next, try to reinsert the same module?
> http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/force-unload.patch.gz
> [ Doesn't apply currently, needs updating ]
ERROR 404: Not Found.
-- Daniel - 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/