lkml.org 
[lkml]   [2022]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] mapletree-vs-khugepaged
Date
* Sven Schnelle <svens@linux.ibm.com> [220513 10:46]:
> Heiko Carstens <hca@linux.ibm.com> writes:
>
> > On Thu, Apr 28, 2022 at 10:20:40AM -0700, Guenter Roeck wrote:
> >> On Wed, Apr 27, 2022 at 03:10:45PM -0700, Andrew Morton wrote:
> >> > Fix mapletree for patch series "Make khugepaged collapse readonly FS THP
> >> > more consistent", v3.
> >> >
> >> > Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
> >> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >>
> >> This patch causes all my sparc64 boot tests to fail. Bisect and crash logs
> >> attached.
> >>
> >> Guenter
> >>

....

> >
> > FWIW, same on s390 - linux-next is completely broken. Note: I didn't
> > bisect, but given that the call trace, and even the failing address
> > match, I'm quite confident it is the same reason.
> >
> > Unable to handle kernel pointer dereference in virtual kernel address space
> > Failing address: 0e00000000000000 TEID: 0e00000000000803
> > Fault in home space mode while using kernel ASCE.
> > AS:00000000bac44007 R3:00000001ffff0007 S:00000001fffef800 P:000000000000003d
> > Oops: 0038 ilc:3 [#1] SMP
> > CPU: 3 PID: 79757 Comm: pt_upgrade_race Tainted: G E K 5.18.0-20220428.rc4.git500.bdc61aad77fa.300.fc35.s390x+next #1
> > Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0)
> > Krnl PSW : 0704c00180000000 00000000b912c9a2 (mmap_region+0x1a2/0x8a8)
> > R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
> > Krnl GPRS: 0000000000000000 0e00000000000000 0000000000000000 0000000000000000
> > ffffffffffffffff 000000000000000f 00000380016b3d98 0000080000100000
> > 000000008364c100 0000080000000000 0000000000100077 0e00000000000000
> > 00000000909da100 00000380016b3c58 00000000b912c982 00000380016b3b40
> > Krnl Code: 00000000b912c992: a774002c brc 7,00000000b912c9ea
> > 00000000b912c996: ecb80225007c cgij %r11,0,8,00000000b912cde0
> > #00000000b912c99c: e310f0f80004 lg %r1,248(%r15)
> > >00000000b912c9a2: e37010000020 cg %r7,0(%r1)
> > 00000000b912c9a8: a784010b brc 8,00000000b912cbbe
> > 00000000b912c9ac: e310f0e80004 lg %r1,232(%r15)
> > 00000000b912c9b2: ec180013007c cgij %r1,0,8,00000000b912c9d8
> > 00000000b912c9b8: e310f0e80004 lg %r1,232(%r15)
> > Call Trace:
> > [<00000000b912c9a2>] mmap_region+0x1a2/0x8a8
> > ([<00000000b912c982>] mmap_region+0x182/0x8a8)
> > [<00000000b912d492>] do_mmap+0x3ea/0x4c8
> > [<00000000b90fb9cc>] vm_mmap_pgoff+0xd4/0x170
> > [<00000000b9129c9a>] ksys_mmap_pgoff+0x62/0x238
> > [<00000000b912a034>] __s390x_sys_old_mmap+0x74/0x98
> > [<00000000b9a78ff8>] __do_syscall+0x1d8/0x200
> > [<00000000b9a872a2>] system_call+0x82/0xb0
> > Last Breaking-Event-Address:
> > [<00000000b9b9e678>] __s390_indirect_jump_r14+0x0/0xc
> > Kernel panic - not syncing: Fatal exception: panic_on_oops
>
> Starting today we're still seeing the same crash with linux-next from
> (next-20220513):
>
> [ 211.937897] CPU: 7 PID: 535 Comm: pt_upgrade Not tainted 5.18.0-rc6-11648-g76535d42eb53-dirty #732
> [ 211.937902] Unable to handle kernel pointer dereference in virtual kernel address space
> [ 211.937903] Hardware name: IBM 3906 M04 704 (z/VM 7.1.0)
> [ 211.937906] Failing address: 0e00000000000000 TEID: 0e00000000000803
> [ 211.937909] Krnl PSW : 0704c00180000000 0000001ca52f06d6
> [ 211.937910] Fault in home space mode while using kernel ASCE.
> [ 211.937917] AS:0000001ca6e24007 R3:0000001fffff0007 S:0000001ffffef800 P:000000000000003d
> [ 211.937914] (mmap_region+0x19e/0x848)
> [ 211.937929] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
> [ 211.937939] Krnl GPRS: 0000000000000000 0e00000000000000 0000000000000000 0000000000000000
> [ 211.937942] ffffffff00000f0f ffffffffffffffff 0e00000000000000 0000040000001000
> [ 211.937945] 0000000083551900 0000040000000000 00000000000000fb 000003800070fc58
> [ 211.937947] 000000008f490000 0000000000000000 0000001ca52f06b6 000003800070fb48
> [ 211.937959] Krnl Code: 0000001ca52f06c6: a7740021 brc 7,0000001ca52f0708
> [ 211.937959] 0000001ca52f06ca: ec6801b3007c cgij %r6,0,8,0000001ca52f0a30
> [ 211.937959] #0000001ca52f06d0: e310f0f80004 lg %r1,248(%r15)
> [ 211.937959] >0000001ca52f06d6: e37010000020 cg %r7,0(%r1)
> [ 211.937959] 0000001ca52f06dc: a78400ea brc 8,0000001ca52f08b0
> [ 211.937959] 0000001ca52f06e0: e310f0f00004 lg %r1,240(%r15)
> [ 211.937959] 0000001ca52f06e6: ec180008007c cgij %r1,0,8,0000001ca52f06f6
> [ 211.937959] 0000001ca52f06ec: e39010080020 cg %r9,8(%r1)
> [ 211.937973] Call Trace:
> [ 211.937975] [<0000001ca52f06d6>] mmap_region+0x19e/0x848
> [ 211.937978] ([<0000001ca52f06b6>] mmap_region+0x17e/0x848)
> [ 211.937981] [<0000001ca52f116a>] do_mmap+0x3ea/0x4c8
> [ 211.937983] [<0000001ca52bed12>] vm_mmap_pgoff+0xda/0x178
> [ 211.937987] [<0000001ca52ed5ea>] ksys_mmap_pgoff+0x62/0x238
> [ 211.937989] [<0000001ca52ed992>] __s390x_sys_old_mmap+0x7a/0xa0
> [ 211.937993] [<0000001ca5c4ef5c>] __do_syscall+0x1d4/0x200
> [ 211.937999] [<0000001ca5c5d572>] system_call+0x82/0xb0
> [ 211.938002] Last Breaking-Event-Address:
> [ 211.938003] [<0000001ca5888616>] mas_prev+0xb6/0xc0
> [ 211.938010] Oops: 0038 ilc:3 [#2]
> [ 211.938011] Kernel panic - not syncing: Fatal exception: panic_on_oops
> [ 211.938012] SMP
> [ 211.938014] Modules linked in:
> 07: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 0000001C
> A50679A6
>
> IS that issue supposed to be fixed? git bisect pointed me to
>
> # bad: [76535d42eb53485775a8c54ea85725812b75543f] Merge branch
> 'mm-everything' of
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>
> which isn't really helpful.
>
> Anything we could help with debugging this?

I tested the maple tree on top of the s390 as it was the same crash and
it was okay. I haven't tested the mm-everything branch though. Can you
test mm-unstable?

I'll continue setting up a sparc VM for testing here and test
mm-everything on that and the s390

Thanks,
Liam
\
 
 \ /
  Last update: 2022-05-13 19:02    [W:0.168 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site