[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.023 / U:25.992 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site