Messages in this thread |  | | | Date | Thu, 25 Jun 1998 22:58:27 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: pre-patch-2.1.107 breaks kmod |
| |
On Thu, 25 Jun 1998, Adam J. Richter wrote: > > > >Well, that's the bug then -- loading two modules with the name name is > >illegal, and *has* to work such that exactly one succeeds even if it > >happens at the same time. > > This would be a bug in the create_module(2) system call, not kmod or > the insmod program.
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
|  |