Re: mm: BUG in do_huge_pmd_wp_page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 3 Feb 2014, Sasha Levin wrote:
> On 04/25/2013 10:01 PM, Dave Jones wrote:
> > On Thu, Apr 25, 2013 at 08:51:27PM -0400, Sasha Levin wrote:
> >   > On 04/24/2013 06:46 PM, Andrew Morton wrote:
> >   > > Guys, did this get fixed?
> >   >
> >   > I've stopped seeing that during fuzzing, so I guess that it got fixed
> > somehow...
> > 
> > We've had reports of users hitting this in 3.8
> > 
> > eg:
> > https://bugzilla.redhat.com/show_bug.cgi?id=947985
> > https://bugzilla.redhat.com/show_bug.cgi?id=956730
> > 
> > I'm sure there are other reports of it too.
> > 
> > Would be good if we can figure out what fixed it (if it is actually fixed)
> > for backporting to stable
> 
> It's been a while (7 months?), but this one is back...
> 
> Just hit it again with today's -next:
> 
> [  762.701278] BUG: unable to handle kernel paging request at
> ffff88009eae6000
> [  762.702462] IP: [<ffffffff81ae8455>] copy_page_rep+0x5/0x10
> [  762.703369] PGD 84bb067 PUD 22fa81067 PMD 22f98b067 PTE 800000009eae6060
> [  762.704411] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [  762.705873] Dumping ftrace buffer:
> [  762.707606]    (ftrace buffer empty)
> [  762.708311] Modules linked in:
> [  762.708762] CPU: 16 PID: 17920 Comm: trinity-c16 Tainted: G        W
> 3.13.0-next-2
> 0140203-sasha-00007-gf4985e2 #23
> [  762.710135] task: ffff8801ac358000 ti: ffff880199234000 task.ti:
> ffff880199234000
> [  762.710135] RIP: 0010:[<ffffffff81ae8455>]  [<ffffffff81ae8455>]
> copy_page_rep+0x5/0x
> 10
> [  762.710135] RSP: 0018:ffff880199235c90  EFLAGS: 00010286
> [  762.710135] RAX: 0000000080000002 RBX: 00000000056db980 RCX:
> 0000000000000200
> [  762.710135] RDX: ffff8801ac358000 RSI: ffff88009eae6000 RDI:
> ffff88015b6e6000
> [  762.710135] RBP: ffff880199235cd8 R08: 0000000000000000 R09:
> 0000000000000000
> [  762.710135] R10: 0000000000000001 R11: 0000000000000000 R12:
> 00000000027ab980
> [  762.710135] R13: 0000000000000200 R14: 00000000000000e6 R15:
> ffff880000000000
> [  762.710135] FS:  00007fb0804e1700(0000) GS:ffff88003da00000(0000)
> knlGS:0000000000000
> 000
> [  762.710135] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  762.710135] CR2: ffff88009eae6000 CR3: 0000000199225000 CR4:
> 00000000000006e0
> [  762.710135] Stack:
> [  762.710135]  ffffffff81298995 ffff8801a841ae00 ffff88003d084520
> ffff880199227090
> [  762.710135]  800000009ea008e5 ffff8801a841ae00 ffffea00027a8000
> ffff880199227090
> [  762.710135]  ffffea00056d8000 ffff880199235d58 ffffffff812d7260
> ffff880199235cf8
> [  762.710135] Call Trace:
> [  762.710135]  [<ffffffff81298995>] ? copy_user_huge_page+0x1a5/0x210
> [  762.710135]  [<ffffffff812d7260>] do_huge_pmd_wp_page+0x3d0/0x650
> [  762.710135]  [<ffffffff811a308e>] ? put_lock_stats+0xe/0x30
> [  762.710135]  [<ffffffff8129b511>] __handle_mm_fault+0x2b1/0x3d0
> [  762.710135]  [<ffffffff8129b763>] handle_mm_fault+0x133/0x1c0
> [  762.710135]  [<ffffffff8129bcf8>] __get_user_pages+0x438/0x630
> [  762.710135]  [<ffffffff811a308e>] ? put_lock_stats+0xe/0x30
> [  762.710135]  [<ffffffff8129cfc4>] __mlock_vma_pages_range+0xd4/0xe0
> [  762.710135]  [<ffffffff8129d0e0>] __mm_populate+0x110/0x190
> [  762.710135]  [<ffffffff8129dcd0>] SyS_mlockall+0x160/0x1b0
> [  762.710135]  [<ffffffff84450650>] tracesys+0xdd/0xe2
> [  762.710135] Code: 90 90 90 90 90 90 9c fa 65 48 3b 06 75 14 65 48 3b 56 08
> 75 0d 65 48 89 1e 65 48 89 4e 08 9d b0 01 c3 9d 30 c0 c3 b9 00 02 00 00 <f3>
> 48 a5 c3 0f 1f 80 00
> 00 00 00 eb ee 66 66 66 90 66 66 66 90
> [  762.710135] RIP  [<ffffffff81ae8455>] copy_page_rep+0x5/0x10
> [  762.710135]  RSP <ffff880199235c90>
> [  762.710135] CR2: ffff88009eae6000

Here's what I suggested about that one in eecc1e426d68
"thp: fix copy_page_rep GPF by testing is_huge_zero_pmd once only":
Note: this is not the same issue as trinity's DEBUG_PAGEALLOC BUG
in copy_page_rep with RSI: ffff88009c422000, reported by Sasha Levin
in https://lkml.org/lkml/2013/3/29/103.  I believe that one is due
to the source page being split, and a tail page freed, while copy
is in progress; and not a problem without DEBUG_PAGEALLOC, since
the pmd_same check will prevent a miscopy from being made visible.

It could be fixed by additional locking, or by taking an additional
reference on every tail page, in the DEBUG_PAGEALLOC case (we wouldn't
want to add to the overhead in the normal case).  I didn't feel very
motivated to uglify the code in that way just for DEBUG_PAGEALLOC and
trinity: if it only comes up once in seven months, I'm inclined to
live with it myself, but you may have a different perspective.

Hugh

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]