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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
