linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: bzolnier@gmail.com, james.steward@dynamicratings.com,
	rmk@arm.linux.org.uk, Jeff Garzik <jgarzik@pobox.com>,
	axboe@suse.de
Subject: [MM, HELP] PIO to and from user-mapped page caches
Date: Thu, 22 Dec 2005 14:55:07 +0900	[thread overview]
Message-ID: <20051222055507.GA19446@htj.dyndns.org> (raw)

Hello, all.

This subject was brought up in linux-ide mailing list by James
Steward in the following message.

http://marc.theaimsgroup.com/?l=linux-ide&m=113494968723962&w=2

Russell King kindly explained the problem in detail in the following
message.

http://marc.theaimsgroup.com/?l=linux-ide&m=113517728717638&w=2

To reiterate it again for the purpose of discussion, the problem is
that some block drivers (IDE, libata and a few SCSI drivers) sometimes
perform PIO instead of DMA.  Block drivers often perform IOs on page
caches which can also be mapped from user-space.  On machines where
caches are physically indexed, PIO doesn't cause any problem as CPU
handles all cache coherency.

However, on machines with virtually indexed caches, there can be
aliased cache lines of the same page which can result in accessing
stale data if mis-managed.  DMA API takes good care of cache coherency
issues but currently most block drivers don't properly manage cache
coherency for PIOs.

The question is what kind of flushing is required where.  AFAIK, DMA
API does the following flushing operations.

* On READ (DMA_FROM_DEVICE)

	Invalidate all cpu caches of the target memory area before IO.
	There's no need for flushing after IO as DMA transfers don't
	affect cpu caches.

* On WRITE (DMA_TO_DEVICE)

	Writeback (but don't invalidate) all cpu caches of the target
	memory area before IO.  There's no need for flushing after IO
	as DMA write transfers don't dirty cpu caches.

PIO READs are different from DMA READs in that read operation creates
(on write-allocate caches) or dirties cache lines and they need to be
flushed before the page is mapped to user space.

As the ramdisk driver (driver/block/rd.c) deals with similar problem
and it performs flush_dcache_page after READ operation, there's no
question that flush_dcache_page is needed after READ, but we're not
sure...

* Is flush_dcache_page needed before PIO READ?  IOW, is it guaranteed
  that there's no dirty user-mapped cache lines on entry to block
  layer for READ?

* Is flush_dcache_page needed before PIO WRITE?  IOW, is it guaranteed
  that there's no dirty user-mapped cache lines on entry to block
  layer for WRITE?

* Is there any better (lighter) function to call to flush dirty
  kernel-mapped cachelines?  flush_dcache_page seems quite heavy for
  that purpose.

And, I think it would be a good idea to have kmap/unmap wrappers in
block layer, say, kmap/unmap_for_pio(page, rw) which deal with above
cache coherency issues.  How does it sound?

TIA.

-- 
tejun

             reply	other threads:[~2005-12-22  5:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-22  5:55 Tejun Heo [this message]
2006-01-09 10:38 ` [MM, HELP] PIO to and from user-mapped page caches Russell King

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=20051222055507.GA19446@htj.dyndns.org \
    --to=htejun@gmail.com \
    --cc=axboe@suse.de \
    --cc=bzolnier@gmail.com \
    --cc=james.steward@dynamicratings.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@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;
as well as URLs for NNTP newsgroup(s).