mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jens Axboe <axboe@suse.de>, Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [patch][9/9] block: remove bio walking
Date: Thu, 9 Sep 2004 19:10:57 +0200	[thread overview]
Message-ID: <200409091910.57137.bzolnier@elka.pw.edu.pl> (raw)
In-Reply-To: <20040909155420.D6434@flint.arm.linux.org.uk>

On Thursday 09 September 2004 16:54, Russell King wrote:
> On Thu, Sep 09, 2004 at 04:28:25PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 09 September 2004 16:04, Russell King wrote:
> > > On Thu, Sep 09, 2004 at 03:53:13PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Thursday 09 September 2004 10:03, Russell King wrote:
> > > > > On Wed, Sep 08, 2004 at 09:27:04PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > > [patch] block: remove bio walking
> > > > > > 
> > > > > > IDE driver was the only user of bio walking code.
> > > > 
> > > > was in -bk10 :-(
> > > > 
> > > > > The MMC driver also uses this.  Please don't remove.
> > > > 
> > > > OK I'll just drop this patch but can't we also use scatterlists in MMC?
> > > > 
> > > > The point is that I now think bio walking was a mistake and accessing
> > > > bios directly from low-level drivers is a layering violation (thus
> > > > all the added complexity). Moreover with fixed IDE PIO and without
> > > > bio walking code it should be possible to shrink struct request by
> > > > removing all "current" entries.
> > > 
> > > I'm wondering whether it is legal to map onto SG lists and then do PIO.
> > > Provided we don't end up using the DMA API and then using PIO to the
> > > original pages, it should work.
> > 
> > Yes, it actually works fine. See the other patches from the patchkit. :-)
> 
> Actually, if you've only tested x86, you don't know if it works fine.
> x86 is a rather benign architecture when it comes to testing whether
> various interfaces are being used correctly.

x86 only

This forced me into rechecking everything and I found one issue:
in ide_pio_sector() sg->length should be used instead of sg_dma_len(sg).

With this fixed patchkit should work on any arch
(testing and comments are welcomed of course).

> > > However, using the SG lists does finally provide us with a nice way to
> > > ensure that we have the right information to finally fix IDE wrt the
> > > PIO cache issues (dirty cache lines being left in the page cache.)
> > 
> > Could you explain the issue a bit more?
> 
> Essentially, kernel PIO writes data into the page cache, and that action
> may leave data in the CPU's caches.  Since the kernels mappings may not
> be coherent with mappings in userspace, data written to the kernel
> mappings may remain in the data cache, and stale data would be visible
> to user space.
> 
> There has been talk about using flush_dcache_page() to resolve
> this issue, but I'm not sure what the outcome was.  Certainly
> flush_dcache_page() is supposed to be used before the data in the
> kernels page cache is read or written.
> 
> See Documentation/cachetlb.txt for further information on this
> interface.

Thanks, now I understand the problem.

  parent reply	other threads:[~2004-09-09 17:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 19:27 Bartlomiej Zolnierkiewicz
2004-09-09  8:03 ` Russell King
2004-09-09 13:53   ` Bartlomiej Zolnierkiewicz
2004-09-09 14:04     ` Russell King
2004-09-09 14:28       ` Bartlomiej Zolnierkiewicz
2004-09-09 14:54         ` Russell King
2004-09-09 15:44           ` Jens Axboe
2004-09-09 15:49             ` Jens Axboe
2004-09-09 16:01             ` David S. Miller
2004-09-09 17:10           ` Bartlomiej Zolnierkiewicz [this message]
2004-09-09 14:32       ` Jens Axboe
2004-09-09 14:31     ` Jens Axboe

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=200409091910.57137.bzolnier@elka.pw.edu.pl \
    --to=bzolnier@elka.pw.edu.pl \
    --cc=axboe@suse.de \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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

all inboxes | Powered by JetHome®