linux-kernel - Re: [REVIEW][PATCH] pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 08 Sep 2013 17:12:57 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Ramkumar Ramachandra <artagnon@...il.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [REVIEW][PATCH] pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup

Ramkumar Ramachandra <artagnon@...il.com> writes:

> Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
>     Serge Hallyn <serge.hallyn@...ntu.com> writes:
>     > Since commit af4b8a83add95ef40716401395b44a1b579965f4 it's been
>     > possible to get into a situation where a pidns reaper is
>     > <defunct>, reparented to host pid 1, but never reaped.  How to
>     > reproduce this is documented at
>     >
>     > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526
>     > (and see
>     >
>     https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526/comments/13)
>     > In short, run repeated starts of a container whose init is
>     >
>     > Process.exit(0);
>     >
>     > sysrq-t when such a task is playing zombie shows:
>     >
>     > [  131.132978] init            x ffff88011fc14580     0  2084  
>     2039 0x00000000
>     > [  131.132978]  ffff880116e89ea8 0000000000000002
>     ffff880116e89fd8 0000000000014580
>     > [  131.132978]  ffff880116e89fd8 0000000000014580
>     ffff8801172a0000 ffff8801172a0000
>     > [  131.132978]  ffff8801172a0630 ffff88011729fff0
>     ffff880116e14650 ffff88011729fff0
>     > [  131.132978] Call Trace:
>     > [  131.132978]  [<ffffffff816f6159>] schedule+0x29/0x70
>     > [  131.132978]  [<ffffffff81064591>] do_exit+0x6e1/0xa40
>     > [  131.132978]  [<ffffffff81071eae>] ?
>     signal_wake_up_state+0x1e/0x30
>     > [  131.132978]  [<ffffffff8106496f>] do_group_exit+0x3f/0xa0
>     > [  131.132978]  [<ffffffff810649e4>] SyS_exit_group+0x14/0x20
>     > [  131.132978]  [<ffffffff8170102f>] tracesys+0xe1/0xe6
>     
>     
> Interestingly, notice how the memory addresses begin with ffff88011,
> and then ffffffff81 in the call trace.

The cause is known and this patch fixes the problem.  So I don't know
why you would be looking at the addresses, there is no mystery to be solved.

That said roughly ffff880000000000 is where the kernel has it's identity
mapping of all physical memory in the system.

Meanwhile roughly ffffffff80000000 is the high 2GB of memory where the
kernel text pages reside.

So what is seen is exactly what is expected that the data pointers point
into the kernels identity mapping and the code address use the mapping
for kernel code.

Eric
--
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/