On Sun, Jan 25, 2004 at 11:02:58AM -0800, Linus Torvalds wrote:> The proper thing to do (and what we _have_ done) is to say "unloading of > modules is not supported". It's a debugging feature, and you literally > shouldn't do it unless you are actively developing that module.> > Sadly, some modules are broken. Old 16-bit PCMCIA in particular _depends_> on unloading modules, since the old PCMCIA layer doesn't do hotplug: it> literally thinks of module load/unload as the "plug/unplug" event.> > But it basically boils down to: don't think of module unload as a "normal> event". It isn't. Getting it truly right is (a) too painful and (b) would> be too slow, so we're not even going to try.> > (As an example of "too painful, too slow", think of something like a > packet filter module. You'd literally have to increment the count in every > part that gets a packet, and decrement the count at every point where it > lets the packet go. And since it would have to be SMP-safe, it would have > to be a locked cycle, or we'd have to have per-CPU counters - at which > point you now also have to worry about things like preemption and > sleeping, which just means that it would be a _lot_ of very fragile code).

Packet filter is hardly a normal module. For absolute majority of modulesit's nowhere near that bad.

HOWEVER, module unload is not the real problem. We have objects withlimited lifetimes. Always had, always will. Whether we remove piecesof .text from the in-core kernel or not, we must be able to deal withthat. Even if methods themselves are present, they won't do you anygood when data structures belonging to object are destroyed.

If that is handled right, rmmod is trivial for 99% of modules. Therest (including Rusty's stuff) can simply say "we can't be unloadedat all" and be done with that.

Basically, "protect the module" is wrong - it should be "protect specificobject" and we need that anyway. We already have that for the largestclass of modules - 300-odd netdev ones. We have that for filesystems.We have that for block devices. We have infrastructure for doing thatto character devices, ttys and ldiscs. Which leaves us with truly weirdstuff that doesn't work in such terms and yes, there your argumentsapply.

Frankly, I'm much more concerned about the stuff that _can't_ be disabled.You can disable module unloading; hell, you can disable modules completely.You can't disable ifdown(8). Which currently means very bad things forstuff in /proc/sys/net/ipv4/{conf,neigh}/*. And all arguments re rmmoddeadlocks apply to that sort of situations...-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at http://www.tux.org/lkml/