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: 28+ 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
[not found] ` <874lwqyo8i.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-05-12 17:55 ` [REVIEW][PATCH] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes Eric W. Biederman
2017-05-12 17:55 ` Eric W. Biederman
[not found] ` <87d1bex8mt.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-05-12 19:33 ` Guenter Roeck
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.