Nononono.
The module creation is atomic, like Alan said. My argument was that that
isn't enough. It's enough for "command line" usage, and it guarantees that
you cannot have the same module loaded twice. As such, it guarantees
safety.
However, the thing that the pre-107 patches tried to fix, and which is a
usability bug rather than a safety bug is the fact that it is _not_ enough
to just have create_module() be atomic when you use kmod (or kerneld - I
don't want to give people the impression that this is new to kmod per se).
The problem is that if you have two threads that want to load the same
module with kmod, _both_ of them have to succeed, and _both_ of them have
to wait not until after create_module(), but until after init_module() has
successfully returned.
That's fairly hard to do. The pre-107 patches did this correctly, but only
for modules that couldn't cause recursive module loading (ie one module
causing another module to be requested from kmod when it is loaded). And
like it or not, that's exactly what we have with multi-layer modules like
the printer driver or certain other drivers (scsi, sound, 8390.c).
What the current thing can result in is that when two processes need
dependent modules, one of them can failt to get it because it happened to
come in at just the wrong moment. It's unlikely, but at the same time it's
certainly easy enough to trigger with certain usage patterns..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu