[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:

    > >> 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.
    > You're speaking too generally there for me to understand its
    > relevance! What specific problem do you see?

    I had the impression that you rely on SLAB_DESTROY_BY_RCU for more than
    what it gives you. If the lock taken is not directly in the structure that
    is managed by slab but only reachable by a pointer then potential pointer
    changes are also danger to consider.

    I'd be much more comfortable if the following would be done

    A. Pin the anon_vma by either
    I. Take a refcount on the anon vma
    II. Take a lock in the anon vma (something that is not pointed to)

    B. Either
    I. All values that have been used before the pinning are
    verified after the pinning (and the lock is reacquired
    if verification fails).

    II. Or all functions using page_lock_anon_vma() must securely
    work in the case that the anon_vma was reused for
    something else before the vma lock was acquired.

     \ /
      Last update: 2010-08-28 04:49    [W:0.029 / U:15.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site