All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xishi Qiu <qiuxishi@huawei.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Michal Hocko <mhocko@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
	Minchan Kim <minchan@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	aarcange@redhat.com, sumeet.keswani@hpe.com,
	Rik van Riel <riel@redhat.com>, Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	zhong jiang <zhongjiang@huawei.com>
Subject: Re: mm, something wring in page_lock_anon_vma_read()?
Date: Sat, 20 May 2017 09:21:13 +0800	[thread overview]
Message-ID: <591F9A09.6010707@huawei.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1705191453040.3819@eggly.anvils>

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

> .
> 



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

WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Michal Hocko <mhocko@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Mel Gorman" <mgorman@techsingularity.net>,
	Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
	Minchan Kim <minchan@kernel.org>,
	"David Rientjes" <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>, <aarcange@redhat.com>,
	<sumeet.keswani@hpe.com>, Rik van Riel <riel@redhat.com>,
	Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	zhong jiang <zhongjiang@huawei.com>
Subject: Re: mm, something wring in page_lock_anon_vma_read()?
Date: Sat, 20 May 2017 09:21:13 +0800	[thread overview]
Message-ID: <591F9A09.6010707@huawei.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1705191453040.3819@eggly.anvils>

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

> .
> 

  reply	other threads:[~2017-05-20  1:28 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18  9:46 mm, something wring in page_lock_anon_vma_read()? Xishi Qiu
2017-05-18  9:46 ` Xishi Qiu
2017-05-19  8:52 ` Xishi Qiu
2017-05-19  8:52   ` Xishi Qiu
2017-05-19  9:44   ` Xishi Qiu
2017-05-19  9:44     ` Xishi Qiu
2017-05-19 22:00     ` Hugh Dickins
2017-05-19 22:00       ` Hugh Dickins
2017-05-20  1:21       ` Xishi Qiu [this message]
2017-05-20  1:21         ` Xishi Qiu
2017-05-20  2:02         ` Hugh Dickins
2017-05-20  2:02           ` Hugh Dickins
2017-05-20  2:18           ` Xishi Qiu
2017-05-20  2:18             ` Xishi Qiu
2017-05-20  2:40             ` Hugh Dickins
2017-05-20  2:40               ` Hugh Dickins
2017-05-20  3:01               ` zhong jiang
2017-05-20  3:01                 ` zhong jiang
2017-05-22 16:51                 ` Vlastimil Babka
2017-05-22 16:51                   ` Vlastimil Babka
2017-05-23  9:21                   ` zhong jiang
2017-05-23  9:21                     ` zhong jiang
2017-05-23  9:33                     ` Vlastimil Babka
2017-05-23  9:33                       ` Vlastimil Babka
2017-05-23 10:32                       ` zhong jiang
2017-05-23 10:32                         ` zhong jiang
2017-06-08 13:44                       ` Xishi Qiu
2017-06-08 13:44                         ` Xishi Qiu
2017-06-08 13:59                         ` Vlastimil Babka
2017-06-08 13:59                           ` Vlastimil Babka
2017-06-08 14:11                           ` zhong jiang
2017-06-08 14:11                             ` zhong jiang
2017-07-18 10:59                           ` mm, something wrong " Xishi Qiu
2017-07-18 10:59                             ` Xishi Qiu
2017-07-19  8:40                             ` Vlastimil Babka
2017-07-19  8:40                               ` Vlastimil Babka
2017-07-19  9:59                               ` Xishi Qiu
2017-07-19  9:59                                 ` Xishi Qiu
2017-07-20 12:58                                 ` Andrea Arcangeli
2017-07-20 12:58                                   ` Andrea Arcangeli
2017-07-20 16:15                                   ` Andrea Arcangeli
2017-07-20 16:15                                     ` Andrea Arcangeli
2017-05-22  9:48               ` mm, something wring " Xishi Qiu
2017-05-22  9:48                 ` Xishi Qiu
2017-05-22 19:26                 ` Hugh Dickins
2017-05-22 19:26                   ` Hugh Dickins
2017-05-23  2:19                   ` Xishi Qiu
2017-05-23  2:19                     ` Xishi Qiu
2017-05-23  2:51                     ` Hugh Dickins
2017-05-23  2:51                       ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=591F9A09.6010707@huawei.com \
    --to=qiuxishi@huawei.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=sumeet.keswani@hpe.com \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=zhongjiang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.