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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
