atm_devs protection.

From: Rogier Wolff (R.E.Wolff@bitwizard.nl)
Date: Wed Oct 18 2000 - 07:05:04 EST

Hi,

We're trying to make the module refcounting 'secure' against
concurrent SMP unloads.

For example in net/atm/resources.c:

-----------------------------------------------------------
static void free_atm_dev(struct atm_dev *dev)
{
        if (dev->prev) dev->prev->next = dev->next;
        else atm_devs = dev->next;
        if (dev->next) dev->next->prev = dev->prev;
        else last_dev = dev->prev;
        kfree(dev);
}

struct atm_dev *atm_find_dev(int number)
{
        struct atm_dev *dev;

        for (dev = atm_devs; dev; dev = dev->next)
                if (dev->ops && dev->number == number) return dev;
        return NULL;
}

-----------------------------------------------------------

as I see it, we could have two processors near this code section.
Processor 1 is looking for the first in the list (number ==
atm_devs->number). and Processor 2 happens to be freeing the atm_dev
that happens to be the first on the list. (dev == atm_devs).

So processor 1 does the first section of the "for":

        dev = atm_devs;

Now processor 2 comes along and executes

                atm_devs=dev->next;
                kfree (dev);

Now processor 1 holds a reference to a freed piece of memory, and will
happily dereference it...

So, our conclusion is that mostly the "walk the atm_devs list"
instances will have to be protected with a spinlock. There are
many instances (about 10) of this.

When we do the "atm_find_dev", to connect a VCC to a DEV, that's when
we'll increase the refcount of the module handling the "dev"....

Any things we've missed? Suggestions? Feedback. Anybody?

                                Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*       Common sense is the collection of                                *
******  prejudices acquired by age eighteen.   -- Albert Einstein ********
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:13 EST