[lkml]   [2010]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] mm: fix hang on anon_vma->root->lock
    On Fri, 27 Aug 2010, Hugh Dickins wrote:

    > >> I do not see a second check (*after* taking the lock) in the patch
    > if (page_mapped(page))
    > return anon_vma;

    As far as I can tell you would have to recheck the mapping pointer and the
    pointer to the root too after taking the lock because only taking the lock
    stabilitzes the object. Any other data you may have obtained before
    acquiring the lock may have changed.

    > >> and the way the lock is taken can be a problem in itself.
    > No, that's what we rely upon SLAB_DESTROY_BY_RCU for.

    SLAB_DESTROY_BY_RCU does not guarantee that the object stays the same nor
    does it prevent any fields from changing. Going through a pointer with
    only SLAB_DESTROY_BY_RCU means that you can only rely on the atomicity
    guarantee for pointer updates. You get a valid pointer but pointer changes
    are not prevented by SLAB_DESTROY_BY_RCU.

    The only guarantee of that would be through other synchronization
    techniques. If you believe that the page lock provides sufficient
    synchronization that then this approach may be ok.

     \ /
      Last update: 2010-08-28 01:09    [W:0.024 / U:11.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site