2004-09-01 23:03:57

by J.A. Magallon

[permalink] [raw]
Subject: Module unloading policy (should be killed from .config ?)

Hi all...

Since 2.6.8.1-mm3, my system hangs when I modprobe -r ipt_MASQUERADE
(yup, you guessed, its an SMP box). Just locks hard.

A kernel build without module unloading seems to work. I heard about
module unloading not being safe, but this is the first time it hits me
seriously. If it is so dangerous and deprecated, why is still in Kconfig ?
Could you kill it and remove the code completely ? Because I suppose that
the idea is not to fix drivers...

But I guess this is going to break a lot of distros. At least Mandrake
initscripts is plenty of <modprobe, test, rmmod | modprobe -r> snippets.
Do not know if this is going to break cases like
modprobe -r xxxx || do_more

Could modprobe at least return 0 to the shell when removing ?

What is going on ?

TIA

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.1 (Beta 1) for i586
Linux 2.6.8.1-mm4 (gcc 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)) #8



2004-09-01 23:41:05

by Dave Jones

[permalink] [raw]
Subject: Re: Module unloading policy (should be killed from .config ?)

On Wed, Sep 01, 2004 at 10:59:57PM +0000, J.A. Magallon wrote:
> Hi all...
>
> Since 2.6.8.1-mm3, my system hangs when I modprobe -r ipt_MASQUERADE
> (yup, you guessed, its an SMP box). Just locks hard.
>
> A kernel build without module unloading seems to work. I heard about
> module unloading not being safe, but this is the first time it hits me
> seriously.

I wrote a script a while ago that modprobe'd & rmmod'd every module
it could find. Results weren't pretty.

Lessons learned:
- lots of driver writers don't take into consideration the fact the hardware
might not be present when the driver does probing.
- Those that do, fail to clean up properly in this case.
- A lot of drivers leave junk in sysfs/procfs after rmmod which causes
great fun for the next driver that gets loaded that uses the same subsystems.

It's been a few months since I last ran that script, but I'll bet
the results today aren't much better than they were back then
despite a bunch of problems I reported getting fixed.

Dave