From: Andrew Morton <akpm@linux-foundation.org>
To: Oliver Neukum <oliver@neukum.org>
Cc: David Brownell <david-b@pacbell.net>,
Li Hong <lihong.hi@gmail.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: use memdup_user()
Date: Tue, 5 May 2009 10:22:53 -0700 [thread overview]
Message-ID: <20090505102253.6993f381.akpm@linux-foundation.org> (raw)
In-Reply-To: <200905051244.01698.oliver@neukum.org>
On Tue, 5 May 2009 12:44:01 +0200 Oliver Neukum <oliver@neukum.org> wrote:
> Am Dienstag, 5. Mai 2009 08:11:57 schrieb Andrew Morton:
> > On Mon, 4 May 2009 16:01:51 +0200 Oliver Neukum <oliver@neukum.org> wrote:
>
> > > I want people to be forced to think about memory allocations.
> > > We had endless trouble during 2.4 with storage deadlocking.
> > > We simply need full control of this.
> >
> > thou-shalt-use-GFP_NOFS is a very common pattern in many filesystems.
> > And thou-shalt-use-GFP_NOIO is a very common pattern in block drivers.
>
> USB drivers are interface level yet some functions, reset and power
> management, are on a device level. As it is unpredictable whether
> a driver will share a device with a storage driver, all USB drivers as far as
> these functions are concerned must be considered block device drivers.
> That's the reason GFP_NOIO is so prevalent in USB.
There must be some particular action which flips the thread of control
from one state to the other. eg, taking of a lock.
> > I wonder how hard it would be to add runtime debugging checks? If
>
> I'd prefer compile time checks. Ideally we'd annotate a function with an
> attribute making the compiler barf if copy_to/from_user or an inappropriate
> kmalloc is used. It can't be perfect due to function pointers, but it would
> be a good start.
I don't think that would have enough coverage - bugs in this area tend
to come from calling some function which looks innocent, but which
calls some function which calls some function which calls some function
which uses GFP_KERNEL.
And then there's stuff like "usb takes a mutex which is also taken by
some other thread which does a GFP_KERNEL allocation while holding that
mutex".
next prev parent reply other threads:[~2009-05-05 17:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-03 16:00 [PATCH] usb: use memdup_user() Li Hong
2009-05-03 16:28 ` Oliver Neukum
2009-05-03 17:09 ` Oliver Neukum
2009-05-04 3:38 ` Li Hong
2009-05-04 6:54 ` Oliver Neukum
2009-05-04 7:02 ` David Brownell
2009-05-04 7:41 ` Pekka Enberg
2009-05-04 14:53 ` Greg KH
2009-05-04 15:13 ` Li Hong
2009-05-05 8:50 ` Oliver Neukum
2009-05-04 14:01 ` Oliver Neukum
2009-05-05 6:11 ` Andrew Morton
2009-05-05 10:44 ` Oliver Neukum
2009-05-05 17:22 ` Andrew Morton [this message]
2009-05-06 13:34 ` Oliver Neukum
2009-05-06 18:31 ` Andrew Morton
2009-05-06 18:44 ` Oliver Neukum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090505102253.6993f381.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=lihong.hi@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oliver@neukum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.