On 2017/5/20 6:00, Hugh Dickins wrote:
> On Fri, 19 May 2017, Xishi Qiu wrote:
>> On 2017/5/19 16:52, Xishi Qiu wrote:
>>> On 2017/5/18 17:46, Xishi Qiu wrote:
>>>
>>>> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems
>>>> be freed.
>>>> The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know
>>>> if it
>>>> exists in mainline, any reply is welcome!
>>>>
>>>
>>> When we alloc anon_vma, we will init the value of anon_vma->root,
>>> so can we set anon_vma->root to NULL when calling
>>> anon_vma_free -> kmem_cache_free(anon_vma_cachep, anon_vma);
>>>
>>> anon_vma_free()
>>> ...
>>> anon_vma->root = NULL;
>>> kmem_cache_free(anon_vma_cachep, anon_vma);
>>>
>>> I find if we do this above, system boot failed, why?
>>>
>>
>> If anon_vma was freed, we should not to access the root_anon_vma, because it
>> maybe also
>> freed(e.g. anon_vma == root_anon_vma), right?
>>
>> page_lock_anon_vma_read()
>> ...
>> anon_vma = (struct anon_vma *) (anon_mapping - PAGE_MAPPING_ANON);
>> root_anon_vma = ACCESS_ONCE(anon_vma->root);
>> if (down_read_trylock(&root_anon_vma->rwsem)) { // it's not safe
>> ...
>> if (!atomic_inc_not_zero(&anon_vma->refcount)) { // check anon_vma was
>> not freed
>> ...
>> anon_vma_lock_read(anon_vma); // it's safe
>> ...
>
> You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(),
> and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature
> of the anon_vma_cachep kmem cache. It is not safe to muck with anon_vma->
> root in anon_vma_free(), others could still be looking at it.
>
> Hugh
>
Hi Hugh,
Thanks for your reply.
SLAB_DESTROY_BY_RCU will let it call call_rcu() in free_slab(), but if the
anon_vma *reuse* by someone again, access root_anon_vma is not safe, right?
e.g. if I clean the root pointer before free it, then access root_anon_vma
in page_lock_anon_vma_read() is NULL pointer access, right?
anon_vma_free()
...
anon_vma->root = NULL;
kmem_cache_free(anon_vma_cachep, anon_vma);
...
Thanks,
Xishi Qiu
> .
>
