From: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org>
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-GANU6spQydw@public.gmane.org>
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.
WARNING: multiple messages have this Message-ID (diff)
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:45 UTC|newest]
Thread overview: 9+ 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 ` Daniel Lezcano
[not found] ` <1322956280-13831-1-git-send-email-daniel.lezcano-GANU6spQydw@public.gmane.org>
2011-12-03 23:51 ` [PATCH 1/1][v2] Add reboot_pid_ns to handle the reboot syscall Daniel Lezcano
2011-12-03 23:51 ` Daniel Lezcano
[not found] ` <1322956280-13831-2-git-send-email-daniel.lezcano-GANU6spQydw@public.gmane.org>
2011-12-04 15:45 ` Oleg Nesterov [this message]
2011-12-04 15:45 ` Oleg Nesterov
[not found] ` <20111204154543.GA23805-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-12-04 19:25 ` Daniel Lezcano
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-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=daniel.lezcano-GANU6spQydw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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.