public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Becky Bruce <beckyb@kernel.crashing.org>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
Date: Thu, 21 May 2009 23:08:16 +0100	[thread overview]
Message-ID: <1242943696.25553.658.camel@localhost.localdomain> (raw)
In-Reply-To: <4A15B72E.2070202@goop.org>

On Thu, 2009-05-21 at 16:18 -0400, Jeremy Fitzhardinge wrote:
> I guess the test is checking for a bad implementation of map_single().

More importantly the io_tlb_overflow_buffer is basically a second chance
if you exhaust the swiotlb pool. The check seems to be there to ensure
that the second chance memory is suitable for the device (it's hard to
imagine, but possible I suppose, that it wouldn't be), a bad
implementation of map_single() is a secondary concern I suspect.

If all the callers of map_page did proper error handling this would all
be unnecessary. I guess someone was worried, at least at one point, that
they didn't. The failure case could possibly be scribbling into a random
memory location or more worryingly sprinkling random memory locations
onto your disk or whatever. That said I'd imagine that map_page
returning NULL would cause an oops long before anything tried to DMA
anything and the second chance probably doesn't buy us much in practice.

Ian.



  reply	other threads:[~2009-05-21 22:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1242340949-16369-1-git-send-email-beckyb@kernel.crashing.org>
     [not found] ` <1242340949-16369-2-git-send-email-beckyb@kernel.crashing.org>
2009-05-19  5:27   ` [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit FUJITA Tomonori
2009-05-19 20:57     ` Becky Bruce
2009-05-21 17:43       ` Jeremy Fitzhardinge
2009-05-21 18:27         ` Becky Bruce
2009-05-21 19:01           ` Ian Campbell
2009-05-22 10:51             ` FUJITA Tomonori
2009-05-21 20:18           ` Jeremy Fitzhardinge
2009-05-21 22:08             ` Ian Campbell [this message]
2009-05-22 10:51             ` FUJITA Tomonori
2009-05-27 19:05               ` Becky Bruce
2009-05-22 11:11           ` Ian Campbell
2009-05-22 23:55             ` Jeremy Fitzhardinge
2009-05-23 22:59               ` Leon Woestenberg
2009-05-26 12:51               ` Ian Campbell
2009-05-27 19:11                 ` Becky Bruce
2009-05-27 19:05             ` Becky Bruce
2009-05-27 20:29               ` Ian Campbell
2009-05-27 22:11                 ` Becky Bruce

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=1242943696.25553.658.camel@localhost.localdomain \
    --to=ian.campbell@eu.citrix.com \
    --cc=beckyb@kernel.crashing.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.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