Re: owner field in `struct fs'

From: Philipp Rumpf (prumpf@uzix.org)
Date: Sun Jun 25 2000 - 10:29:56 EST


On Sun, Jun 25, 2000 at 08:51:12PM +1000, Andrew Morton wrote:
> Alan Cox wrote:
> >
> > > Here it is (it compiles both for UP and SMP, I can't test it on SMP though).
> > >
> > > --- linux/kernel/module.c Fri Jun 23 20:17:18 2000
> > > +++ linux-prumpf/kernel/module.c Sat Jun 24 11:53:05 2000
> >
> > CPU1 CPU2
> > spinlock(&card->lock)
> > rmmod
> > -FREEZE->
> > spin on freeze
> > cleanup_module
> > spinlock(&card->lock)
> >
> > And the box is dead.
>
> Except CPU2 shouldn't be diddling with device-specific locks when the
> module refcount is zero.

But it can. There's no point in disallowing it, is there ?

> Al, the problem we've hit with the netdevice drivers is that they are
> registered and appear in the namespace _when their refcount is zero_.
> That is, register_netdevice() is called from within the context of the
> module constructor. (Well, that's just one of the problems..)
>
> So netdevice methods such as open(), do_ioctl(), set_multicast_list(),
> etc can be and are called when the module refcount is zero.

With the grab-all-CPUs patch, you can arbitrarily call functions with
refcount == 0, as long as they don't go to sleep and

Not a problem, as long as they increase the module use count before going
to sleep (and are called out of process context).

> I think the 'grab all other CPUs' trick solves a lot of the problems.
> It seems to be a sensible thing to do when you're unloading kernel text
> anyway. But there remains the possibility that someone has done a
> shedule() from within the context of a zero-refcount module :(

Yes. schedule() out of a zero-refcount module is a bug. In fact, it's
quite easy to make it a BUG() as well:

struct module *lookup_module(unsigned long pc)
{
        struct module *mod;

        for(mod = &kernel_module; mod; mod = mod->next) {
                if((pc >= (unsigned long)mod) && (pc < (unsigned long)mod+mod->size))
                        return mod;
        }

        return NULL;
}

in schedule():

if((mod = lookup_module(__builtin_return_address(0))) && (atomic_read(&mod->uc.usecount) == 0))
        BUG();

        Phiilpp

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:07 EST