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
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_get_by_name() (Fails if unloaded)
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 ]