From: Oleg Nesterov <oleg@redhat.com>
To: Demi Marie Obenour <demiobenour@gmail.com>,
Christian Brauner <brauner@kernel.org>,
Mateusz Guzik <mjguzik@gmail.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: PID namespace init releases its file locks before its children die
Date: Fri, 3 Oct 2025 14:38:28 +0200 [thread overview]
Message-ID: <20251003123828.GA26441@redhat.com> (raw)
In-Reply-To: <58ac5d49-14a9-4fe6-a5a4-746d6b73f82b@gmail.com>
Add CCs.
I can't really help, just my 2 cents...
I don't think we can change do_exit() to call exit_files() after
exit_notify().
At first glance, technically it is possible to change do_exit() so
that the exiting reaper does zap_pid_ns_processes() earlier... But
even if this is possible, I think that this complication needs more
justification.
Oleg.
On 10/02, Demi Marie Obenour wrote:
>
> I noticed that PID 1 in a PID namespace can release file locks (due
> to exiting) while its children are still running for a bit. If the
> locks held by PID 1 were relied to serialize the execution of its
> child processes, this could result in data corruption.
>
> Specifically, the child processes are killed via exit_notify() ->
> forget_original_parent() -> find_child_reaper() ->
> zap_pid_ns_processes(). That comes *after* exit_files(), which
> releases the file locks.
>
> While it is possible to implement this with cgroups, cgroups
> are quite a bit more complicated to use, at least compared to
> a single call to unshare() before fork().
>
> Is this intentional? Changing the behavior would make supervision
> trees significantly easier to properly implement.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
next prev parent reply other threads:[~2025-10-03 12:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 18:22 PID namespace init releases its file locks before its children die Demi Marie Obenour
2025-10-03 12:38 ` Oleg Nesterov [this message]
2025-10-03 17:09 ` Demi Marie Obenour
2025-10-07 12:02 ` Christian Brauner
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=20251003123828.GA26441@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=demiobenour@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.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.