Re: Threads stuck in zap_pid_ns_processes()

From	ebiederm@xmission.com (Eric W. Biederman)
Newsgroups	linux.kernel
Subject	Re: Threads stuck in zap_pid_ns_processes()
Date	2017-06-01 19:20 +0200
Message-ID	<tNBVo-5uA-33@gated-at.bofh.it> (permalink)
References	(8 earlier) <tGm55-7o1-37@gated-at.bofh.it> <tGmHM-7YH-9@gated-at.bofh.it> <tGoJA-YD-3@gated-at.bofh.it> <tGpcB-1r5-1@gated-at.bofh.it> <tGGn8-4So-27@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Guenter Roeck <linux@roeck-us.net> writes:
>
> I think you nailed it. If I drop CLONE_NEWPID from the reproducer I get
> a zombie process.
>
> I guess the only question left is if zap_pid_ns_processes() should (or could)
> somehow detect that situation and return instead of waiting forever.
> What do you think ?

Any chance you can point me at the chromium code that is performing the
ptrace?

I want to conduct a review of the kernel semantics to see if the current
semantics make it unnecessarily easy to get into hang situations.  If
the semantics make it really easy to get into a hang situation I want
to see if there is anything we can do to delicately change the semantics
to avoid the hangs without breaking existing userspace.

We have a real problem in exec which has similar semantics and as long
as I am looking at one I figure I should look at the other.

Eric

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-06-01 19:20 +0200
  Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-06-01 20:50 +0200
    Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-06-01 21:50 +0200
      Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-06-01 23:50 +0200
        Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-06-02 03:20 +0200

csiph-web