[lkml]   [2007]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUGFIX]{PATCH] flush icache on ia64 take2
KAMEZAWA Hiroyuki wrote:

> Then, what should I do more for fixing this SIGILL problem ?
> -Kame

I can think of a relatively cheap solution:

New pages are allocated with the bit PG_arch_1 off, see
page_cache_read() ... prep_new_page(), i.e. the I-cache is
not coherent with the D-cache.

page_cache_read() should add a macro, say:


before actually calling mapping->a_ops->readpage(file, page).

This macro can be for ia64 something like:

do { if (CPU_has_split_L2_I_cache) set_bit(PG_arch_1, &page->flags); }

and empty for the the architectures non concerned.

The file systems which are identified not to use HW tools to
avoid split I-cache incoherency, e.g. nfs_readpage(), are required
to add a macro, say:


This macro can be for ia64:

do { if (CPU_has_split_L2_I_cache) clear_bit(PG_arch_1, &page->flags); }

and empty for the the architectures non concerned.

Back to do_no_page():
if the new PTE includes the exec bit and PG_arch_1 is set,
the page has to be flushed from the I-cache before the PTE is
made globally visible.

File systems using local block devices with DMA are considered
to be safe, with the exceptions of the bounce buffers.

When you copy into the destination page, another macro should be
added, say:



Remote DMA based network file systems, e.g. Lustre on Quadrics,
Infiniband are also considered to be safe.


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: 2007-07-19 14:07    [W:0.220 / U:5.460 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site