From: Oleg Nesterov <oleg@redhat.com>
To: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: akpm@linux-foundation.org, serge.hallyn@canonical.com,
containers@lists.linux-foundation.org, gkurz@fr.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1][v2] Add reboot_pid_ns to handle the reboot syscall
Date: Sun, 4 Dec 2011 16:45:43 +0100 [thread overview]
Message-ID: <20111204154543.GA23805@redhat.com> (raw)
In-Reply-To: <1322956280-13831-2-git-send-email-daniel.lezcano@free.fr>
On 12/04, Daniel Lezcano wrote:
>
> @@ -32,6 +32,8 @@ struct pid_namespace {
> #endif
> gid_t pid_gid;
> int hide_pid;
> + int reboot;
> + spinlock_t reboot_lock;
> };
Well. I was thinking about the serialization too, but this
->reboot_lock asks for v3 imho ;)
First of all, do we really care? force_sig(SIGKILL, child_reaper)
can't race with itself, it does nothing if init is already killed.
So why it is important to protect pid_ns->reboot? Yes, it is possible
to change it again if two callers do sys_reboot() "at the same time".
But in this case we can't predict which caller wins anyway, so why
should we worry?
IOW. Say, we have the 2 tasks doing HALT and RESTART in parallel.
It is possible that HALT sets ->reboot and kills init first, then
RESTART changes ->reboot and the second force_sig() does nothing.
In this case we can simply pretend that RESTART wins and the dying
init kills HALT before it calls sys_reboot().
In any case. Even if you want to serialize, instead of adding the
new lock reboot_pid_ns() can simply do:
if (cmpxchg(&pid_ns->reboot, 0, reboot) != 0)
return -EBUSY;
this looks much simpler to me.
Oleg.
next prev parent reply other threads:[~2011-12-04 15:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-03 23:51 [PATCH 0/1][V2] Handle reboot in a child pid namespace Daniel Lezcano
2011-12-03 23:51 ` [PATCH 1/1][v2] Add reboot_pid_ns to handle the reboot syscall Daniel Lezcano
2011-12-04 15:45 ` Oleg Nesterov [this message]
2011-12-04 19:25 ` Daniel Lezcano
2011-12-04 15:58 ` Miquel van Smoorenburg
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=20111204154543.GA23805@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=daniel.lezcano@free.fr \
--cc=gkurz@fr.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@canonical.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