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: ARCH_PREP_PAGE_BEFORE_READ(page); 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: ARCH_CHECK_READ_PAGE_COHERENCY(page); 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: ARCH_CHECK_BOUNCE_READ_COHERENCY(bio_vec); #define ARCH_CHECK_BOUNCE_READ_COHERENCY(bio_vec) \ ARCH_CHECK_READ_PAGE_COHERENCY(bio_vec->bv_page) Remote DMA based network file systems, e.g. Lustre on Quadrics, Infiniband are also considered to be safe. Thanks, Zoltan - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |