[Top] [All Lists]

Re: modular net drivers, take 2

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: modular net drivers, take 2
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Wed, 21 Jun 2000 03:47:29 +0000
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
References: <> <Pine.LNX.4.10.10006202140210.26261-100000@vaio.greennet>
Sender: owner-netdev@xxxxxxxxxxx
Donald Becker wrote:
> On Wed, 21 Jun 2000, Andrew Morton wrote:
> > In this example, both dev->ioctl() and dev->get_stats() are called while
> > the module refcount is zero.   So they're as risky as open(); these code
> > paths need to be audited for races wrt kmalloc->schedule()
> > opportunities.
> Hmmm, now this is an important point.
> I just "know" that ioctl() and get_stats() should be "simple" functions that
> shouldn't do call any kernel function, except for perhaps printk().  This is
> not documented in the skeleton driver, or elsewhere.
> I'm guessing that the documentation should advise locking the module if any
> operation is done in get_stats() or private_ioctl() that might result in a
> reschedule.

Yes, these functions tend to be atomic in-and-out.  But there are
opportunities for module unload prior to them even being called.

The call path appears to be:

  -> fd.file_operations.ioctl()  (sock_ioctl())
       -> sock.proto_ops.ioctl() (inet_ioctl() for af_inet)
            -> dev_ioctl()
                 -> dev_ifsioc()
                      __dev_get_by_name() (Fails if unloaded)
                        -> dev->ioctl()

So there are some small SMP-only opportunities for the module
to be unloaded prior to netdevice.do_ioctl() even being called.

This is getting sticky, isn't it?

[ Yipes.  3c527.c does a sleep_on() when the module refcount is zero ]

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