Re: [PATCH try #4] proc: fix PAGE_SIZE limit of /proc/$PID/cmdline

[Jan Stancek <jstancek@redhat.com>]

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