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

[Eric W. Biederman]

Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:

> Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>
>     Serge Hallyn <serge.hallyn@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/