Andrew Morton writes:
> "Lothar Wassmann" <LW@KARO-electronics.de> 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
2.5.68.
Lothar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:54 EST