Re: [PATCH] ide: add dcache flushing after PIO

[Tejun Heo <htejun@gmail.com>]

Bartlomiej Zolnierkiewicz wrote:
> On 12/21/05, Tejun Heo <htejun@gmail.com> wrote:
>> Russell King wrote:
>>> On Wed, Dec 21, 2005 at 11:00:22PM +0900, Tejun Heo wrote:
>>>
>>>> Block drivers are responsible for cache coherency before and after IO.
>>>> When using DMA, DMA API takes care of it but drivers should do manual
>>>> flushing with PIO.
>>>
>>> Are you sure you need the ones in the write path?  No other driver
>>> seems to do this.
>>>
>> Unfortunately, I'm not.  I was trying to be on the safe side.
>>
>> Are the page caches guaranteed to have no dirty alias on entry to block
>> layer for write?  I can see that aliases are handled for read(2)s and
>> write(2)s but I don't know much about mmap writebacks.
>>
>> Another question is whether or not it's guaranteed that there's no
>> user-mapped dirty cachelines on entry to block layer for read.  DMA API
> 
> It seems to be guaranteed for read() and write() but not for mmap().
> 
>> clears all cpu caches before IO and, as DMA IO doesn't touch any cpu
>> caches, it doesn't do anything after IO.  The previous patch adds a
>> flush_dcache_page after IO which makes sure that the kernel cache line
>> is gone, but it doesn't do anything to make sure that there's no dirty
>> user-mapped cachelines hanging around before IO.
>>
>> I couldn't find an exemplary driver doing this kind of things with page
>> caches.  Most other flush_dcache_page usages I looked at didn't deal
>> with user mapped page caches.
> 
> After reading excellent explanation by rmk I think that it should be
> fixed at VM layer (filemap_nopage() perhaps).
> 
> Could you move the discussion to LKML (with some generic "subject")
> so we can get some help from MM hackers?
> 
> Bartlomiej

Hi, Bartlomiej.

I'll post a new message to LKML first thing tomorrow.  :-)

-- 
tejun