[Top] [All Lists]

Re: problems on D-cache alias in 2.4.22

To: wuming <>
Subject: Re: problems on D-cache alias in 2.4.22
From: Peter Horton <>
Date: Fri, 14 May 2004 08:52:42 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mozilla Thunderbird 0.6 (Windows/20040502)
wuming wrote:

I have understood the phenomenon, and I think this is a kernel's bug.
The real wrong place is not the judgement for condition "PG_dcache_dirty"
in function __update_cache( ).
in file mm/filemap.c and function filemap_nopage( ):
        * Try read-ahead for sequential areas.
       if (VM_SequentialReadHint(area))
               nopage_sequential_readahead(area, pgoff, size);
/* * Found the page and have a reference on it, need to check sharing
        * and possibly copy it over to another page..
       return page;

flush_page_to_ram( ) has not been used for a long time, and in kernel 2.4.22
#define flush_page_to_ram(page)         do { } while (0)

so the mapped page has not been flushed to ram, and the user space will not
know the latest data in the page.
the flush_page_to_ram( ) should be replaced by flush_dcache_page( ),
and if the flush_dcache_page( ) does not really flush the cache, it will set the PG_dcache_dirty, and the real flush will be postponed to __update_cache( ). and if there is not the flush_dcache_page( ) here, no one will set the PG_dcache_dirty, and __update_cache( ) will not flush the page too, so the D-cache aliasing happens.

at last, when I replaced flush_page_to_ram( ) with flush_dcache_page( ),
the internal compiler error disappeared.

I hope your problem will be solved by this way too. God bless you! :-)

This is probably just hiding your problem. flush_page_to_ram() is not used anymore.


<Prev in Thread] Current Thread [Next in Thread>