On Sun, May 27, 2007 at 11:49:30AM +0100, Russell King wrote:
> * - the hole is:
>
> void do_generic_mapping_read(struct address_space *mapping,
> struct file_ra_state *_ra,
> struct file *filp,
> loff_t *ppos,
> read_descriptor_t *desc,
> read_actor_t actor)
> {
> ...
> /* If users can be writing to this page using arbitrary
> * virtual addresses, take care about potential aliasing
> * before reading the page on the kernel side.
> */
> if (mapping_writably_mapped(mapping))
> flush_dcache_page(page);
>
> is false for both read calls, since at the time this test is done, there
> are no shared writable mappings. However, that's not to say that there
> haven't _been_ shared writable mappings.
If I make the flush_dcache_page() call above unconditional, then
the program I posted to this list previously[*] starts reliably
printing secondsecondsec as the third line.
David's check_dcache_page() suggestion makes a lot of sense to me.
Whether this solves the db4 corruption issues I've been seeing is
another matter...
[*] http://www.wantstofly.org/~buytenh/cache-issue2.c
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
