[lkml]   [2003]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least))
Andrew Morton writes:
> "Lothar Wassmann" <> wrote:
> >
> > And maybe because *every* other call to flush_page_to_ram() has been
> > replaced by one of the new interface macros except that one in
> > filemap_nopage() in 'mm/filemap.c'.
> >
> flush_page_to_ram() has been deleted from the kernel.
Yes, I know. But did you even read, what I have written?

The macro has still been there in 2.5.30, but was already defined as a
NOP. In every source file where it had been used (except filemap.c), it
was already accompanied by a call to one of 'flush_dcache_page',
'flush_icache_page', 'copy_user_page' or 'clear_user_page' which
obviously took over the function that flush_page_to_ram previously
had. Somewhere around 2.5.46 the obsolete macro was removed and the
piece of code in filemap.c is the only location where it has not been
replaced by one of the new macros. This looks very suspicious to me.

Unfortunately in the i386 Architecture (which I presume is the most
widely spread Linux arch) this macro has always been a NOP, so that
noone could notice it missing somewhere.

> filemap_nopage() is a pagecache function and shouldn't be fiddling with
> cache and/or TLB operations. Unless it touches the page by hand, which it
> does not.
Ok, but then some function which is called from filemap_nopage()
should have done the job beforehand.

> Please, test a current kernel.
Is 2.5.68 current enough? The problem was even better reproducible
with this kernel than with the old one. So I made all my tests with

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.072 / U:0.072 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site