Messages in this thread | | | Date | Wed, 27 May 2015 12:56:21 +0200 | From | Jan Stancek <> | Subject | Re: [PATCH try #4] proc: fix PAGE_SIZE limit of /proc/$PID/cmdline |
| |
On Wed, May 27, 2015 at 01:27:13AM -0400, Jarod Wilson wrote: > On May 26, 2015, at 5:24 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote: > >> Should have tested on more than just x86, it appears. We've started > >> hammering on this internally across all arches, and its exploded > >> multiple times on ppc64 now: > >> > >> [ 2717.074699] ------------[ cut here ]------------ > >> [ 2717.074787] kernel BUG at fs/proc/base.c:244! > > > >> OE-------------- 3.10.0-255.el7.ppc64.debug #1 > > > > Which BUG_ON is this? > > > > BUG_ON(*pos < 0); > > BUG_ON(arg_start > arg_end); > > BUG_ON(env_start > env_end); >
Is create_elf_tables() taking mm->mmap_sem when it's initialising env_start/end?
I could reproduce it on x86_64 as well, just by doing exec in loop and "ps afx" in other window:
------------------------------------------ # cat a.sh b.sh go.sh #!/bin/sh exec ./b.sh skajsdlakj leakj slekj alkse j
#!/bin/sh exec ./a.sh ere rwer 23 r23 23r2 rwrd 23r
#!/bin/sh for i in `seq 1 50`; do sh ./a.sh & done ------------------------------------------ In window 1: ./go.sh In window 2: while [ True ]; do ps afx > /dev/null; done
From vmcore:
struct mm_struct { ... [0x1e0] unsigned long arg_start; [0x1e8] unsigned long arg_end; [0x1f0] unsigned long env_start; [0x1f8] unsigned long env_end;
RIP: ffffffff812996b1 RSP: ffff8800b362fe78 RFLAGS: 00010206 RAX: ffff8801b0461040 RBX: ffff8801b0460f80 RCX: 0000000000003040 RDX: 0000000000000001 RSI: ffff8801b6c00000 RDI: 0000000000000246 RBP: ffff8800b362ff00 R8: 0000000000000000 R9: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: 00007ffd3fb0d396 R13: 00007ffd3fb0d396 R14: 0000000000020000 R15: ffff8800b362ff48 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
crash> disassemble proc_pid_cmdline_read Dump of assembler code for function proc_pid_cmdline_read: ... 0xffffffff812991f2 <+178>: callq 0xffffffff816e4870 <down_read> 0xffffffff812991f7 <+183>: mov 0x1e0(%rbx),%rax # arg_start 0xffffffff812991fe <+190>: mov 0x1f8(%rbx),%rdx # env_end 0xffffffff81299205 <+197>: mov 0x1e8(%rbx),%r12 # arg_end 0xffffffff8129920c <+204>: mov 0x1f0(%rbx),%r13 # env_start 0xffffffff81299213 <+211>: mov %rax,-0x50(%rbp) 0xffffffff81299217 <+215>: mov -0x60(%rbp),%rax 0xffffffff8129921b <+219>: mov %rdx,-0x58(%rbp) 0xffffffff8129921f <+223>: mov %rax,%rdi 0xffffffff81299222 <+226>: callq 0xffffffff810bbb50 <up_read> 0xffffffff81299227 <+231>: cmp %r12,-0x50(%rbp) 0xffffffff8129922b <+235>: ja 0xffffffff812996b3 <proc_pid_cmdline_read+1395> 0xffffffff81299231 <+241>: cmp -0x58(%rbp),%r13 0xffffffff81299235 <+245>: ja 0xffffffff812996b1 <proc_pid_cmdline_read+1393>
crash> p/x ((struct mm_struct *)0xffff8801b0460f80)->arg_start $5 = 0x7ffd3fb0d365 crash> p/x ((struct mm_struct *)0xffff8801b0460f80)->arg_end $6 = 0x7ffd3fb0d396 crash> p/x ((struct mm_struct *)0xffff8801b0460f80)->env_start $7 = 0x7ffd3fb0d396 crash> p/x ((struct mm_struct *)0xffff8801b0460f80)->env_end $8 = 0x7ffd3fb0dfed
crash> x/1g (0xffff8800b362ff00-0x50) 0xffff8800b362feb0: 0x00007ffd3fb0d365
crash> x/1g (0xffff8800b362ff00-0x58) 0xffff8800b362fea8: 0x0000000000000000
Regards, Jan
| |