"mm: per-thread vma caching fix 5" breaks s390
Subsystems (2)
Hi Andrew,
your patch "mm-per-thread-vma-caching-fix-5" in linux-next (see below) breaks s390:
[ 10.101173] kernel BUG at mm/vmacache.c:76!
[ 10.101206] illegal operation: 0001 [#1] SMP DEBUG_PAGEALLOC
[ 10.101210] Modules linked in:
[ 10.101212] CPU: 3 PID: 2286 Comm: ifup-eth Not tainted 3.14.0-rc6-00193-g7f31667faba3 #20
[ 10.101214] task: 000000003f65cb90 ti: 000000003db30000 task.ti: 000000003db30000
[ 10.101220] Krnl PSW : 0704d00180000000 000000000025df40 (vma_interval_tree_augment_rotate+0x0/0x64)
[ 10.101222] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
Krnl GPRS: 0000000000000000 0000000000000018 000000003a42cfd0 00000000800fb000
[ 10.101225] 0000000000000001 000000003f65cb90 0000000000000000 000000003dbacba8
[ 10.101226] 0705100180000000 000000003dbacb00 000000003f65cb90 000000003dbacb00
[ 10.101227] 000000003a42cfd0 00000000800fb000 0000000000269e54 000000003db33d80
[ 10.101235] Krnl Code: 000000000025df32: e3b0c0400020 cg %r11,64(%r12)
000000000025df38: a784ffd1 brc 8,25deda
#000000000025df3c: a7f40001 brc 15,25df3e
>000000000025df40: e31020180004 lg %r1,24(%r2)
000000000025df46: e31030180024 stg %r1,24(%r3)
000000000025df4c: e3302fb0ff04 lg %r3,-80(%r2)
000000000025df52: e31020400004 lg %r1,64(%r2)
000000000025df58: e3302fa8ff09 sg %r3,-88(%r2)
[ 10.101251] Call Trace:
[ 10.101253] ([<000000003dbacb00>] 0x3dbacb00)
[ 10.101256] [<00000000007a62da>] do_protection_exception+0x12a/0x3b4
[ 10.101258] [<00000000007a4862>] pgm_check_handler+0x17a/0x17e
[ 10.101259] [<0000000080086806>] 0x80086806
[ 10.101260] INFO: lockdep is turned off.
[ 10.101261] Last Breaking-Event-Address:
[ 10.101262] [<000000000025df3c>] vmacache_find+0x80/0x84
[ 10.101264]
[ 10.101265] Kernel panic - not syncing: Fatal exception: panic_on_oopsGiven that this is just an addon patch to Davidlohr's "mm: per-thread vma caching" patch I was wondering if something in there is architecture specific.
But it doesn't look like that. So I'm wondering if this only breaks on s390?
commit 7f31667faba32a4cf1e20d042c17783168c95f1b
Author: Andrew Morton <[email protected]> Date: Mon Mar 17 11:23:53 2014 +1100
mm-per-thread-vma-caching-fix-5
a sanity check
mm/vmacache.c +3 -1
@@ -72,8 +72,10 @@ struct vm_area_struct *vmacache_find(struct mm_struct *mm, unsigned long addr)for (i =0 ; i <VMACACHE_SIZE ; i++) {struct vm_area_struct *vma = current->vmacache[i]; -if (vma && vma->vm_start <= addr && vma->vm_end > addr) +if (vma && vma->vm_start <= addr && vma->vm_end > addr) { +BUG_ON (vma->vm_mm != mm);return vma; + } }return NULL ;
--
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>
Quoted 34 lines · Heiko Carstens
Hi Andrew,
your patch "mm-per-thread-vma-caching-fix-5" in linux-next (see below) breaks s390:
[ 10.101173] kernel BUG at mm/vmacache.c:76! [ 10.101206] illegal operation: 0001 [#1] SMP DEBUG_PAGEALLOC [ 10.101210] Modules linked in: [ 10.101212] CPU: 3 PID: 2286 Comm: ifup-eth Not tainted 3.14.0-rc6-00193-g7f31667faba3 #20 [ 10.101214] task: 000000003f65cb90 ti: 000000003db30000 task.ti: 000000003db30000 [ 10.101220] Krnl PSW : 0704d00180000000 000000000025df40 (vma_interval_tree_augment_rotate+0x0/0x64) [ 10.101222] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3 Krnl GPRS: 0000000000000000 0000000000000018 000000003a42cfd0 00000000800fb000 [ 10.101225] 0000000000000001 000000003f65cb90 0000000000000000 000000003dbacba8 [ 10.101226] 0705100180000000 000000003dbacb00 000000003f65cb90 000000003dbacb00 [ 10.101227] 000000003a42cfd0 00000000800fb000 0000000000269e54 000000003db33d80 [ 10.101235] Krnl Code: 000000000025df32: e3b0c0400020 cg %r11,64(%r12) 000000000025df38: a784ffd1 brc 8,25deda #000000000025df3c: a7f40001 brc 15,25df3e >000000000025df40: e31020180004 lg %r1,24(%r2) 000000000025df46: e31030180024 stg %r1,24(%r3) 000000000025df4c: e3302fb0ff04 lg %r3,-80(%r2) 000000000025df52: e31020400004 lg %r1,64(%r2) 000000000025df58: e3302fa8ff09 sg %r3,-88(%r2) [ 10.101251] Call Trace: [ 10.101253] ([<000000003dbacb00>] 0x3dbacb00) [ 10.101256] [<00000000007a62da>] do_protection_exception+0x12a/0x3b4 [ 10.101258] [<00000000007a4862>] pgm_check_handler+0x17a/0x17e [ 10.101259] [<0000000080086806>] 0x80086806 [ 10.101260] INFO: lockdep is turned off. [ 10.101261] Last Breaking-Event-Address: [ 10.101262] [<000000000025df3c>] vmacache_find+0x80/0x84 [ 10.101264] [ 10.101265] Kernel panic - not syncing: Fatal exception: panic_on_oops
Quoted 5 lines
Given that this is just an addon patch to Davidlohr's "mm: per-thread vma caching" patch I was wondering if something in there is architecture specific.
But it doesn't look like that. So I'm wondering if this only breaks on s390?
No, there isn't anything arch specific. Please note that there are a few other patches in -mm that fix the actual issue that triggers that BUG_ON(), so you'll want to try those.
--
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>
Quoted 5 lines · Heiko Carstens
Given that this is just an addon patch to Davidlohr's "mm: per-thread vma caching" patch I was wondering if something in there is architecture specific.
But it doesn't look like that. So I'm wondering if this only breaks on s390?
I'm seeing this same BUG_ON() on ia64 (when trying out next-20140318)
Starting HAkernel BUG at mm/vmacache.c:76!
L daemon7[?25lps[3259]: bugcheck! 0 [1]
Modules linked in: mptctl
CPU: 0 PID: 3259 Comm: ps Not tainted 3.14.0-rc7-zx1-smp-next-20140318 #1
Hardware name: hp server rx2620 , BIOS 03.17
03/31/2005
task: e000000001070000 ti: e000000001070c80 task.ti: e000000001070c80psr : 0000101008526038 ifs : 8000000000000309 ip :
[<a00000010019a930>] Not tainted (3.14.0-rc7-zx1-smp-next-20140318)
ip is at vmacache_find+0x1d0/0x1e0
unat: 0000000000000000 pfs : 0000000000000309 rsc : 0000000000000003
rnat: 0009804c0270033f bsps: a00000010153e470 pr : 0000000019a99565
ldrs: 0000000000000000 ccv : 00000010e0bb89b1 fpsr: 0009804c0270033f csd : 0000000000000000 ssd : 0000000000000000
b0 : a00000010019a930 b6 : a0000001006cff20 b7 : a0000001006d1a40 f6 : 1003e000000167080aa40 f7 : 1003e0000000000000514 f8 : 1003e000000167080a52c f9 : 1003e0000000000000001 f10 : 1003e501ac672552bd930 f11 : 1003e0000000000000004 r1 : a00000010176aa00 r2 : a00000010153e468 r3 : a00000010156b5e0 r8 : 000000000000001f r9 : 0000000000001b14 r10 : ffffffffffffffff r11 : 0000000000000000 r12 : e000000001077df0 r13 : e000000001070000 r14 : a00000010153e470 r15 : a00000010153e470 r16 : 000000001b140d8a r17 : 0000000000000000 r18 : 0000000000007fff r19 : 0000000000000182 r20 : 0000000000000003 r21 : 0000000000000000 r22 : 0000000000000182 r23 : a00000010130a9a8 r24 : a0000001006cff20 r25 : a00000010130a9a8 r26 : a0000001006cff20 r27 : a000000101544658 r28 : a0000001015e2508 r29 : a00000010130a998 r30 : a0000001006cfec0 r31 : a0000001015e23e0
Call Trace:
[<a000000100015460>] show_stack+0x80/0xa0
sp=e0000000010779b0 bsp=e0000000010712e0
[<a000000100015ac0>] show_regs+0x640/0x920
sp=e000000001077b80 bsp=e000000001071288
[<a0000001000424c0>] die+0x1a0/0x2e0
sp=e000000001077b90 bsp=e000000001071248
[<a000000100042650>] die_if_kernel+0x50/0x80
sp=e000000001077b90 bsp=e000000001071218
[<a000000100f3df10>] ia64_bad_break+0x3d0/0x6e0
sp=e000000001077b90 bsp=e0000000010711e8
[<a00000010000c740>] ia64_native_leave_kernel+0x0/0x270
sp=e000000001077c20 bsp=e0000000010711e8
[<a00000010019a930>] vmacache_find+0x1d0/0x1e0
sp=e000000001077df0 bsp=e0000000010711a0
[<a0000001001b4cb0>] find_vma+0x30/0x140
sp=e000000001077df0 bsp=e000000001071170
[<a0000001001b4df0>] find_extend_vma+0x30/0x140
sp=e000000001077df0 bsp=e000000001071138
[<a0000001001a9080>] __get_user_pages+0x120/0xd60
sp=e000000001077df0 bsp=e000000001071010
[<a0000001001a9dd0>] get_user_pages+0x70/0xa0
sp=e000000001077e10 bsp=e000000001070fb0
[<a0000001001a9eb0>] __access_remote_vm+0xb0/0x360
sp=e000000001077e10 bsp=e000000001070f18
[<a0000001001aa1c0>] access_process_vm+0x60/0xa0
sp=e000000001077e20 bsp=e000000001070ed0
[<a00000010018a390>] get_cmdline+0xb0/0x240
sp=e000000001077e20 bsp=e000000001070e88
[<a0000001002ca2f0>] proc_pid_cmdline+0x30/0x60
sp=e000000001077e20 bsp=e000000001070e60
[<a0000001002c7880>] proc_info_read+0x120/0x200
sp=e000000001077e20 bsp=e000000001070e10
[<a000000100201da0>] vfs_read+0x140/0x340
sp=e000000001077e20 bsp=e000000001070dc0
[<a000000100202180>] SyS_read+0xa0/0x120
sp=e000000001077e20 bsp=e000000001070d40
[<a00000010000c5c0>] ia64_ret_from_syscall+0x0/0x20
sp=e000000001077e30 bsp=e000000001070d40
[<a000000000040720>] ia64_ivt+0xffffffff00040720/0x400
sp=e000000001078000 bsp=e000000001070d40Disabling lock debugging due to kernel taint
--
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>
Andrew Morton
maintainerQuoted 9 lines · On Tue, 18 Mar 2014 16:06:59 -0700 Tony Luck <[email protected]> wrote:
Quoted 5 lines · Heiko Carstens
Given that this is just an addon patch to Davidlohr's "mm: per-thread vma caching" patch I was wondering if something in there is architecture specific.
But it doesn't look like that. So I'm wondering if this only breaks on s390?I'm seeing this same
BUG_ON()on ia64 (when trying out next-20140318)
-next is missing
http://ozlabs.org/~akpm/mmots/broken-out/mm-per-thread-vma-caching-fix-6.patch.
Am presently trying to cook up an mmotm for tomorrow's -next.
--
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>
Hi Andrew,
Quoted 11 lines · On Tue, 18 Mar 2014 16:10:50 -0700 Andrew Morton <[email protected]>…
Quoted 8 lines · On Tue, 18 Mar 2014 16:06:59 -0700 Tony Luck <[email protected]> wrote:
Quoted 5 lines · Heiko Carstens
Given that this is just an addon patch to Davidlohr's "mm: per-thread vma caching" patch I was wondering if something in there is architecture specific.
But it doesn't look like that. So I'm wondering if this only breaks on s390?
Quoted 5 lines
Quoted 1 line
I'm seeing this same
BUG_ON()on ia64 (when trying out next-20140318)-next is missing
http://ozlabs.org/~akpm/mmots/broken-out/mm-per-thread-vma-caching-fix-6.patch.
Am presently trying to cook up an mmotm for tomorrow's -next.
I could apply just that patch to today's linux-next if you like. Otherwise if you get a new mmotm out in the next ~6-8 hours, I will use that.
Signature · 2 lines
Cheers, Stephen Rothwell [email protected]
Problem is no longer present in next-20140321.
-Tony
--
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>