linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	tytso@mit.edu, Kyle McMartin <kyle@mcmartin.ca>,
	linux-parisc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [git patches] xfs and block fixes for virtually indexed arches
Date: Mon, 21 Dec 2009 11:14:39 -0600	[thread overview]
Message-ID: <1261415679.2619.121.camel@mulgrave.site> (raw)
In-Reply-To: <20091219183305.GA10568@linux-mips.org>

On Sat, 2009-12-19 at 18:33 +0000, Ralf Baechle wrote:
> On Thu, Dec 17, 2009 at 09:42:15AM -0800, Linus Torvalds wrote:
> 
> > 
> > I also think that the changes to bio_map_kernel() and bio_map_kern_endio() 
> > are not just "fundamentally ugly", I think they are made worse by the fact 
> > that it's not even done "right". You both flush the virtual caches before 
> > the IO and invalidate after - when the real pattern should be that you 
> > flush it before a write, and invalidate it after a read.
> > 
> > And I really think that would be all much more properly done at the 
> > _caller_ level, not by the BIO layer.
> > 
> > You must have some locking and allocation etc logic at the caller anyway, 
> > why doesn't _that_ level just do the flushing or invalidation?
> 
> And then there are certain types of caches that need invalidation before
> _and_ after a DMA transaction as a workaround for a processor being
> grossly abused in a system that it should not be used in.  Basically the
> issue is that falsly speculated stores may dirty caches.

Um, so that's just so wrong it doesn't even seem possible.  It would
mean that a speculation could make a line dirty while DMA was in
progress to the underlying memory.  There's always going to be a window
between the DMA completion and the software invalidation where the dirty
line could be flushed, thus corrupting the DMA transfer.

Hopefully steps have been taken to see that whoever thought this was a
good idea isn't still contributing to the gene pool?

James

  parent reply	other threads:[~2009-12-21 17:14 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20091216043618.GB9104@hera.kernel.org>
2009-12-17 13:22 ` [git patches] xfs and block fixes for virtually indexed arches Kyle McMartin
2009-12-17 13:22   ` Kyle McMartin
2009-12-17 13:25   ` Christoph Hellwig
2009-12-17 16:16   ` Linus Torvalds
2009-12-17 16:30     ` tytso
2009-12-17 16:46       ` Linus Torvalds
2009-12-17 16:46         ` Linus Torvalds
2009-12-17 17:07         ` Christoph Hellwig
2009-12-17 17:07           ` Christoph Hellwig
2009-12-17 17:42           ` Linus Torvalds
2009-12-17 17:51             ` Christoph Hellwig
2009-12-17 17:51               ` Christoph Hellwig
2009-12-17 18:08             ` Russell King
2009-12-17 18:08               ` Russell King
2009-12-17 18:17               ` Linus Torvalds
2009-12-17 18:17                 ` Linus Torvalds
2009-12-19 18:33             ` Ralf Baechle
2009-12-19 18:33               ` Ralf Baechle
2009-12-21 17:14               ` James Bottomley [this message]
2009-12-17 17:39         ` tytso
2009-12-17 17:39           ` tytso
2009-12-17 17:51           ` Linus Torvalds
2009-12-17 19:36             ` Jens Axboe
2009-12-17 19:36               ` Jens Axboe
2009-12-17 23:57               ` James Bottomley
2009-12-17 23:57                 ` James Bottomley
2009-12-18  1:00                 ` FUJITA Tomonori
2009-12-18  2:44                   ` Dave Chinner
2009-12-18  2:44                     ` Dave Chinner
2009-12-18  3:51                     ` FUJITA Tomonori
2009-12-18  3:51                       ` FUJITA Tomonori
2009-12-18  7:10                     ` James Bottomley
2009-12-18  7:08                   ` James Bottomley
2009-12-18  9:34                     ` FUJITA Tomonori
2009-12-18 10:01                       ` James Bottomley
2009-12-18 10:01                         ` James Bottomley
2009-12-18 10:24                         ` FUJITA Tomonori
2009-12-18 10:30                           ` James Bottomley
2009-12-18 12:00                     ` Dave Chinner
2009-12-18 12:00                       ` Dave Chinner
2009-12-18  0:21           ` FUJITA Tomonori
2009-12-18 14:17             ` tytso
2009-12-18 14:17               ` tytso
2009-12-21  8:53               ` FUJITA Tomonori
2009-12-17 17:10       ` Christoph Hellwig
2009-12-17 17:10       ` Christoph Hellwig
2009-12-17 17:33         ` tytso
2009-12-17 17:33           ` tytso

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=1261415679.2619.121.camel@mulgrave.site \
    --to=james.bottomley@hansenpartnership.com \
    --cc=hch@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=kyle@mcmartin.ca \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=ralf@linux-mips.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).