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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>