[Top] [All Lists]

Re: modular net drivers, take 2

To: Keith Owens <kaos@xxxxxxxxxx>
Subject: Re: modular net drivers, take 2
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Wed, 21 Jun 2000 04:24:01 +0000
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
References: Your message of "Wed, 21 Jun 2000 02:37:58 GMT." <39502A86.6C8C6FC2@xxxxxxxxxx> <12333.961559040@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Keith Owens wrote:
> Anything sleeping loses the lock.  Any sleep in module open code primes
> the race, if the module_exit code also sleeps the race is triggered.

You're a hard man, Mr Owens.

So sys_delete_module() isn't allowed to sleep. It's hard to make this
rule future-safe.

Do you think that the concept of grabbing the entire machine during
module unload is an acceptable one?  I think it is, because the act of
actually unloading kernel text is so unique and traumatic.

If so then it shouldn't be too hard to find a way.  You have shown why
we can't use the big lock, but we could create a new one for this
purpose.  The challenge is to find a place to put it.  A code path which
is regularly traversed in toplevel context and has an upper bound on the
revisit period.  

Such as schedule() (we'd get shot..).

        blocked_cpus = 1 << smp_processor_id();
        while (blocked_cpus != ((1 << smp_num_cpus) - 1))
                I think the only code whcih needs to go in
                here is the call to vfree(module).

        if (spin_is_locked(&module_deletion_lock))

        set_bit(&blocked_cpus, smp_processor_id());
        while (spin_is_locked(&module_deletion_lock))

<Prev in Thread] Current Thread [Next in Thread>