* "reuse mergeable anon_vma as parent when fork" causes a crash on s390
@ 2019-10-09 21:29 Qian Cai
2019-10-09 22:21 ` Shakeel Butt
0 siblings, 1 reply; 8+ messages in thread
From: Qian Cai @ 2019-10-09 21:29 UTC (permalink / raw)
To: Wei Yang
Cc: Andrew Morton, Konstantin Khlebnikov, Rik van Riel, linux-mm,
linux-kernel, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-s390
The linux-next commit "mm/rmap.c: reuse mergeable anon_vma as parent when fork"
[1] causes a crash on s390 while compiling some C code. Reverted it fixes the
issue.
[1] https://lore.kernel.org/lkml/20191004160632.30251-1-richardw.yang@linux.intel.com/
00: [ 330.681233] vma 0000000049a08008 start 000003ff8ee7f000 end 000003ff8eee4
00: 000
00: [ 330.681233] next 000000004f272008 prev 0000000065c84230 mm 0000000037d1c1
00: 00
00: [ 330.681233] prot 711 anon_vma 000000001f4e4a80 vm_ops 0000000000000000
00: [ 330.681233] pgoff 3ff8ee7f file 0000000000000000 private_data 00000000000
00: 00000
00: [ 330.681233] flags: 0x8100073(read|write|mayread|maywrite|mayexec|account|
00: softdirty)
00: [ 330.681344] ------------[ cut here ]------------
00: [ 330.681357] kernel BUG at include/linux/rmap.h:159!
00: [ 330.681442] illegal operation: 0001 ilc:1 [#1] SMP DEBUG_PAGEALLOC
00: [ 330.681460] Modules linked in: ip_tables x_tables xfs dasd_fba_mod dasd_e
00: ckd_mod dm_mirror dm_region_hash dm_log dm_mod
00: [ 330.681502] CPU: 0 PID: 7651 Comm: cc1 Not tainted 5.4.0-rc2-next-2019100
00: 9+ #4
00: [ 330.681516] Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
00: [ 330.681530] Krnl PSW : 0704c00180000000 00000000531d9cac (__vma_adjust+0x
00: cf4/0xf30)
00: [ 330.681561] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0
00: RI:0 EA:3
00: [ 330.681579] Krnl GPRS: 0000000000000001 0000030000000000 0000000000000146
00: 000000006cc03da4
00: [ 330.681595] 0000030000000000 000000005304378c 00000000513de008
00: 0000000000000000
00: [ 330.681611] 0000000049a08008 0000000049a08080 0000000000000000
00: 000000005a178438
00: [ 330.681627] 0000000053bae3b0 0000000037d1c100 00000000531d9ca8
00: 00000000235ef880
01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
CPU 01.
01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
CPU 00.
00: [ 330.681668] Krnl Code: 00000000531d9c9c: fae0b9040028 ap 2308
00: (15,%r11),40(1,%r0)
00: [ 330.681668] 00000000531d9ca2: c0e5ffff145f brasl %r14
00: ,531bc560
00: [ 330.681668] #00000000531d9ca8: a7f40001 brc 15,5
00: 31d9caa
00: [ 330.681668] >00000000531d9cac: c020005f1a5a larl %r2,
00: 53dbd160
00: [ 330.681668] 00000000531d9cb2: c0e50015ec2b brasl %r14
00: ,53497508
00: [ 330.681668] 00000000531d9cb8: e320f0d80004 lg %r2,
00: 216(%r15)
00: [ 330.681668] 00000000531d9cbe: c0e500040de1 brasl %r14
00: ,5325b880
00: [ 330.681668] 00000000531d9cc4: 4120d038 la %r2,
00: 56(%r13)
00: [ 330.682579] Call Trace:
00: [ 330.682665] ([<00000000531d9ca8>] __vma_adjust+0xcf0/0xf30)
00: [ 330.682684] [<00000000531da4f0>] vma_merge+0x608/0x6b8
00: [ 330.682699] [<00000000531de3b8>] mmap_region+0x1e0/0x9b0
00: [ 330.682713] [<00000000531defec>] do_mmap+0x464/0x650
00: [ 330.682730] [<00000000531930ba>] vm_mmap_pgoff+0x132/0x1c0
00: [ 330.682745] [<00000000531da7b4>] ksys_mmap_pgoff+0xd4/0x458
00: [ 330.682761] [<00000000531dac54>] __s390x_sys_old_mmap+0xdc/0x108
00: [ 330.682779] [<00000000537dcdd0>] system_call+0xd8/0x2b4
00: [ 330.682791] INFO: lockdep is turned off.
00: [ 330.682801] Last Breaking-Event-Address:
00: [ 330.682815] [<00000000531d9ca8>] __vma_adjust+0xcf0/0xf30
00: [ 330.682833] Kernel panic - not syncing: Fatal exception: panic_on_oops
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390
2019-10-09 21:29 "reuse mergeable anon_vma as parent when fork" causes a crash on s390 Qian Cai
@ 2019-10-09 22:21 ` Shakeel Butt
2019-10-10 0:04 ` Andrew Morton
2019-10-10 2:36 ` Wei Yang
0 siblings, 2 replies; 8+ messages in thread
From: Shakeel Butt @ 2019-10-09 22:21 UTC (permalink / raw)
To: Qian Cai
Cc: Wei Yang, Andrew Morton, Konstantin Khlebnikov, Rik van Riel,
Linux MM, LKML, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-s390
On Wed, Oct 9, 2019 at 2:30 PM Qian Cai <cai@lca.pw> wrote:
>
> The linux-next commit "mm/rmap.c: reuse mergeable anon_vma as parent when fork"
> [1] causes a crash on s390 while compiling some C code. Reverted it fixes the
> issue.
>
> [1] https://lore.kernel.org/lkml/20191004160632.30251-1-richardw.yang@linux.intel.com/
>
> 00: [ 330.681233] vma 0000000049a08008 start 000003ff8ee7f000 end 000003ff8eee4
> 00: 000
> 00: [ 330.681233] next 000000004f272008 prev 0000000065c84230 mm 0000000037d1c1
> 00: 00
> 00: [ 330.681233] prot 711 anon_vma 000000001f4e4a80 vm_ops 0000000000000000
> 00: [ 330.681233] pgoff 3ff8ee7f file 0000000000000000 private_data 00000000000
> 00: 00000
> 00: [ 330.681233] flags: 0x8100073(read|write|mayread|maywrite|mayexec|account|
> 00: softdirty)
> 00: [ 330.681344] ------------[ cut here ]------------
> 00: [ 330.681357] kernel BUG at include/linux/rmap.h:159!
> 00: [ 330.681442] illegal operation: 0001 ilc:1 [#1] SMP DEBUG_PAGEALLOC
> 00: [ 330.681460] Modules linked in: ip_tables x_tables xfs dasd_fba_mod dasd_e
> 00: ckd_mod dm_mirror dm_region_hash dm_log dm_mod
> 00: [ 330.681502] CPU: 0 PID: 7651 Comm: cc1 Not tainted 5.4.0-rc2-next-2019100
> 00: 9+ #4
> 00: [ 330.681516] Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
> 00: [ 330.681530] Krnl PSW : 0704c00180000000 00000000531d9cac (__vma_adjust+0x
> 00: cf4/0xf30)
> 00: [ 330.681561] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0
> 00: RI:0 EA:3
> 00: [ 330.681579] Krnl GPRS: 0000000000000001 0000030000000000 0000000000000146
> 00: 000000006cc03da4
> 00: [ 330.681595] 0000030000000000 000000005304378c 00000000513de008
> 00: 0000000000000000
> 00: [ 330.681611] 0000000049a08008 0000000049a08080 0000000000000000
> 00: 000000005a178438
> 00: [ 330.681627] 0000000053bae3b0 0000000037d1c100 00000000531d9ca8
> 00: 00000000235ef880
> 01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
> CPU 01.
> 01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
> CPU 00.
> 00: [ 330.681668] Krnl Code: 00000000531d9c9c: fae0b9040028 ap 2308
> 00: (15,%r11),40(1,%r0)
> 00: [ 330.681668] 00000000531d9ca2: c0e5ffff145f brasl %r14
> 00: ,531bc560
> 00: [ 330.681668] #00000000531d9ca8: a7f40001 brc 15,5
> 00: 31d9caa
> 00: [ 330.681668] >00000000531d9cac: c020005f1a5a larl %r2,
> 00: 53dbd160
> 00: [ 330.681668] 00000000531d9cb2: c0e50015ec2b brasl %r14
> 00: ,53497508
> 00: [ 330.681668] 00000000531d9cb8: e320f0d80004 lg %r2,
> 00: 216(%r15)
> 00: [ 330.681668] 00000000531d9cbe: c0e500040de1 brasl %r14
> 00: ,5325b880
> 00: [ 330.681668] 00000000531d9cc4: 4120d038 la %r2,
> 00: 56(%r13)
> 00: [ 330.682579] Call Trace:
> 00: [ 330.682665] ([<00000000531d9ca8>] __vma_adjust+0xcf0/0xf30)
> 00: [ 330.682684] [<00000000531da4f0>] vma_merge+0x608/0x6b8
> 00: [ 330.682699] [<00000000531de3b8>] mmap_region+0x1e0/0x9b0
> 00: [ 330.682713] [<00000000531defec>] do_mmap+0x464/0x650
> 00: [ 330.682730] [<00000000531930ba>] vm_mmap_pgoff+0x132/0x1c0
> 00: [ 330.682745] [<00000000531da7b4>] ksys_mmap_pgoff+0xd4/0x458
> 00: [ 330.682761] [<00000000531dac54>] __s390x_sys_old_mmap+0xdc/0x108
> 00: [ 330.682779] [<00000000537dcdd0>] system_call+0xd8/0x2b4
> 00: [ 330.682791] INFO: lockdep is turned off.
> 00: [ 330.682801] Last Breaking-Event-Address:
> 00: [ 330.682815] [<00000000531d9ca8>] __vma_adjust+0xcf0/0xf30
> 00: [ 330.682833] Kernel panic - not syncing: Fatal exception: panic_on_oops
Our internal syzbot instance also hit this bug and bisected to the same patch.
Report:
[ 74.249839][ T8601] vma ffff88808c0f7eb0 start 0000000020000000 end
0000000021000000
[ 74.249839][ T8601] next ffff888095f5e568 prev ffff888091279318 mm
ffff8880894555c0
[ 74.249839][ T8601] prot 25 anon_vma ffff88809a9c4b40 vm_ops 0000000000000000
[ 74.249839][ T8601] pgoff 20000 file 0000000000000000 private_data
0000000000000000
[ 74.249839][ T8601] flags:
0x8100077(read|write|exec|mayread|maywrite|mayexec|account|softdirty)
[ 74.289454][ T8601] ------------[ cut here ]------------
[ 74.294941][ T8601] kernel BUG at include/linux/rmap.h:159!
[ 74.301474][ T8601] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[ 74.307549][ T8601] CPU: 0 PID: 8601 Comm: syz-executor.0 Not
tainted 5.4.0-rc2-next-20191008 #0
[ 74.316453][ T8601] Hardware name: Google Google Compute
Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 74.327161][ T8601] RIP: 0010:__vma_adjust+0x151c/0x1cc0
[ 74.332604][ T8601] Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee
0f 82 1b fe ff ff 45 31 ed e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8
e8 76 62 fc ff <0f> 0b e8 6d 00 d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f
85 20 07 00
[ 74.352189][ T8601] RSP: 0018:ffff8880a0e9f9c0 EFLAGS: 00010286
[ 74.358232][ T8601] RAX: 0000000000000147 RBX: dffffc0000000000
RCX: 0000000000000000
[ 74.366180][ T8601] RDX: 0000000000000000 RSI: ffffffff815cb676
RDI: ffffed10141d3f12
[ 74.374126][ T8601] RBP: ffff8880a0e9fa88 R08: 0000000000000147
R09: ffffed1015d06161
[ 74.382076][ T8601] R10: ffffed1015d06160 R11: ffff8880ae830b07
R12: ffff888095f28e10
[ 74.390054][ T8601] R13: ffff88808c0f7f18 R14: 0000000000000000
R15: 0000000000000001
[ 74.398014][ T8601] FS: 0000000000c57940(0000)
GS:ffff8880ae800000(0000) knlGS:0000000000000000
[ 74.406918][ T8601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 74.413491][ T8601] CR2: 0000000020d06000 CR3: 0000000090f89000
CR4: 00000000001406f0
[ 74.421447][ T8601] DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
[ 74.429403][ T8601] DR3: 0000000000000000 DR6: 00000000fffe0ff0
DR7: 0000000000000400
[ 74.437348][ T8601] Call Trace:
[ 74.440625][ T8601] vma_merge+0xb8a/0xe60
[ 74.444848][ T8601] ? __vma_adjust+0x1cc0/0x1cc0
[ 74.449677][ T8601] ? __sanitizer_cov_trace_cmp8+0x18/0x20
[ 74.455369][ T8601] ? __vm_enough_memory+0x1b7/0x390
[ 74.460542][ T8601] mmap_region+0x3e0/0x1760
[ 74.465025][ T8601] ? __x64_sys_brk+0x760/0x760
[ 74.469766][ T8601] ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
[ 74.475991][ T8601] ? get_unmapped_area+0x2ad/0x3d0
[ 74.481075][ T8601] do_mmap+0x853/0x1190
[ 74.485216][ T8601] vm_mmap_pgoff+0x1c5/0x230
[ 74.489784][ T8601] ? randomize_stack_top+0x110/0x110
[ 74.495044][ T8601] ? __kasan_check_read+0x11/0x20
[ 74.500042][ T8601] ? _copy_to_user+0x118/0x160
[ 74.504782][ T8601] ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
[ 74.511007][ T8601] ksys_mmap_pgoff+0xf7/0x630
[ 74.515662][ T8601] ? find_mergeable_anon_vma+0x2e0/0x2e0
[ 74.521295][ T8601] ? trace_hardirqs_on_thunk+0x1a/0x20
[ 74.526735][ T8601] ? trace_hardirqs_on_thunk+0x1a/0x20
[ 74.532181][ T8601] ? do_syscall_64+0x26/0x760
[ 74.536835][ T8601] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 74.542881][ T8601] __x64_sys_mmap+0xe9/0x1b0
[ 74.547448][ T8601] do_syscall_64+0xfa/0x760
[ 74.551928][ T8601] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 74.557796][ T8601] RIP: 0033:0x459a59
[ 74.561682][ T8601] Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b
4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84
00 00 00 00
[ 74.581261][ T8601] RSP: 002b:00007ffcc91b5068 EFLAGS: 00000246
ORIG_RAX: 0000000000000009
[ 74.589731][ T8601] RAX: ffffffffffffffda RBX: 0000000000000006
RCX: 0000000000459a59
[ 74.597685][ T8601] RDX: ffffffffefffffff RSI: 0000000000004000
RDI: 0000000020196000
[ 74.605632][ T8601] RBP: 000000000075bf20 R08: ffffffffffffffff
R09: 0000000000000000
[ 74.613580][ T8601] R10: 0000000000008032 R11: 0000000000000246
R12: 0000000000c57914
[ 74.621527][ T8601] R13: 00000000004c6176 R14: 00000000004db118
R15: 00000000ffffffff
[ 74.629486][ T8601] Modules linked in:
[ 74.636716][ T8601] ---[ end trace aa2e499bc1c6fb5e ]---
[ 74.642235][ T8601] RIP: 0010:__vma_adjust+0x151c/0x1cc0
[ 74.647787][ T8601] Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee
0f 82 1b fe ff ff 45 31 ed e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8
e8 76 62 fc ff <0f> 0b e8 6d 00 d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f
85 20 07 00
[ 74.667752][ T8601] RSP: 0018:ffff8880a0e9f9c0 EFLAGS: 00010286
[ 74.673806][ T8601] RAX: 0000000000000147 RBX: dffffc0000000000
RCX: 0000000000000000
[ 74.681794][ T8601] RDX: 0000000000000000 RSI: ffffffff815cb676
RDI: ffffed10141d3f12
[ 74.689779][ T8601] RBP: ffff8880a0e9fa88 R08: 0000000000000147
R09: ffffed1015d06161
[ 74.698081][ T8601] R10: ffffed1015d06160 R11: ffff8880ae830b07
R12: ffff888095f28e10
[ 74.706052][ T8601] R13: ffff88808c0f7f18 R14: 0000000000000000
R15: 0000000000000001
[ 74.714061][ T8601] FS: 0000000000c57940(0000)
GS:ffff8880ae800000(0000) knlGS:0000000000000000
[ 74.723209][ T8601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 74.729820][ T8601] CR2: 0000000020d06000 CR3: 0000000090f89000
CR4: 00000000001406f0
[ 74.738021][ T8601] DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
[ 74.745972][ T8601] DR3: 0000000000000000 DR6: 00000000fffe0ff0
DR7: 0000000000000400
[ 74.753968][ T8601] Kernel panic - not syncing: Fatal exception
Syzbot reproducer:
mmap(&(0x7f0000196000/0x4000)=nil, 0x4000, PROT_NONE, 0x4032 /* flags=
MAP_NORESERVE|MAP_ANONYMOUS|MAP_FIXED|PROT_WRITE*/, -1, 0x0)
mmap(&(0x7f0000196000/0x4000)=nil, 0x4000, 0xffffffffefffffff, 0x8032
/* flags= MAP_POPULATE|MAP_ANONYMOUS|MAP_FIXED|PROT_WRITE*/, -1, 0x0)
Shakeel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390
2019-10-09 22:21 ` Shakeel Butt
@ 2019-10-10 0:04 ` Andrew Morton
2019-10-10 2:36 ` Wei Yang
1 sibling, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2019-10-10 0:04 UTC (permalink / raw)
To: Shakeel Butt
Cc: Qian Cai, Wei Yang, Konstantin Khlebnikov, Rik van Riel,
Linux MM, LKML, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-s390, Stephen Rothwell
On Wed, 9 Oct 2019 15:21:11 -0700 Shakeel Butt <shakeelb@google.com> wrote:
> On Wed, Oct 9, 2019 at 2:30 PM Qian Cai <cai@lca.pw> wrote:
> >
> > The linux-next commit "mm/rmap.c: reuse mergeable anon_vma as parent when fork"
> > [1] causes a crash on s390 while compiling some C code. Reverted it fixes the
> > issue.
> >
> > [1] https://lore.kernel.org/lkml/20191004160632.30251-1-richardw.yang@linux.intel.com/
> >
>
> ...
>
> Our internal syzbot instance also hit this bug and bisected to the same patch.
Thanks, I'll drop
mm-rmapc-reuse-mergeable-anon_vma-as-parent-when-fork.patch.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390
2019-10-09 22:21 ` Shakeel Butt
2019-10-10 0:04 ` Andrew Morton
@ 2019-10-10 2:36 ` Wei Yang
2019-10-10 3:15 ` Wei Yang
1 sibling, 1 reply; 8+ messages in thread
From: Wei Yang @ 2019-10-10 2:36 UTC (permalink / raw)
To: Shakeel Butt
Cc: Qian Cai, Wei Yang, Andrew Morton, Konstantin Khlebnikov,
Rik van Riel, Linux MM, LKML, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-s390
Hi, Qian, Shakeel
Thanks for testing.
Sounds I missed some case to handle. anon_vma_clone() now would be called in
vma_adjust, which is a different case when it is introduced.
BTW, do you have the specific test case? So that I could verify my change. The
kernel build test doesn't trigger this.
Thanks a lot :-)
On Wed, Oct 09, 2019 at 03:21:11PM -0700, Shakeel Butt wrote:
>On Wed, Oct 9, 2019 at 2:30 PM Qian Cai <cai@lca.pw> wrote:
>>
>> The linux-next commit "mm/rmap.c: reuse mergeable anon_vma as parent when fork"
>> [1] causes a crash on s390 while compiling some C code. Reverted it fixes the
>> issue.
>>
>> [1] https://lore.kernel.org/lkml/20191004160632.30251-1-richardw.yang@linux.intel.com/
>>
>> 00: [ 330.681233] vma 0000000049a08008 start 000003ff8ee7f000 end 000003ff8eee4
>> 00: 000
>> 00: [ 330.681233] next 000000004f272008 prev 0000000065c84230 mm 0000000037d1c1
>> 00: 00
>> 00: [ 330.681233] prot 711 anon_vma 000000001f4e4a80 vm_ops 0000000000000000
>> 00: [ 330.681233] pgoff 3ff8ee7f file 0000000000000000 private_data 00000000000
>> 00: 00000
>> 00: [ 330.681233] flags: 0x8100073(read|write|mayread|maywrite|mayexec|account|
>> 00: softdirty)
>> 00: [ 330.681344] ------------[ cut here ]------------
>> 00: [ 330.681357] kernel BUG at include/linux/rmap.h:159!
>> 00: [ 330.681442] illegal operation: 0001 ilc:1 [#1] SMP DEBUG_PAGEALLOC
>> 00: [ 330.681460] Modules linked in: ip_tables x_tables xfs dasd_fba_mod dasd_e
>> 00: ckd_mod dm_mirror dm_region_hash dm_log dm_mod
>> 00: [ 330.681502] CPU: 0 PID: 7651 Comm: cc1 Not tainted 5.4.0-rc2-next-2019100
>> 00: 9+ #4
>> 00: [ 330.681516] Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
>> 00: [ 330.681530] Krnl PSW : 0704c00180000000 00000000531d9cac (__vma_adjust+0x
>> 00: cf4/0xf30)
>> 00: [ 330.681561] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0
>> 00: RI:0 EA:3
>> 00: [ 330.681579] Krnl GPRS: 0000000000000001 0000030000000000 0000000000000146
>> 00: 000000006cc03da4
>> 00: [ 330.681595] 0000030000000000 000000005304378c 00000000513de008
>> 00: 0000000000000000
>> 00: [ 330.681611] 0000000049a08008 0000000049a08080 0000000000000000
>> 00: 000000005a178438
>> 00: [ 330.681627] 0000000053bae3b0 0000000037d1c100 00000000531d9ca8
>> 00: 00000000235ef880
>> 01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
>> CPU 01.
>> 01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from
>> CPU 00.
>> 00: [ 330.681668] Krnl Code: 00000000531d9c9c: fae0b9040028 ap 2308
>> 00: (15,%r11),40(1,%r0)
>> 00: [ 330.681668] 00000000531d9ca2: c0e5ffff145f brasl %r14
>> 00: ,531bc560
>> 00: [ 330.681668] #00000000531d9ca8: a7f40001 brc 15,5
>> 00: 31d9caa
>> 00: [ 330.681668] >00000000531d9cac: c020005f1a5a larl %r2,
>> 00: 53dbd160
>> 00: [ 330.681668] 00000000531d9cb2: c0e50015ec2b brasl %r14
>> 00: ,53497508
>> 00: [ 330.681668] 00000000531d9cb8: e320f0d80004 lg %r2,
>> 00: 216(%r15)
>> 00: [ 330.681668] 00000000531d9cbe: c0e500040de1 brasl %r14
>> 00: ,5325b880
>> 00: [ 330.681668] 00000000531d9cc4: 4120d038 la %r2,
>> 00: 56(%r13)
>> 00: [ 330.682579] Call Trace:
>> 00: [ 330.682665] ([<00000000531d9ca8>] __vma_adjust+0xcf0/0xf30)
>> 00: [ 330.682684] [<00000000531da4f0>] vma_merge+0x608/0x6b8
>> 00: [ 330.682699] [<00000000531de3b8>] mmap_region+0x1e0/0x9b0
>> 00: [ 330.682713] [<00000000531defec>] do_mmap+0x464/0x650
>> 00: [ 330.682730] [<00000000531930ba>] vm_mmap_pgoff+0x132/0x1c0
>> 00: [ 330.682745] [<00000000531da7b4>] ksys_mmap_pgoff+0xd4/0x458
>> 00: [ 330.682761] [<00000000531dac54>] __s390x_sys_old_mmap+0xdc/0x108
>> 00: [ 330.682779] [<00000000537dcdd0>] system_call+0xd8/0x2b4
>> 00: [ 330.682791] INFO: lockdep is turned off.
>> 00: [ 330.682801] Last Breaking-Event-Address:
>> 00: [ 330.682815] [<00000000531d9ca8>] __vma_adjust+0xcf0/0xf30
>> 00: [ 330.682833] Kernel panic - not syncing: Fatal exception: panic_on_oops
>
>Our internal syzbot instance also hit this bug and bisected to the same patch.
>
>Report:
>
>[ 74.249839][ T8601] vma ffff88808c0f7eb0 start 0000000020000000 end
>0000000021000000
>[ 74.249839][ T8601] next ffff888095f5e568 prev ffff888091279318 mm
>ffff8880894555c0
>[ 74.249839][ T8601] prot 25 anon_vma ffff88809a9c4b40 vm_ops 0000000000000000
>[ 74.249839][ T8601] pgoff 20000 file 0000000000000000 private_data
>0000000000000000
>[ 74.249839][ T8601] flags:
>0x8100077(read|write|exec|mayread|maywrite|mayexec|account|softdirty)
>[ 74.289454][ T8601] ------------[ cut here ]------------
>[ 74.294941][ T8601] kernel BUG at include/linux/rmap.h:159!
>[ 74.301474][ T8601] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
>[ 74.307549][ T8601] CPU: 0 PID: 8601 Comm: syz-executor.0 Not
>tainted 5.4.0-rc2-next-20191008 #0
>[ 74.316453][ T8601] Hardware name: Google Google Compute
>Engine/Google Compute Engine, BIOS Google 01/01/2011
>[ 74.327161][ T8601] RIP: 0010:__vma_adjust+0x151c/0x1cc0
>[ 74.332604][ T8601] Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee
>0f 82 1b fe ff ff 45 31 ed e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8
>e8 76 62 fc ff <0f> 0b e8 6d 00 d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f
>85 20 07 00
>[ 74.352189][ T8601] RSP: 0018:ffff8880a0e9f9c0 EFLAGS: 00010286
>[ 74.358232][ T8601] RAX: 0000000000000147 RBX: dffffc0000000000
>RCX: 0000000000000000
>[ 74.366180][ T8601] RDX: 0000000000000000 RSI: ffffffff815cb676
>RDI: ffffed10141d3f12
>[ 74.374126][ T8601] RBP: ffff8880a0e9fa88 R08: 0000000000000147
>R09: ffffed1015d06161
>[ 74.382076][ T8601] R10: ffffed1015d06160 R11: ffff8880ae830b07
>R12: ffff888095f28e10
>[ 74.390054][ T8601] R13: ffff88808c0f7f18 R14: 0000000000000000
>R15: 0000000000000001
>[ 74.398014][ T8601] FS: 0000000000c57940(0000)
>GS:ffff8880ae800000(0000) knlGS:0000000000000000
>[ 74.406918][ T8601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 74.413491][ T8601] CR2: 0000000020d06000 CR3: 0000000090f89000
>CR4: 00000000001406f0
>[ 74.421447][ T8601] DR0: 0000000000000000 DR1: 0000000000000000
>DR2: 0000000000000000
>[ 74.429403][ T8601] DR3: 0000000000000000 DR6: 00000000fffe0ff0
>DR7: 0000000000000400
>[ 74.437348][ T8601] Call Trace:
>[ 74.440625][ T8601] vma_merge+0xb8a/0xe60
>[ 74.444848][ T8601] ? __vma_adjust+0x1cc0/0x1cc0
>[ 74.449677][ T8601] ? __sanitizer_cov_trace_cmp8+0x18/0x20
>[ 74.455369][ T8601] ? __vm_enough_memory+0x1b7/0x390
>[ 74.460542][ T8601] mmap_region+0x3e0/0x1760
>[ 74.465025][ T8601] ? __x64_sys_brk+0x760/0x760
>[ 74.469766][ T8601] ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
>[ 74.475991][ T8601] ? get_unmapped_area+0x2ad/0x3d0
>[ 74.481075][ T8601] do_mmap+0x853/0x1190
>[ 74.485216][ T8601] vm_mmap_pgoff+0x1c5/0x230
>[ 74.489784][ T8601] ? randomize_stack_top+0x110/0x110
>[ 74.495044][ T8601] ? __kasan_check_read+0x11/0x20
>[ 74.500042][ T8601] ? _copy_to_user+0x118/0x160
>[ 74.504782][ T8601] ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
>[ 74.511007][ T8601] ksys_mmap_pgoff+0xf7/0x630
>[ 74.515662][ T8601] ? find_mergeable_anon_vma+0x2e0/0x2e0
>[ 74.521295][ T8601] ? trace_hardirqs_on_thunk+0x1a/0x20
>[ 74.526735][ T8601] ? trace_hardirqs_on_thunk+0x1a/0x20
>[ 74.532181][ T8601] ? do_syscall_64+0x26/0x760
>[ 74.536835][ T8601] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
>[ 74.542881][ T8601] __x64_sys_mmap+0xe9/0x1b0
>[ 74.547448][ T8601] do_syscall_64+0xfa/0x760
>[ 74.551928][ T8601] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>[ 74.557796][ T8601] RIP: 0033:0x459a59
>[ 74.561682][ T8601] Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b
>4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84
>00 00 00 00
>[ 74.581261][ T8601] RSP: 002b:00007ffcc91b5068 EFLAGS: 00000246
>ORIG_RAX: 0000000000000009
>[ 74.589731][ T8601] RAX: ffffffffffffffda RBX: 0000000000000006
>RCX: 0000000000459a59
>[ 74.597685][ T8601] RDX: ffffffffefffffff RSI: 0000000000004000
>RDI: 0000000020196000
>[ 74.605632][ T8601] RBP: 000000000075bf20 R08: ffffffffffffffff
>R09: 0000000000000000
>[ 74.613580][ T8601] R10: 0000000000008032 R11: 0000000000000246
>R12: 0000000000c57914
>[ 74.621527][ T8601] R13: 00000000004c6176 R14: 00000000004db118
>R15: 00000000ffffffff
>[ 74.629486][ T8601] Modules linked in:
>[ 74.636716][ T8601] ---[ end trace aa2e499bc1c6fb5e ]---
>[ 74.642235][ T8601] RIP: 0010:__vma_adjust+0x151c/0x1cc0
>[ 74.647787][ T8601] Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee
>0f 82 1b fe ff ff 45 31 ed e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8
>e8 76 62 fc ff <0f> 0b e8 6d 00 d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f
>85 20 07 00
>[ 74.667752][ T8601] RSP: 0018:ffff8880a0e9f9c0 EFLAGS: 00010286
>[ 74.673806][ T8601] RAX: 0000000000000147 RBX: dffffc0000000000
>RCX: 0000000000000000
>[ 74.681794][ T8601] RDX: 0000000000000000 RSI: ffffffff815cb676
>RDI: ffffed10141d3f12
>[ 74.689779][ T8601] RBP: ffff8880a0e9fa88 R08: 0000000000000147
>R09: ffffed1015d06161
>[ 74.698081][ T8601] R10: ffffed1015d06160 R11: ffff8880ae830b07
>R12: ffff888095f28e10
>[ 74.706052][ T8601] R13: ffff88808c0f7f18 R14: 0000000000000000
>R15: 0000000000000001
>[ 74.714061][ T8601] FS: 0000000000c57940(0000)
>GS:ffff8880ae800000(0000) knlGS:0000000000000000
>[ 74.723209][ T8601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 74.729820][ T8601] CR2: 0000000020d06000 CR3: 0000000090f89000
>CR4: 00000000001406f0
>[ 74.738021][ T8601] DR0: 0000000000000000 DR1: 0000000000000000
>DR2: 0000000000000000
>[ 74.745972][ T8601] DR3: 0000000000000000 DR6: 00000000fffe0ff0
>DR7: 0000000000000400
>[ 74.753968][ T8601] Kernel panic - not syncing: Fatal exception
>
>
>Syzbot reproducer:
>mmap(&(0x7f0000196000/0x4000)=nil, 0x4000, PROT_NONE, 0x4032 /* flags=
>MAP_NORESERVE|MAP_ANONYMOUS|MAP_FIXED|PROT_WRITE*/, -1, 0x0)
>mmap(&(0x7f0000196000/0x4000)=nil, 0x4000, 0xffffffffefffffff, 0x8032
>/* flags= MAP_POPULATE|MAP_ANONYMOUS|MAP_FIXED|PROT_WRITE*/, -1, 0x0)
>
>Shakeel
--
Wei Yang
Help you, Help me
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390
2019-10-10 2:36 ` Wei Yang
@ 2019-10-10 3:15 ` Wei Yang
2019-10-10 8:29 ` Konstantin Khlebnikov
0 siblings, 1 reply; 8+ messages in thread
From: Wei Yang @ 2019-10-10 3:15 UTC (permalink / raw)
To: Wei Yang
Cc: Shakeel Butt, Qian Cai, Andrew Morton, Konstantin Khlebnikov,
Rik van Riel, Linux MM, LKML, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-s390
On Thu, Oct 10, 2019 at 10:36:01AM +0800, Wei Yang wrote:
>Hi, Qian, Shakeel
>
>Thanks for testing.
>
>Sounds I missed some case to handle. anon_vma_clone() now would be called in
>vma_adjust, which is a different case when it is introduced.
>
Well, I have to correct my statement. The reason is we may did something more
in anon_vma_clone().
Here is a quick fix, while I need to go through all the cases carefully.
diff --git a/mm/rmap.c b/mm/rmap.c
index 12f6c3d7fd9d..2844f442208d 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -271,7 +271,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
* 1. Parent has vm_prev, which implies we have vm_prev.
* 2. Parent and its vm_prev have the same anon_vma.
*/
- if (pprev && pprev->anon_vma == src->anon_vma)
+ if (!dst->anon_vma && pprev && pprev->anon_vma == src->anon_vma)
dst->anon_vma = prev->anon_vma;
list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) {
>BTW, do you have the specific test case? So that I could verify my change. The
>kernel build test doesn't trigger this.
>
>Thanks a lot :-)
>
>On Wed, Oct 09, 2019 at 03:21:11PM -0700, Shakeel Butt wrote:
>--
>Wei Yang
>Help you, Help me
--
Wei Yang
Help you, Help me
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390
2019-10-10 3:15 ` Wei Yang
@ 2019-10-10 8:29 ` Konstantin Khlebnikov
2019-10-10 12:14 ` Wei Yang
2019-10-10 14:03 ` Wei Yang
0 siblings, 2 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2019-10-10 8:29 UTC (permalink / raw)
To: Wei Yang
Cc: Shakeel Butt, Qian Cai, Andrew Morton, Rik van Riel, Linux MM,
LKML, Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
linux-s390
On 10/10/2019 06.15, Wei Yang wrote:
> On Thu, Oct 10, 2019 at 10:36:01AM +0800, Wei Yang wrote:
>> Hi, Qian, Shakeel
>>
>> Thanks for testing.
>>
>> Sounds I missed some case to handle. anon_vma_clone() now would be called in
>> vma_adjust, which is a different case when it is introduced.
>>
>
> Well, I have to correct my statement. The reason is we may did something more
> in anon_vma_clone().
>
> Here is a quick fix, while I need to go through all the cases carefully.
Oops, I've overlooked this case too.
You have to check src->anon_vma
otherwise in __split_vma or copy_vma dst could pick completely random anon_vma.
Also checking prev will not hurt, just to be sure.
So, something like this should work:
if (!dst->anon_vma && src->anon_vma &&
prev && pprev && pprev->anon_vma == src->anon_vma)
dst->anon_vma = prev->anon_vma;
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 12f6c3d7fd9d..2844f442208d 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -271,7 +271,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
> * 1. Parent has vm_prev, which implies we have vm_prev.
> * 2. Parent and its vm_prev have the same anon_vma.
> */
> - if (pprev && pprev->anon_vma == src->anon_vma)
> + if (!dst->anon_vma && pprev && pprev->anon_vma == src->anon_vma)
> dst->anon_vma = prev->anon_vma;
>
> list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) {
>
>> BTW, do you have the specific test case? So that I could verify my change. The
>> kernel build test doesn't trigger this.
>>
>> Thanks a lot :-)
>>
>> On Wed, Oct 09, 2019 at 03:21:11PM -0700, Shakeel Butt wrote:
>> --
>> Wei Yang
>> Help you, Help me
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390
2019-10-10 8:29 ` Konstantin Khlebnikov
@ 2019-10-10 12:14 ` Wei Yang
2019-10-10 14:03 ` Wei Yang
1 sibling, 0 replies; 8+ messages in thread
From: Wei Yang @ 2019-10-10 12:14 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Wei Yang, Shakeel Butt, Qian Cai, Andrew Morton, Rik van Riel,
Linux MM, LKML, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-s390
On Thu, Oct 10, 2019 at 11:29:44AM +0300, Konstantin Khlebnikov wrote:
>On 10/10/2019 06.15, Wei Yang wrote:
>> On Thu, Oct 10, 2019 at 10:36:01AM +0800, Wei Yang wrote:
>> > Hi, Qian, Shakeel
>> >
>> > Thanks for testing.
>> >
>> > Sounds I missed some case to handle. anon_vma_clone() now would be called in
>> > vma_adjust, which is a different case when it is introduced.
>> >
>>
>> Well, I have to correct my statement. The reason is we may did something more
>> in anon_vma_clone().
>>
>> Here is a quick fix, while I need to go through all the cases carefully.
>
>Oops, I've overlooked this case too.
>
>You have to check src->anon_vma
>otherwise in __split_vma or copy_vma dst could pick completely random anon_vma.
>
>Also checking prev will not hurt, just to be sure.
>
>So, something like this should work:
>
>if (!dst->anon_vma && src->anon_vma &&
> prev && pprev && pprev->anon_vma == src->anon_vma)
> dst->anon_vma = prev->anon_vma;
>
This may not be the root cause, I found another problem of it.
Let me prepare a patch to fix it.
>>
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 12f6c3d7fd9d..2844f442208d 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -271,7 +271,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
>> * 1. Parent has vm_prev, which implies we have vm_prev.
>> * 2. Parent and its vm_prev have the same anon_vma.
>> */
>> - if (pprev && pprev->anon_vma == src->anon_vma)
>> + if (!dst->anon_vma && pprev && pprev->anon_vma == src->anon_vma)
>> dst->anon_vma = prev->anon_vma;
>> list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) {
>>
>> > BTW, do you have the specific test case? So that I could verify my change. The
>> > kernel build test doesn't trigger this.
>> >
>> > Thanks a lot :-)
>> >
>> > On Wed, Oct 09, 2019 at 03:21:11PM -0700, Shakeel Butt wrote:
>> > --
>> > Wei Yang
>> > Help you, Help me
>>
--
Wei Yang
Help you, Help me
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "reuse mergeable anon_vma as parent when fork" causes a crash on s390
2019-10-10 8:29 ` Konstantin Khlebnikov
2019-10-10 12:14 ` Wei Yang
@ 2019-10-10 14:03 ` Wei Yang
1 sibling, 0 replies; 8+ messages in thread
From: Wei Yang @ 2019-10-10 14:03 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Wei Yang, Shakeel Butt, Qian Cai, Andrew Morton, Rik van Riel,
Linux MM, LKML, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-s390
On Thu, Oct 10, 2019 at 11:29:44AM +0300, Konstantin Khlebnikov wrote:
>On 10/10/2019 06.15, Wei Yang wrote:
>> On Thu, Oct 10, 2019 at 10:36:01AM +0800, Wei Yang wrote:
>> > Hi, Qian, Shakeel
>> >
>> > Thanks for testing.
>> >
>> > Sounds I missed some case to handle. anon_vma_clone() now would be called in
>> > vma_adjust, which is a different case when it is introduced.
>> >
>>
>> Well, I have to correct my statement. The reason is we may did something more
>> in anon_vma_clone().
>>
>> Here is a quick fix, while I need to go through all the cases carefully.
>
>Oops, I've overlooked this case too.
>
>You have to check src->anon_vma
>otherwise in __split_vma or copy_vma dst could pick completely random anon_vma.
>
Per my understanding, the root cause is commit 7a3ef208e662 did a little
further for the reuse case.
We intend to reuse anon_vma on fork, but we also did this when we just want a
copy of src, like __split_vma(), copy_vma() and __vma_split(). This will lead
to a random anon_vma and not what we expect.
A fix patch is sent for this.
>Also checking prev will not hurt, just to be sure.
>
>So, something like this should work:
>
>if (!dst->anon_vma && src->anon_vma &&
> prev && pprev && pprev->anon_vma == src->anon_vma)
> dst->anon_vma = prev->anon_vma;
>
>>
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 12f6c3d7fd9d..2844f442208d 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -271,7 +271,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
>> * 1. Parent has vm_prev, which implies we have vm_prev.
>> * 2. Parent and its vm_prev have the same anon_vma.
>> */
>> - if (pprev && pprev->anon_vma == src->anon_vma)
>> + if (!dst->anon_vma && pprev && pprev->anon_vma == src->anon_vma)
>> dst->anon_vma = prev->anon_vma;
>> list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) {
>>
>> > BTW, do you have the specific test case? So that I could verify my change. The
>> > kernel build test doesn't trigger this.
>> >
>> > Thanks a lot :-)
>> >
>> > On Wed, Oct 09, 2019 at 03:21:11PM -0700, Shakeel Butt wrote:
>> > --
>> > Wei Yang
>> > Help you, Help me
>>
--
Wei Yang
Help you, Help me
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-10-10 14:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-09 21:29 "reuse mergeable anon_vma as parent when fork" causes a crash on s390 Qian Cai
2019-10-09 22:21 ` Shakeel Butt
2019-10-10 0:04 ` Andrew Morton
2019-10-10 2:36 ` Wei Yang
2019-10-10 3:15 ` Wei Yang
2019-10-10 8:29 ` Konstantin Khlebnikov
2019-10-10 12:14 ` Wei Yang
2019-10-10 14:03 ` Wei Yang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).