Why in the world are you concerned about this? Rmmod already
serializes "fine" with insmod. In that the kernel keeps the
data structures in a sane state, but that the users of said
modules are bound to loose no matter what.
> Using an flock scheme, the second insmod waits for the flock and holds
> until the first insmod completes. Then it checks if the module has
> been loaded while it was waiting, yes the module is there, return OK.
Um, no, that's not what it does. It waits for the lock, tries to
create the module, and if that fails with EEXIST, returns OK.
But rmmod has always been able to remove an embryonic module before
insmod can fully initialize it -- how else can one clean up after
insmod faults? So there are more insmod/rmmod "races" than you
imagine.
"Doc, it hurts when I do this."
"Don't do that."
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu