Received:  by oss.sgi.com id <S42354AbQFUDzN>;
	Tue, 20 Jun 2000 20:55:13 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:4191 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42305AbQFUDzJ>;
	Tue, 20 Jun 2000 20:55:09 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA29319
	for <netdev@oss.sgi.com>; Tue, 20 Jun 2000 20:50:11 -0700 (PDT)
	mail_from (kaos@kao2.melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA02652; Wed, 21 Jun 2000 13:53:49 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@ocs.com.au>
To:     Donald Becker <becker@scyld.com>
cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: modular net drivers, take 2 
In-reply-to: Your message of "Tue, 20 Jun 2000 23:12:36 -0400."
             <Pine.LNX.4.10.10006202140210.26261-100000@vaio.greennet> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 21 Jun 2000 13:53:49 +1000
Message-ID: <12400.961559629@kao2.melbourne.sgi.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, 20 Jun 2000 23:12:36 -0400 (EDT), 
Donald Becker <becker@scyld.com> 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
>reschedule.

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.