[PATCH] mm: remove BUG_ON() from mlock_vma_page()

[PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Bob Liu]

This BUG_ON() was triggered when called from try_to_unmap_cluster() which
didn't lock the page.
And it's safe to mlock_vma_page() without PageLocked, so this patch fix this
issue by removing that BUG_ON() simply.

[  253.869145] kernel BUG at mm/mlock.c:82!
[  253.869549] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  253.870098] Dumping ftrace buffer:
[  253.870098]    (ftrace buffer empty)
[  253.870098] Modules linked in:
[  253.870098] CPU: 10 PID: 9162 Comm: trinity-child75 Tainted: G        W
3.13.0-rc4-next-20131216-sasha-00011-g5f105ec-dirty #4137
[  253.873310] task: ffff8800c98cb000 ti: ffff8804d34e8000 task.ti:
ffff8804d34e8000
[  253.873310] RIP: 0010:[<ffffffff81281f28>]  [<ffffffff81281f28>]
mlock_vma_page+0x18/0xc0
[  253.873310] RSP: 0000:ffff8804d34e99e8  EFLAGS: 00010246
[  253.873310] RAX: 006fffff8038002c RBX: ffffea00474944c0 RCX:
ffff880807636000
[  253.873310] RDX: ffffea0000000000 RSI: 00007f17a9bca000 RDI:
ffffea00474944c0
[  253.873310] RBP: ffff8804d34e99f8 R08: ffff880807020000 R09:
0000000000000000
[  253.873310] R10: 0000000000000001 R11: 0000000000002000 R12:
00007f17a9bca000
[  253.873310] R13: ffffea00474944c0 R14: 00007f17a9be0000 R15:
ffff880807020000
[  253.873310] FS:  00007f17aa31a700(0000) GS:ffff8801c9c00000(0000)
knlGS:0000000000000000
[  253.873310] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  253.873310] CR2: 00007f17a94fa000 CR3: 00000004d3b02000 CR4:
00000000000006e0
[  253.873310] DR0: 00007f17a74ca000 DR1: 0000000000000000 DR2:
0000000000000000
[  253.873310] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000600
[  253.873310] Stack:
[  253.873310]  0000000b3de28067 ffff880b3de28e50 ffff8804d34e9aa8
ffffffff8128bc31
[  253.873310]  0000000000000301 ffffea0011850220 ffff8809a4039000
ffffea0011850238
[  253.873310]  ffff8804d34e9aa8 ffff880807636060 0000000000000001
ffff880807636348
[  253.873310] Call Trace:
[  253.873310]  [<ffffffff8128bc31>] try_to_unmap_cluster+0x1c1/0x340
[  253.873310]  [<ffffffff8128c60a>] try_to_unmap_file+0x20a/0x2e0
[  253.873310]  [<ffffffff8128c7b3>] try_to_unmap+0x73/0x90
[  253.873310]  [<ffffffff812b526d>] __unmap_and_move+0x18d/0x250
[  253.873310]  [<ffffffff812b53e9>] unmap_and_move+0xb9/0x180
[  253.873310]  [<ffffffff812b559b>] migrate_pages+0xeb/0x2f0
[  253.873310]  [<ffffffff812a0660>] ? queue_pages_pte_range+0x1a0/0x1a0
[  253.873310]  [<ffffffff812a193c>] migrate_to_node+0x9c/0xc0
[  253.873310]  [<ffffffff812a30b8>] do_migrate_pages+0x1b8/0x240
[  253.873310]  [<ffffffff812a3456>] SYSC_migrate_pages+0x316/0x380
[  253.873310]  [<ffffffff812a31ec>] ? SYSC_migrate_pages+0xac/0x380
[  253.873310]  [<ffffffff811763c6>] ? vtime_account_user+0x96/0xb0
[  253.873310]  [<ffffffff812a34ce>] SyS_migrate_pages+0xe/0x10
[  253.873310]  [<ffffffff843c4990>] tracesys+0xdd/0xe2
[  253.873310] Code: 0f 1f 00 65 48 ff 04 25 10 25 1d 00 48 83 c4 08
5b c9 c3 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 07 48 89 fb
a8 01 75 10 <0f> 0b 66 0f 1f 44 00 00 eb fe 66 0f 1f 44 00 00 f0 0f ba
2f 15
[  253.873310] RIP  [<ffffffff81281f28>] mlock_vma_page+0x18/0xc0
[  253.873310]  RSP <ffff8804d34e99e8>
[  253.904194] ---[ end trace be59c4a7f8edab3f ]---

Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Bob Liu <bob.liu@oracle.com>
---
 mm/mlock.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/mm/mlock.c b/mm/mlock.c
index d480cd6..5488d44 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -79,8 +79,6 @@ void clear_page_mlock(struct page *page)
  */
 void mlock_vma_page(struct page *page)
 {
-	BUG_ON(!PageLocked(page));
-
 	if (!TestSetPageMlocked(page)) {
 		mod_zone_page_state(page_zone(page), NR_MLOCK,
 				    hpage_nr_pages(page));
-- 
1.7.10.4

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Vlastimil Babka]

On 12/18/2013 01:42 AM, Bob Liu wrote:
> This BUG_ON() was triggered when called from try_to_unmap_cluster() which
> didn't lock the page.
> And it's safe to mlock_vma_page() without PageLocked, so this patch fix this
> issue by removing that BUG_ON() simply.

I think it might be correct, but needs better explanation why it's safe. 
The check appeared in both mlock_vma_page and munlock_vma_page since the 
original commit b291f0003. Munlock definitely needs it for 
try_to_munlock(), but mlock doesn't seem to be doing anything that would 
need it.

In case it's really not needed, it might be useful to remove the 
now-useless lock from the callers, if they acquire it just for this call.
I quickly checked:
- follow_trans_huge_pmd only rechecks page->mapping besides calling this
   so it might be a candidate?
- try_to_merge_one_page is definitely a candidate
- follow_page_mask checks page->mapping only outside of the lock, which
   seems strangely different from follow_trans_huge_pmd at first glance.
   So it only does lru_add_drain() under the lock and is probably a
   candidate. Or, it should be rechecking page->mapping as well.


> [  253.869145] kernel BUG at mm/mlock.c:82!
> [  253.869549] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [  253.870098] Dumping ftrace buffer:
> [  253.870098]    (ftrace buffer empty)
> [  253.870098] Modules linked in:
> [  253.870098] CPU: 10 PID: 9162 Comm: trinity-child75 Tainted: G        W
> 3.13.0-rc4-next-20131216-sasha-00011-g5f105ec-dirty #4137
> [  253.873310] task: ffff8800c98cb000 ti: ffff8804d34e8000 task.ti:
> ffff8804d34e8000
> [  253.873310] RIP: 0010:[<ffffffff81281f28>]  [<ffffffff81281f28>]
> mlock_vma_page+0x18/0xc0
> [  253.873310] RSP: 0000:ffff8804d34e99e8  EFLAGS: 00010246
> [  253.873310] RAX: 006fffff8038002c RBX: ffffea00474944c0 RCX:
> ffff880807636000
> [  253.873310] RDX: ffffea0000000000 RSI: 00007f17a9bca000 RDI:
> ffffea00474944c0
> [  253.873310] RBP: ffff8804d34e99f8 R08: ffff880807020000 R09:
> 0000000000000000
> [  253.873310] R10: 0000000000000001 R11: 0000000000002000 R12:
> 00007f17a9bca000
> [  253.873310] R13: ffffea00474944c0 R14: 00007f17a9be0000 R15:
> ffff880807020000
> [  253.873310] FS:  00007f17aa31a700(0000) GS:ffff8801c9c00000(0000)
> knlGS:0000000000000000
> [  253.873310] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  253.873310] CR2: 00007f17a94fa000 CR3: 00000004d3b02000 CR4:
> 00000000000006e0
> [  253.873310] DR0: 00007f17a74ca000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [  253.873310] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000600
> [  253.873310] Stack:
> [  253.873310]  0000000b3de28067 ffff880b3de28e50 ffff8804d34e9aa8
> ffffffff8128bc31
> [  253.873310]  0000000000000301 ffffea0011850220 ffff8809a4039000
> ffffea0011850238
> [  253.873310]  ffff8804d34e9aa8 ffff880807636060 0000000000000001
> ffff880807636348
> [  253.873310] Call Trace:
> [  253.873310]  [<ffffffff8128bc31>] try_to_unmap_cluster+0x1c1/0x340
> [  253.873310]  [<ffffffff8128c60a>] try_to_unmap_file+0x20a/0x2e0
> [  253.873310]  [<ffffffff8128c7b3>] try_to_unmap+0x73/0x90
> [  253.873310]  [<ffffffff812b526d>] __unmap_and_move+0x18d/0x250
> [  253.873310]  [<ffffffff812b53e9>] unmap_and_move+0xb9/0x180
> [  253.873310]  [<ffffffff812b559b>] migrate_pages+0xeb/0x2f0
> [  253.873310]  [<ffffffff812a0660>] ? queue_pages_pte_range+0x1a0/0x1a0
> [  253.873310]  [<ffffffff812a193c>] migrate_to_node+0x9c/0xc0
> [  253.873310]  [<ffffffff812a30b8>] do_migrate_pages+0x1b8/0x240
> [  253.873310]  [<ffffffff812a3456>] SYSC_migrate_pages+0x316/0x380
> [  253.873310]  [<ffffffff812a31ec>] ? SYSC_migrate_pages+0xac/0x380
> [  253.873310]  [<ffffffff811763c6>] ? vtime_account_user+0x96/0xb0
> [  253.873310]  [<ffffffff812a34ce>] SyS_migrate_pages+0xe/0x10
> [  253.873310]  [<ffffffff843c4990>] tracesys+0xdd/0xe2
> [  253.873310] Code: 0f 1f 00 65 48 ff 04 25 10 25 1d 00 48 83 c4 08
> 5b c9 c3 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 07 48 89 fb
> a8 01 75 10 <0f> 0b 66 0f 1f 44 00 00 eb fe 66 0f 1f 44 00 00 f0 0f ba
> 2f 15
> [  253.873310] RIP  [<ffffffff81281f28>] mlock_vma_page+0x18/0xc0
> [  253.873310]  RSP <ffff8804d34e99e8>
> [  253.904194] ---[ end trace be59c4a7f8edab3f ]---
>
> Reported-by: Sasha Levin <sasha.levin@oracle.com>
> Signed-off-by: Bob Liu <bob.liu@oracle.com>
> ---
>   mm/mlock.c |    2 --
>   1 file changed, 2 deletions(-)
>
> diff --git a/mm/mlock.c b/mm/mlock.c
> index d480cd6..5488d44 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -79,8 +79,6 @@ void clear_page_mlock(struct page *page)
>    */
>   void mlock_vma_page(struct page *page)
>   {
> -	BUG_ON(!PageLocked(page));
> -
>   	if (!TestSetPageMlocked(page)) {
>   		mod_zone_page_state(page_zone(page), NR_MLOCK,
>   				    hpage_nr_pages(page));
>

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Bob Liu]

On 12/18/2013 05:36 PM, Vlastimil Babka wrote:
> On 12/18/2013 01:42 AM, Bob Liu wrote:
>> This BUG_ON() was triggered when called from try_to_unmap_cluster() which
>> didn't lock the page.
>> And it's safe to mlock_vma_page() without PageLocked, so this patch
>> fix this
>> issue by removing that BUG_ON() simply.
> 
> I think it might be correct, but needs better explanation why it's safe.
> The check appeared in both mlock_vma_page and munlock_vma_page since the
> original commit b291f0003. Munlock definitely needs it for
> try_to_munlock(), but mlock doesn't seem to be doing anything that would
> need it.
> 
> In case it's really not needed, it might be useful to remove the
> now-useless lock from the callers, if they acquire it just for this call.

Thank you, I will take a look at the place your mentioned.

> I quickly checked:
> - follow_trans_huge_pmd only rechecks page->mapping besides calling this
>   so it might be a candidate?
> - try_to_merge_one_page is definitely a candidate
> - follow_page_mask checks page->mapping only outside of the lock, which
>   seems strangely different from follow_trans_huge_pmd at first glance.
>   So it only does lru_add_drain() under the lock and is probably a
>   candidate. Or, it should be rechecking page->mapping as well.
> 

I'm prefer to make this patch a separate one which just fixing the issue
Sasha reported in case more bugs might be introduced if removed lock
page in other place.

> 
>> [  253.869145] kernel BUG at mm/mlock.c:82!
>> [  253.869549] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> [  253.870098] Dumping ftrace buffer:
>> [  253.870098]    (ftrace buffer empty)
>> [  253.870098] Modules linked in:
>> [  253.870098] CPU: 10 PID: 9162 Comm: trinity-child75 Tainted:
>> G        W
>> 3.13.0-rc4-next-20131216-sasha-00011-g5f105ec-dirty #4137
>> [  253.873310] task: ffff8800c98cb000 ti: ffff8804d34e8000 task.ti:
>> ffff8804d34e8000
>> [  253.873310] RIP: 0010:[<ffffffff81281f28>]  [<ffffffff81281f28>]
>> mlock_vma_page+0x18/0xc0
>> [  253.873310] RSP: 0000:ffff8804d34e99e8  EFLAGS: 00010246
>> [  253.873310] RAX: 006fffff8038002c RBX: ffffea00474944c0 RCX:
>> ffff880807636000
>> [  253.873310] RDX: ffffea0000000000 RSI: 00007f17a9bca000 RDI:
>> ffffea00474944c0
>> [  253.873310] RBP: ffff8804d34e99f8 R08: ffff880807020000 R09:
>> 0000000000000000
>> [  253.873310] R10: 0000000000000001 R11: 0000000000002000 R12:
>> 00007f17a9bca000
>> [  253.873310] R13: ffffea00474944c0 R14: 00007f17a9be0000 R15:
>> ffff880807020000
>> [  253.873310] FS:  00007f17aa31a700(0000) GS:ffff8801c9c00000(0000)
>> knlGS:0000000000000000
>> [  253.873310] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  253.873310] CR2: 00007f17a94fa000 CR3: 00000004d3b02000 CR4:
>> 00000000000006e0
>> [  253.873310] DR0: 00007f17a74ca000 DR1: 0000000000000000 DR2:
>> 0000000000000000
>> [  253.873310] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>> 0000000000000600
>> [  253.873310] Stack:
>> [  253.873310]  0000000b3de28067 ffff880b3de28e50 ffff8804d34e9aa8
>> ffffffff8128bc31
>> [  253.873310]  0000000000000301 ffffea0011850220 ffff8809a4039000
>> ffffea0011850238
>> [  253.873310]  ffff8804d34e9aa8 ffff880807636060 0000000000000001
>> ffff880807636348
>> [  253.873310] Call Trace:
>> [  253.873310]  [<ffffffff8128bc31>] try_to_unmap_cluster+0x1c1/0x340
>> [  253.873310]  [<ffffffff8128c60a>] try_to_unmap_file+0x20a/0x2e0
>> [  253.873310]  [<ffffffff8128c7b3>] try_to_unmap+0x73/0x90
>> [  253.873310]  [<ffffffff812b526d>] __unmap_and_move+0x18d/0x250
>> [  253.873310]  [<ffffffff812b53e9>] unmap_and_move+0xb9/0x180
>> [  253.873310]  [<ffffffff812b559b>] migrate_pages+0xeb/0x2f0
>> [  253.873310]  [<ffffffff812a0660>] ? queue_pages_pte_range+0x1a0/0x1a0
>> [  253.873310]  [<ffffffff812a193c>] migrate_to_node+0x9c/0xc0
>> [  253.873310]  [<ffffffff812a30b8>] do_migrate_pages+0x1b8/0x240
>> [  253.873310]  [<ffffffff812a3456>] SYSC_migrate_pages+0x316/0x380
>> [  253.873310]  [<ffffffff812a31ec>] ? SYSC_migrate_pages+0xac/0x380
>> [  253.873310]  [<ffffffff811763c6>] ? vtime_account_user+0x96/0xb0
>> [  253.873310]  [<ffffffff812a34ce>] SyS_migrate_pages+0xe/0x10
>> [  253.873310]  [<ffffffff843c4990>] tracesys+0xdd/0xe2
>> [  253.873310] Code: 0f 1f 00 65 48 ff 04 25 10 25 1d 00 48 83 c4 08
>> 5b c9 c3 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 07 48 89 fb
>> a8 01 75 10 <0f> 0b 66 0f 1f 44 00 00 eb fe 66 0f 1f 44 00 00 f0 0f ba
>> 2f 15
>> [  253.873310] RIP  [<ffffffff81281f28>] mlock_vma_page+0x18/0xc0
>> [  253.873310]  RSP <ffff8804d34e99e8>
>> [  253.904194] ---[ end trace be59c4a7f8edab3f ]---
>>
>> Reported-by: Sasha Levin <sasha.levin@oracle.com>
>> Signed-off-by: Bob Liu <bob.liu@oracle.com>
>> ---
>>   mm/mlock.c |    2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/mm/mlock.c b/mm/mlock.c
>> index d480cd6..5488d44 100644
>> --- a/mm/mlock.c
>> +++ b/mm/mlock.c
>> @@ -79,8 +79,6 @@ void clear_page_mlock(struct page *page)
>>    */
>>   void mlock_vma_page(struct page *page)
>>   {
>> -    BUG_ON(!PageLocked(page));
>> -
>>       if (!TestSetPageMlocked(page)) {
>>           mod_zone_page_state(page_zone(page), NR_MLOCK,
>>                       hpage_nr_pages(page));
>>
> 

-- 
Regards,
-Bob

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

RE: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Motohiro Kosaki]

> 
> diff --git a/mm/mlock.c b/mm/mlock.c
> index d480cd6..5488d44 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -79,8 +79,6 @@ void clear_page_mlock(struct page *page)
>   */
>  void mlock_vma_page(struct page *page)
>  {
> -	BUG_ON(!PageLocked(page));
> -
>  	if (!TestSetPageMlocked(page)) {
>  		mod_zone_page_state(page_zone(page), NR_MLOCK,
>  				    hpage_nr_pages(page));
> --
> 1.7.10.4

Acked-by: KOSAKI Motohiro <Kosaki.motohiro@jp.fujitsu.com>


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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Andrew Morton]

On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu <lliubbo@gmail.com> wrote:

> This BUG_ON() was triggered when called from try_to_unmap_cluster() which
> didn't lock the page.
> And it's safe to mlock_vma_page() without PageLocked, so this patch fix this
> issue by removing that BUG_ON() simply.
> 
> [  253.869145] kernel BUG at mm/mlock.c:82!
>
> ...
>
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -79,8 +79,6 @@ void clear_page_mlock(struct page *page)
>   */
>  void mlock_vma_page(struct page *page)
>  {
> -	BUG_ON(!PageLocked(page));
> -
>  	if (!TestSetPageMlocked(page)) {
>  		mod_zone_page_state(page_zone(page), NR_MLOCK,
>  				    hpage_nr_pages(page));

The b291f000393f5a0b67901 changelog is pretty remarkable.  It's not
entirely clear who ended up originating this patch - either Rik or
Lee.

Why do we assert PAGE_Locked() in munlock_vma_page()?

I agree with Vlastimil that we should remove now-unneeded lock_page()s
from callers.

The patch is of course worrisome.  It's going to take quite some effort
to review its safety and I'm disinclined to merge this into 3.13.  Has
this bug really been there since 2008?

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Andrew Morton]

On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu <lliubbo@gmail.com> wrote:

> This BUG_ON() was triggered when called from try_to_unmap_cluster() which
> didn't lock the page.
> And it's safe to mlock_vma_page() without PageLocked, so this patch fix this
> issue by removing that BUG_ON() simply.
> 

This patch doesn't appear to be going anywhere, so I will drop it. 
Please let's check to see whether the bug still exists and if so, start
another round of bugfixing.


From: Bob Liu <lliubbo@gmail.com>
Subject: mm: remove BUG_ON() from mlock_vma_page()

objrmap doesn't work for nonlinear VMAs because the assumption that
offset-into-file correlates with offset-into-virtual-addresses does not
hold.  Hence what try_to_unmap_cluster does is a mini "virtual scan" of
each nonlinear VMA which maps the file to which the target page belongs. 
If vma locked, mlock the pages in the cluster, rather than unmapping them.
However, not all pages are guarantee page locked instead of the check
page, resulting in the below BUG_ON().

It's safe to mlock_vma_page() without PageLocked, so fix this issue by
removing that BUG_ON().

[  253.869145] kernel BUG at mm/mlock.c:82!
[  253.869549] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  253.870098] Dumping ftrace buffer:
[  253.870098]    (ftrace buffer empty)
[  253.870098] Modules linked in:
[  253.870098] CPU: 10 PID: 9162 Comm: trinity-child75 Tainted: G        W 3.13.0-rc4-next-20131216-sasha-00011-g5f105ec-dirty #4137
[  253.873310] task: ffff8800c98cb000 ti: ffff8804d34e8000 task.ti: ffff8804d34e8000
[  253.873310] RIP: 0010:[<ffffffff81281f28>]  [<ffffffff81281f28>] mlock_vma_page+0x18/0xc0
[  253.873310] RSP: 0000:ffff8804d34e99e8  EFLAGS: 00010246
[  253.873310] RAX: 006fffff8038002c RBX: ffffea00474944c0 RCX: ffff880807636000
[  253.873310] RDX: ffffea0000000000 RSI: 00007f17a9bca000 RDI: ffffea00474944c0
[  253.873310] RBP: ffff8804d34e99f8 R08: ffff880807020000 R09: 0000000000000000
[  253.873310] R10: 0000000000000001 R11: 0000000000002000 R12: 00007f17a9bca000
[  253.873310] R13: ffffea00474944c0 R14: 00007f17a9be0000 R15: ffff880807020000
[  253.873310] FS:  00007f17aa31a700(0000) GS:ffff8801c9c00000(0000) knlGS:0000000000000000
[  253.873310] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  253.873310] CR2: 00007f17a94fa000 CR3: 00000004d3b02000 CR4: 00000000000006e0
[  253.873310] DR0: 00007f17a74ca000 DR1: 0000000000000000 DR2: 0000000000000000
[  253.873310] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
[  253.873310] Stack:
[  253.873310]  0000000b3de28067 ffff880b3de28e50 ffff8804d34e9aa8 ffffffff8128bc31
[  253.873310]  0000000000000301 ffffea0011850220 ffff8809a4039000 ffffea0011850238
[  253.873310]  ffff8804d34e9aa8 ffff880807636060 0000000000000001 ffff880807636348
[  253.873310] Call Trace:
[  253.873310]  [<ffffffff8128bc31>] try_to_unmap_cluster+0x1c1/0x340
[  253.873310]  [<ffffffff8128c60a>] try_to_unmap_file+0x20a/0x2e0
[  253.873310]  [<ffffffff8128c7b3>] try_to_unmap+0x73/0x90
[  253.873310]  [<ffffffff812b526d>] __unmap_and_move+0x18d/0x250
[  253.873310]  [<ffffffff812b53e9>] unmap_and_move+0xb9/0x180
[  253.873310]  [<ffffffff812b559b>] migrate_pages+0xeb/0x2f0
[  253.873310]  [<ffffffff812a0660>] ? queue_pages_pte_range+0x1a0/0x1a0
[  253.873310]  [<ffffffff812a193c>] migrate_to_node+0x9c/0xc0
[  253.873310]  [<ffffffff812a30b8>] do_migrate_pages+0x1b8/0x240
[  253.873310]  [<ffffffff812a3456>] SYSC_migrate_pages+0x316/0x380
[  253.873310]  [<ffffffff812a31ec>] ? SYSC_migrate_pages+0xac/0x380
[  253.873310]  [<ffffffff811763c6>] ? vtime_account_user+0x96/0xb0
[  253.873310]  [<ffffffff812a34ce>] SyS_migrate_pages+0xe/0x10
[  253.873310]  [<ffffffff843c4990>] tracesys+0xdd/0xe2
[  253.873310] Code: 0f 1f 00 65 48 ff 04 25 10 25 1d 00 48 83 c4 08
5b c9 c3 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 07 48 89 fb
a8 01 75 10 <0f> 0b 66 0f 1f 44 00 00 eb fe 66 0f 1f 44 00 00 f0 0f ba
2f 15
[  253.873310] RIP  [<ffffffff81281f28>] mlock_vma_page+0x18/0xc0
[  253.873310]  RSP <ffff8804d34e99e8>
[  253.904194] ---[ end trace be59c4a7f8edab3f ]---

Signed-off-by: Bob Liu <bob.liu@oracle.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/mlock.c |    2 --
 1 file changed, 2 deletions(-)

diff -puN mm/mlock.c~mm-remove-bug_on-from-mlock_vma_page mm/mlock.c
--- a/mm/mlock.c~mm-remove-bug_on-from-mlock_vma_page
+++ a/mm/mlock.c
@@ -79,8 +79,6 @@ void clear_page_mlock(struct page *page)
  */
 void mlock_vma_page(struct page *page)
 {
-	BUG_ON(!PageLocked(page));
-
 	if (!TestSetPageMlocked(page)) {
 		mod_zone_page_state(page_zone(page), NR_MLOCK,
 				    hpage_nr_pages(page));
_

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Sasha Levin]

On 01/31/2014 03:33 PM, Andrew Morton wrote:
> On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu<lliubbo@gmail.com>  wrote:
>
>> >This BUG_ON() was triggered when called from try_to_unmap_cluster() which
>> >didn't lock the page.
>> >And it's safe to mlock_vma_page() without PageLocked, so this patch fix this
>> >issue by removing that BUG_ON() simply.
>> >
> This patch doesn't appear to be going anywhere, so I will drop it.
> Please let's check to see whether the bug still exists and if so, start
> another round of bugfixing.

This bug still happens on the latest -next kernel.


Thanks,
Sasha

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

RE: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Motohiro Kosaki]

> -----Original Message-----
> From: Sasha Levin [mailto:sasha.levin@oracle.com]
> Sent: Sunday, February 23, 2014 2:32 PM
> To: Andrew Morton; Bob Liu
> Cc: linux-mm@kvack.org; walken@google.com; Motohiro Kosaki JP;
> riel@redhat.com; vbabka@suse.cz; stable@kernel.org;
> gregkh@linuxfoundation.org; Bob Liu
> Subject: Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()
> 
> On 01/31/2014 03:33 PM, Andrew Morton wrote:
> > On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu<lliubbo@gmail.com>  wrote:
> >
> >> >This BUG_ON() was triggered when called from try_to_unmap_cluster()
> >> >which didn't lock the page.
> >> >And it's safe to mlock_vma_page() without PageLocked, so this patch
> >> >fix this issue by removing that BUG_ON() simply.
> >> >
> > This patch doesn't appear to be going anywhere, so I will drop it.
> > Please let's check to see whether the bug still exists and if so,
> > start another round of bugfixing.
> 
> This bug still happens on the latest -next kernel.

Yeah, I recognized it. I'm preparing new patch. Thanks.

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Vlastimil Babka]

On 02/24/2014 06:57 PM, Motohiro Kosaki wrote:
>
>
>> -----Original Message-----
>> From: Sasha Levin [mailto:sasha.levin@oracle.com]
>> Sent: Sunday, February 23, 2014 2:32 PM
>> To: Andrew Morton; Bob Liu
>> Cc: linux-mm@kvack.org; walken@google.com; Motohiro Kosaki JP;
>> riel@redhat.com; vbabka@suse.cz; stable@kernel.org;
>> gregkh@linuxfoundation.org; Bob Liu
>> Subject: Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()
>>
>> On 01/31/2014 03:33 PM, Andrew Morton wrote:
>>> On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu<lliubbo@gmail.com>  wrote:
>>>
>>>>> This BUG_ON() was triggered when called from try_to_unmap_cluster()
>>>>> which didn't lock the page.
>>>>> And it's safe to mlock_vma_page() without PageLocked, so this patch
>>>>> fix this issue by removing that BUG_ON() simply.
>>>>>
>>> This patch doesn't appear to be going anywhere, so I will drop it.
>>> Please let's check to see whether the bug still exists and if so,
>>> start another round of bugfixing.
>>
>> This bug still happens on the latest -next kernel.
>
> Yeah, I recognized it. I'm preparing new patch. Thanks.

What will be your approach? After we had the discussion some month ago 
about m(un)lock vs migration I've concluded that there is no race that 
page lock helps, and removing the BUG_ON() would be indeed correct. Just 
needs to be correctly explained and documentation updated as well.

Vlastimil

> --
> 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=ilto:"dont@kvack.org"> email@kvack.org </a>
>

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Dave Jones]

On Mon, Mar 03, 2014 at 05:12:25PM +0100, Vlastimil Babka wrote:

 > >> On 01/31/2014 03:33 PM, Andrew Morton wrote:
 > >>> On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu<lliubbo@gmail.com>  wrote:
 > >>>
 > >>>>> This BUG_ON() was triggered when called from try_to_unmap_cluster()
 > >>>>> which didn't lock the page.
 > >>>>> And it's safe to mlock_vma_page() without PageLocked, so this patch
 > >>>>> fix this issue by removing that BUG_ON() simply.
 > >>>>>
 > >>> This patch doesn't appear to be going anywhere, so I will drop it.
 > >>> Please let's check to see whether the bug still exists and if so,
 > >>> start another round of bugfixing.
 > >>
 > >> This bug still happens on the latest -next kernel.
 > >
 > > Yeah, I recognized it. I'm preparing new patch. Thanks.
 > 
 > What will be your approach? After we had the discussion some month ago 
 > about m(un)lock vs migration I've concluded that there is no race that 
 > page lock helps, and removing the BUG_ON() would be indeed correct. Just 
 > needs to be correctly explained and documentation updated as well.

This is not just a -next problem btw, I just hit this in 3.14-rc6

	Dave

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Bob Liu]

On 03/12/2014 02:43 AM, Dave Jones wrote:
> On Mon, Mar 03, 2014 at 05:12:25PM +0100, Vlastimil Babka wrote:
> 
>  > >> On 01/31/2014 03:33 PM, Andrew Morton wrote:
>  > >>> On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu<lliubbo@gmail.com>  wrote:
>  > >>>
>  > >>>>> This BUG_ON() was triggered when called from try_to_unmap_cluster()
>  > >>>>> which didn't lock the page.
>  > >>>>> And it's safe to mlock_vma_page() without PageLocked, so this patch
>  > >>>>> fix this issue by removing that BUG_ON() simply.
>  > >>>>>
>  > >>> This patch doesn't appear to be going anywhere, so I will drop it.
>  > >>> Please let's check to see whether the bug still exists and if so,
>  > >>> start another round of bugfixing.
>  > >>
>  > >> This bug still happens on the latest -next kernel.
>  > >
>  > > Yeah, I recognized it. I'm preparing new patch. Thanks.
>  > 
>  > What will be your approach? After we had the discussion some month ago 
>  > about m(un)lock vs migration I've concluded that there is no race that 
>  > page lock helps, and removing the BUG_ON() would be indeed correct. Just 
>  > needs to be correctly explained and documentation updated as well.
> 
> This is not just a -next problem btw, I just hit this in 3.14-rc6
> 

It seems the fix patch from Vlastimil was missed, I've resend it to Andrew.

-- 
Regards,
-Bob

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

Re: [PATCH] mm: remove BUG_ON() from mlock_vma_page()

[Vlastimil Babka]

On 03/20/2014 10:18 AM, Bob Liu wrote:
>
> On 03/12/2014 02:43 AM, Dave Jones wrote:
>> On Mon, Mar 03, 2014 at 05:12:25PM +0100, Vlastimil Babka wrote:
>>
>>   > >> On 01/31/2014 03:33 PM, Andrew Morton wrote:
>>   > >>> On Wed, 18 Dec 2013 08:42:49 +0800 Bob Liu<lliubbo@gmail.com>  wrote:
>>   > >>>
>>   > >>>>> This BUG_ON() was triggered when called from try_to_unmap_cluster()
>>   > >>>>> which didn't lock the page.
>>   > >>>>> And it's safe to mlock_vma_page() without PageLocked, so this patch
>>   > >>>>> fix this issue by removing that BUG_ON() simply.
>>   > >>>>>
>>   > >>> This patch doesn't appear to be going anywhere, so I will drop it.
>>   > >>> Please let's check to see whether the bug still exists and if so,
>>   > >>> start another round of bugfixing.
>>   > >>
>>   > >> This bug still happens on the latest -next kernel.
>>   > >
>>   > > Yeah, I recognized it. I'm preparing new patch. Thanks.
>>   >
>>   > What will be your approach? After we had the discussion some month ago
>>   > about m(un)lock vs migration I've concluded that there is no race that
>>   > page lock helps, and removing the BUG_ON() would be indeed correct. Just
>>   > needs to be correctly explained and documentation updated as well.
>>
>> This is not just a -next problem btw, I just hit this in 3.14-rc6
>>
>
> It seems the fix patch from Vlastimil was missed, I've resend it to Andrew.

Well, there was a followup discussion with Motohiro Kosaki that 
convinced me to go with the "remove BUG_ON()" again, but I didn't get to 
it yet to thoroughly check that it's indeed safe.
However, my patch could work around the issue until we decide that page 
lock is indeed not needed. Which should still happen one way or another, 
because as Motohiro also pointed out, current munlock code already does 
PageMlocked flag manipulation without page lock.
So thanks for resend.

Vlastimil

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