[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150527105616.GA20345@dustball.brq.redhat.com>
Date: Wed, 27 May 2015 12:56:21 +0200
From: Jan Stancek <jstancek@...hat.com>
To: Jarod Wilson <jwilson@...hat.com>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
Jarod Wilson <jarod@...hat.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists