[lkml]   [2011]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectPatchwork [084/115] x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm - additional question
    Suresh Siddha described in a TLB related problem: "Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb IPI's while the cr3 is still pointing to the prev mm.  And this window can lead to the possibility of bogus TLB fills resulting in strange failures."

    I was wondering if an error we saw with Lustre described in

    could be attributed to the TLB problem described in 564801? The essence is that during massive parallel I/O sometimes page->private (which is used by Lustre as a pointer to private data) would be set to 2. The only place I found where this could happen OUTSIDE normal Lustre code is free_hot_page (called by page_cache_release). But the page remained in the cache, and when a later readpage() was issued, this lead a NULL pointer kernel panic.

    Architecture is x86_64, RH6 kernel 2.6.32-71.18.1.el6

    thanks for any help

    Michael Hebenstreit Senior Cluster Architect
    Intel Corporation Software and Services Group/HTE
    2800 N Center Dr, DP3-307 Tel.: +1 253 371 3144
    WA 98327, DuPont

     \ /
      Last update: 2011-03-24 17:33    [W:0.022 / U:103.552 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site