All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 4 May 2009 23:11:57 -0700	[thread overview]
Message-ID: <20090504231157.1ff2cf15.akpm@linux-foundation.org> (raw)
In-Reply-To: <200905041601.51789.oliver@neukum.org>

On Mon, 4 May 2009 16:01:51 +0200 Oliver Neukum <oliver@neukum.org> wrote:

> Am Montag, 4. Mai 2009 09:02:38 schrieb David Brownell:
> > On Sunday 03 May 2009, Oliver Neukum wrote:
> > > No. To make it plain. To me any use of memdup_user() in USB code
> > > is a bad idea. I don't want to have to think about a new primitive.
> >
> > Unless it's incorrect to use that, I have to say that it
> > makes more sense to use that utility than recreate it by
> > open-coding...
> 
> 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.

I wonder how hard it would be to add runtime debugging checks?  If
there are clearly identified transition points where (say) GFP_NOIO
becomes required and unrequired then we could do something along the
lines of

	current->disallowed_gfp_flags |= __GFP_IO;
	....
	current->disallowed_gfp_flags &= ~__GFP_IO;

and check (gfp_flags & current->disallowed_gfp_flags) in the various
memory-allocation functions, and perhaps in the uaccess functions.

Or possibly teach lockdep about it, although that seems inappropriate.

Anyway.  A little project for someone, perhaps.

  reply	other threads:[~2009-05-05  6:15 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 [this message]
2009-05-05 10:44             ` Oliver Neukum
2009-05-05 17:22               ` Andrew Morton
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=20090504231157.1ff2cf15.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.