mm: kernel BUG at mm/mlock.c:82!

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've
stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                page = vm_normal_page(vma, address, *pte);
                BUG_ON(!page || PageAnon(page));

                if (locked_vma) {
                        mlock_vma_page(page);   /* no-op if already
mlocked */
                        if (page == check_page)
                                ret = SWAP_MLOCK;
                        continue;       /* don't unmap */
                }

And the BUG triggers once we see that 'page' isn't locked.

I couldn't find anything that recently changed in those codepaths, so I'm a bit lost.

[  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-rc
4-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:000000000000
0000
[  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 ]---

Signature · 4 lines

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

cc'd more people.

Quoted 19 lines · Sasha Levin

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've
stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                 page = vm_normal_page(vma, address, *pte);
                 BUG_ON(!page || PageAnon(page));

                 if (locked_vma) {
                         mlock_vma_page(page);   /* no-op if already
mlocked */
                         if (page == check_page)
                                 ret = SWAP_MLOCK;
                         continue;       /* don't unmap */
                 }

Quoted 2 lines

And the BUG triggers once we see that 'page' isn't locked.

Yes, I didn't see any place locked the corresponding page in try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock. How about just remove the BUG_ON() in mlock_vma_page()?

Quoted 25 lines · Bob Liu

cc'd more people.

Quoted 21 lines · Sasha Levin

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've
stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                page = vm_normal_page(vma, address, *pte);
                BUG_ON(!page || PageAnon(page));

                if (locked_vma) {
                        mlock_vma_page(page);   /* no-op if already
mlocked */
                        if (page == check_page)
                                ret = SWAP_MLOCK;
                        continue;       /* don't unmap */
                }

And the BUG triggers once we see that 'page' isn't locked.

Quoted 5 lines

Yes, I didn't see any place locked the corresponding page in try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock. How about just remove the BUG_ON() in mlock_vma_page()?

Welp, it's been there for 5 years now - there should be a good reason to justify removing it.

Thanks,
Sasha

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

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wanpeng Li
Sent: Tuesday, December 17, 2013 3:27 AM
To: Sasha Levin
Cc: Bob Liu; Andrew Morton; [email protected]; Michel Lespinasse; [email protected]; Motohiro Kosaki JP; [email protected]
Subject: Re: mm: kernel BUG at mm/mlock.c:82!

Hi Sasha,

Quoted 31 lines · Sasha Levin

Quoted 29 lines · Bob Liu

cc'd more people.

Quoted 18 lines · Sasha Levin

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                page = vm_normal_page(vma, address, *pte);
                BUG_ON(!page || PageAnon(page));

                if (locked_vma) {
                        mlock_vma_page(page);   /* no-op if already
mlocked */
                        if (page == check_page)
                                ret = SWAP_MLOCK;
                        continue;       /* don't unmap */
                }

Quoted 2 lines

And the BUG triggers once we see that 'page' isn't locked.

Yes, I didn't see any place locked the corresponding page in try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock. How about just remove the BUG_ON() in mlock_vma_page()?

Quoted 1 line

Welp, it's been there for 5 years now - there should be a good reason to

justify removing it.

Quoted 1 line

Page should be locked before invoke try_to_unmap(), this check can't be removed since this bug is just triggered by confirm !check page hold page lock in virtual scan during nolinear VMAs pages aging. Avoid to confirm !check page hold page lock is acceptable.

Quoted 48 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wanpeng Li
Sent: Tuesday, December 17, 2013 3:27 AM
To: Sasha Levin
Cc: Bob Liu; Andrew Morton; [email protected]; Michel Lespinasse; [email protected]; Motohiro Kosaki JP; [email protected]
Subject: Re: mm: kernel BUG at mm/mlock.c:82!

Hi Sasha,

Quoted 25 lines · Sasha Levin

Quoted 24 lines · Bob Liu

cc'd more people.

Quoted 20 lines · Sasha Levin

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                page = vm_normal_page(vma, address, *pte);
                BUG_ON(!page || PageAnon(page));

                if (locked_vma) {
                        mlock_vma_page(page);   /* no-op if already
mlocked */
                        if (page == check_page)
                                ret = SWAP_MLOCK;
                        continue;       /* don't unmap */
                }

And the BUG triggers once we see that 'page' isn't locked.

Quoted 7 lines

Quoted 5 lines

Yes, I didn't see any place locked the corresponding page in try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock. How about just remove the BUG_ON() in mlock_vma_page()?

Welp, it's been there for 5 years now - there should be a good reason to

justify removing it.

Quoted 1 line

Quoted 4 lines

Page should be locked before invoke try_to_unmap(), this check can't be removed since this bug is just triggered by confirm !check page hold page lock in virtual scan during nolinear VMAs pages aging. Avoid to confirm !check page hold page lock is acceptable.

That's a try_to_unmap()'s assumption and it already have BUG_ON(!PageLocked(page)).
We can remove wrong BUG_ON from mlock_vma_page() simply. Mlock_vma_page() doesn't depend on page-locked.

Hi Motohiro,

Quoted 53 lines · Motohiro Kosaki

Quoted 52 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wanpeng Li
Sent: Tuesday, December 17, 2013 3:27 AM
To: Sasha Levin
Cc: Bob Liu; Andrew Morton; [email protected]; Michel Lespinasse; [email protected]; Motohiro Kosaki JP; [email protected]
Subject: Re: mm: kernel BUG at mm/mlock.c:82!

Hi Sasha,

Quoted 25 lines · Sasha Levin

Quoted 24 lines · Bob Liu

cc'd more people.

Quoted 20 lines · Sasha Levin

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                page = vm_normal_page(vma, address, *pte);
                BUG_ON(!page || PageAnon(page));

                if (locked_vma) {
                        mlock_vma_page(page);   /* no-op if already
mlocked */
                        if (page == check_page)
                                ret = SWAP_MLOCK;
                        continue;       /* don't unmap */
                }

And the BUG triggers once we see that 'page' isn't locked.

Quoted 7 lines

Quoted 5 lines

Yes, I didn't see any place locked the corresponding page in try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock. How about just remove the BUG_ON() in mlock_vma_page()?

Welp, it's been there for 5 years now - there should be a good reason to

justify removing it.

Quoted 1 line

Page should be locked before invoke try_to_unmap(), this check can't be removed since this bug is just triggered by confirm !check page hold page lock in virtual scan during nolinear VMAs pages aging. Avoid to confirm !check page hold page lock is acceptable.

Quoted 3 lines

That's a try_to_unmap()'s assumption and it already have BUG_ON(!PageLocked(page)).
We can remove wrong BUG_ON from mlock_vma_page() simply. Mlock_vma_page() doesn't depend on page-locked.

There is a race between mlock_vma_page() and munlock_vma_page(). Both of them should hold page lock and have a BUG_ON assumption.

Hi Motohiro,

Quoted 53 lines · Motohiro Kosaki

Quoted 52 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wanpeng Li
Sent: Tuesday, December 17, 2013 3:27 AM
To: Sasha Levin
Cc: Bob Liu; Andrew Morton; [email protected]; Michel Lespinasse; [email protected]; Motohiro Kosaki JP; [email protected]
Subject: Re: mm: kernel BUG at mm/mlock.c:82!

Hi Sasha,

Quoted 25 lines · Sasha Levin

Quoted 24 lines · Bob Liu

cc'd more people.

Quoted 20 lines · Sasha Levin

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                 page = vm_normal_page(vma, address, *pte);
                 BUG_ON(!page || PageAnon(page));

                 if (locked_vma) {
                         mlock_vma_page(page);   /* no-op if already
mlocked */
                         if (page == check_page)
                                 ret = SWAP_MLOCK;
                         continue;       /* don't unmap */
                 }

And the BUG triggers once we see that 'page' isn't locked.

Quoted 7 lines

Quoted 5 lines

Yes, I didn't see any place locked the corresponding page in try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock. How about just remove the BUG_ON() in mlock_vma_page()?

Welp, it's been there for 5 years now - there should be a good reason to

justify removing it.

Quoted 1 line

Page should be locked before invoke try_to_unmap(), this check can't be removed since this bug is just triggered by confirm !check page hold page lock in virtual scan during nolinear VMAs pages aging. Avoid to confirm !check page hold page lock is acceptable.

Quoted 3 lines

That's a try_to_unmap()'s assumption and it already have BUG_ON(!PageLocked(page)).
We can remove wrong BUG_ON from mlock_vma_page() simply. Mlock_vma_page() doesn't depend on page-locked.

There is a race between mlock_vma_page() and munlock_vma_page(). Both of them should hold page lock and have a BUG_ON assumption.

Regards,
Wanpeng Li

Quoted 1 line

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

-----Original Message-----
From: Wanpeng Li [mailto:[email protected]]
Sent: Tuesday, December 17, 2013 9:03 PM
To: Motohiro Kosaki
Cc: Bob Liu; Andrew Morton; [email protected]; Michel Lespinasse; [email protected]; Motohiro Kosaki JP; [email protected]; Sasha Levin
Subject: Re: mm: kernel BUG at mm/mlock.c:82!

Hi Motohiro,

Quoted 4 lines · Motohiro Kosaki

Quoted 4 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]

On

Quoted 50 lines

Quoted 49 lines

Behalf Of Wanpeng Li
Sent: Tuesday, December 17, 2013 3:27 AM
To: Sasha Levin
Cc: Bob Liu; Andrew Morton; [email protected]; Michel Lespinasse; [email protected]; Motohiro Kosaki JP; [email protected]
Subject: Re: mm: kernel BUG at mm/mlock.c:82!

Hi Sasha,

Quoted 25 lines · Sasha Levin

Quoted 24 lines · Bob Liu

cc'd more people.

Quoted 20 lines · Sasha Levin

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

                page = vm_normal_page(vma, address, *pte);
                BUG_ON(!page || PageAnon(page));

                if (locked_vma) {
                        mlock_vma_page(page);   /* no-op if already
mlocked */
                        if (page == check_page)
                                ret = SWAP_MLOCK;
                        continue;       /* don't unmap */
                }

And the BUG triggers once we see that 'page' isn't locked.

Quoted 8 lines

Quoted 5 lines

Yes, I didn't see any place locked the corresponding page in try_to_unmap_cluster().

I'm afraid adding lock_page() over there may cause potential deadlock. How about just remove the BUG_ON() in mlock_vma_page()?

Welp, it's been there for 5 years now - there should be a good reason to

justify removing it.

Quoted 1 line

Page should be locked before invoke try_to_unmap(), this check can't be removed since this bug is just triggered by confirm !check page hold page lock in virtual scan during nolinear VMAs pages aging. Avoid to confirm !check page hold page lock is acceptable.

Quoted 1 line

That's a try_to_unmap()'s assumption and it already have

BUG_ON(!PageLocked(page)).

Quoted 1 line

We can remove wrong BUG_ON from mlock_vma_page() simply.

Mlock_vma_page() doesn't depend on page-locked.

Quoted 1 line

There is a race between mlock_vma_page() and munlock_vma_page(). Both of them should hold page lock and have a BUG_ON assumption.

Hi all,

While fuzzing with trinity inside a KVM tools guest running latest -next kernel, I've stumbled on the following spew.

Codewise, it's pretty straightforward. In try_to_unmap_cluster():

               page = vm_normal_page(vma, address, *pte);
               BUG_ON(!page || PageAnon(page));

               if (locked_vma) {
                       mlock_vma_page(page);   /* no-op if already mlocked */
                       if (page == check_page)
                               ret = SWAP_MLOCK;
                       continue;       /* don't unmap */
               }

And the BUG triggers once we see that 'page' isn't locked.

I couldn't find anything that recently changed in those codepaths, so I'm a bit lost.

[  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-rc
4-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:000000000000
0000
[  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 ]---

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