One work-around that was suggested was to allow modules to be
superseded, i.e. the old module stays forever, but a new
version can be loaded in parallel. I must say that I'm very
sceptic about this idea, as it seems likely to just mask more
severe problems.
If I remember right, the main arguments why module removal can
race with references were:
- buggy modules that don't even know themselves if they still
serve a purpose or not (solution: fix 'em)
- likewise, but with the excuse that correctness was
sacrificed on the altar of performance
- references getting copied without the module knowing. Looks
like a problem in the subsystem managing the references.
(This was discussed mainly in the context of automating
reference tracking.)
- removal happening immediately after module usage count is
decremented to zero may unload module before module has
executed "return" instruction
While I can accept the theoretical possibility that some code
may indeed not be able to afford handling the module usage
count, I kind of doubt that such conditions exist in real life.
For the removal-before-return problem, I thought a bit about it
on my return flight. It would seem to me that an "atomic"
"decrement_module_count_and_return" function would do the trick.
That function would prepare to return from its caller, then
decrement the module count, and finally do the return. That way,
no resources of the caller would be used after the module usage
counter drops to zero. Obviously, any related cleanup would have
to happen before this. Also, you couldn't call
decrement_module_count_and_return from a function that gets
called from another function in the same module.
Not sure if such a solution for removal-before-return has been
considered/rejected yet. It would seem obvious enough.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://icapeople.epfl.ch/almesber/_____________________________________/ - 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/