From: ebiederm@xmission.com (Eric W. Biederman)
To: Guenter Roeck <linux@roeck-us.net>
Cc: Vovo Yang <vovoy@google.com>, Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: Threads stuck in zap_pid_ns_processes()
Date: Thu, 01 Jun 2017 12:08:58 -0500 [thread overview]
Message-ID: <87inkfab4l.fsf@xmission.com> (raw)
In-Reply-To: <e7826335-3cb5-a4bf-f382-252f8f0a94a4@roeck-us.net> (Guenter Roeck's message of "Sat, 13 May 2017 07:34:13 -0700")
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
next prev parent reply other threads:[~2017-06-01 17:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 17:11 Threads stuck in zap_pid_ns_processes() Guenter Roeck
2017-05-11 17:31 ` Eric W. Biederman
2017-05-11 18:35 ` Guenter Roeck
2017-05-11 20:23 ` Eric W. Biederman
2017-05-11 20:48 ` Guenter Roeck
2017-05-11 21:39 ` Eric W. Biederman
2017-05-11 20:21 ` Guenter Roeck
2017-05-11 21:25 ` Eric W. Biederman
2017-05-11 22:47 ` Guenter Roeck
2017-05-11 23:19 ` Eric W. Biederman
2017-05-12 9:30 ` Vovo Yang
2017-05-12 13:26 ` Eric W. Biederman
2017-05-12 16:52 ` Guenter Roeck
2017-05-12 17:33 ` Eric W. Biederman
2017-05-12 17:55 ` [REVIEW][PATCH] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes Eric W. Biederman
2017-05-12 19:33 ` Guenter Roeck
2017-05-12 19:43 ` Threads stuck in zap_pid_ns_processes() Guenter Roeck
2017-05-12 20:03 ` Eric W. Biederman
2017-05-13 14:34 ` Guenter Roeck
2017-05-13 18:21 ` Eric W. Biederman
2017-06-01 17:08 ` Eric W. Biederman [this message]
2017-06-01 18:45 ` Guenter Roeck
2017-06-01 19:36 ` Eric W. Biederman
2017-06-01 21:43 ` Guenter Roeck
2017-06-02 1:06 ` Eric W. Biederman
2017-05-12 3:42 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87inkfab4l.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mingo@kernel.org \
--cc=vovoy@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox