[Top] [All Lists]

Re: modular net drivers, take 2

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: modular net drivers, take 2
From: Keith Owens <kaos@xxxxxxxxxx>
Date: Wed, 21 Jun 2000 13:53:49 +1000
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: Your message of "Tue, 20 Jun 2000 23:12:36 -0400." <Pine.LNX.4.10.10006202140210.26261-100000@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Tue, 20 Jun 2000 23:12:36 -0400 (EDT), 
Donald Becker <becker@xxxxxxxxx> 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.
>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

Worse than that.  If the module use count is zero then it can be
removed at any time from another cpu.  The only things preventing this
are :-

* Big kernel lock for open() and similar functions.
* MOD_INC_USE_COUNT to bump the reference count.

If the ioctl() uses a file descriptor that was obtained by first
calling the module's open() routine then the use count was bumped so
the ioctl() is safe (once the open race is fixed).  But SIOCDEVPRIVATE
ioctl() calls use file descriptors that do not come from the module and
therefore the reference count "lock" is bypassed.

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