public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Gilad Ben-Yossef <gilad@codefidence.com>,
	Laurent Pinchart <laurent.pinchart@skynet.be>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	zaitcev@redhat.com
Subject: Re: [PATCH] USB: use stack allocation for struct usb_ctrlrequest
Date: Wed, 10 Dec 2008 17:01:06 -0700	[thread overview]
Message-ID: <20081210170106.d19e568d.zaitcev@redhat.com> (raw)
In-Reply-To: <20081210142301.GA11490@localhost>

On Wed, 10 Dec 2008 22:23:01 +0800, Wu Fengguang <fengguang.wu@intel.com> wrote:

> For 64bit systems, we can easily go beyond 4GB physical memory.
> So at least we should add GFP_DMA32 in addition to GFP_NOIO?

I am afraid the situation is that we really screwed the pooch while
creating the USB API. I may be wrong about this, but my understanding
is that if we get an address above 4GB from kmalloc and then send
it down to usb_submit_urb(), a random memory corruption is likely
(this is because we forget to check the result of dma_map_single()).

The code worked until now because most systems out in the field
either a) had IOMMU, or b) had 4GB or RAM or less, but not both.
The case (a) includes all AMD CPUs, all Itanium CPUs, and the
Intel-based enterprise systems from big vendors, e.g. IBM Calgary,
HP ZX-1, etc. Also, (a) covers Intel P4 class systems with swiotlb.
So, we only blow up if a kernel with swiotlb disabled boots on an
Intel box with more than 4GB of RAM. This is still far from ideal,
but we kinda pretend not to notice. I heard that Intel has seen
the error in their ways and is going to come out with IOMMU for
all their chipsets, so in a few years this is going to be moot.

-- Pete

  parent reply	other threads:[~2008-12-11  0:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-10  7:32 [PATCH] USB: use stack allocation for struct usb_ctrlrequest Wu Fengguang
2008-12-10  9:40 ` Laurent Pinchart
2008-12-10 12:43   ` Wu Fengguang
2008-12-10 14:07     ` Gilad Ben-Yossef
2008-12-10 14:23       ` Wu Fengguang
2008-12-10 14:31         ` Gilad Ben-Yossef
2008-12-11  0:01         ` Pete Zaitcev [this message]
2008-12-11  0:57           ` Robert Hancock
2008-12-11  0:59         ` Robert Hancock

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=20081210170106.d19e568d.zaitcev@redhat.com \
    --to=zaitcev@redhat.com \
    --cc=fengguang.wu@intel.com \
    --cc=gilad@codefidence.com \
    --cc=gregkh@suse.de \
    --cc=laurent.pinchart@skynet.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox