[lkml]   [2010]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmas of a mergeable VMA
    On 04/11/2010 01:16 PM, Linus Torvalds wrote:

    > NOTE! If this is the race, then the hack really is just a hack, because it
    > doesn't really solve anything. We still take the spinlock, and if bad
    > things has happened, _that_ can still very much fail, and you get the
    > watchdog lockup message instead. So this doesn't really fix anything.

    Looking around the code some more, zap_pte_range()
    calls page_remove_rmap(), which leaves the
    page->mapping in place and has this comment:

    * It would be tidy to reset the PageAnon mapping here,
    * but that might overwrite a racing page_add_anon_rmap
    * which increments mapcount after us but sets mapping
    * before us: so leave the reset to free_hot_cold_page,
    * and remember that it's only reliable while mapped.
    * Leaving it set also helps swapoff to reinstate ptes
    * faster for those pages still in swapcache.

    I wonder if we can clear page->mapping here, if
    list_is_singular(anon_vma->head). That way we
    will not leave stale pointers behind.

    Adding another VMA to the anon_vma can happen
    at fork time - which will not happen simultaneously
    with exit or munmap, because the mmap_sem is taken
    for write during either code path.

    Am I overlooking something here?

     \ /
      Last update: 2010-04-11 21:53    [W:0.027 / U:32.848 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site