From: Oleg Nesterov <oleg@redhat.com>
To: fan.yu9@zte.com.cn, Thomas Gleixner <tglx@linutronix.de>
Cc: frederic@kernel.org, peterz@infradead.org, brauner@kernel.org,
iro@zeniv.linux.org.uk, joel.granados@kernel.org,
lorenzo.stoakes@oracle.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, xu.xin16@zte.com.cn,
yang.yang29@zte.com.cn
Subject: Re: [PATCH linux-next v2] signal: clarify __send_signal_locked comment in do_notify_parent
Date: Wed, 30 Jul 2025 17:02:40 +0200 [thread overview]
Message-ID: <20250730150240.GB5339@redhat.com> (raw)
In-Reply-To: <20250729152759994n3YKgjxLglCCPkOtYtU2U@zte.com.cn>
On 07/29, fan.yu9@zte.com.cn wrote:
>
> @@ -2252,8 +2252,10 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
> sig = 0;
> }
> /*
> - * Send with __send_signal as si_pid and si_uid are in the
> - * parent's namespaces.
> + * Use __send_signal_locked() instead of send_signal_locked()
> + * because si_pid and si_uid are already in the parent's
> + * namespace. send_signal_locked() would incorrectly modify
> + * them when crossing PID/user namespaces.
> */
Well, Thomas doesn't like the idea to kill this comment, I won't argue.
However, this comment still looks confusing to me, and I don't know how to
make it more clear. Yes, send_signal_locked() may, say, clear info->si_pid
but not "because si_pid and si_uid are already in the parent's namespace".
There are several obvious reasons not to use send_signal_locked():
1. do_notify_parent() has already correctly filled si_pid/si_uid,
the "has_si_pid_and_uid()" checks in send_signal_locked() are
pointless.
That is why I think this comment should simply die.
2. send_signal_locked() assumes that different namespaces mean
"From an ancestor namespace", but in this case the child can
send a signal to the parent namespace while "from parent ns"
is not possible.
3. send_signal_locked() assumes that "current" is a) the sender
and b) alive task. Both assumptions may be wrong if "current"
is the last exiting thread which calls do_notify_parent() from
release_task().
In this case task_pid_nr_ns(current, task_active_pid_ns(parent))
will return 0 because current->thread_pid is already NULL, and
send_signal_locked() will misinterpret this as "from parent ns"
and clear si_pid.
But imo, it is simply unsafe to use send_signal_locked() in this
case, even if currently nothing "really bad" can happen.
OTOH. This patch doesn't make the comment more confusing, plus it removes
the reference to __send_signal() which no longer exists, so let me ack
this patch and forget this surprisingly long discussion ;)
Acked-by: Oleg Nesterov <oleg@redhat.com>
next prev parent reply other threads:[~2025-07-30 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 7:27 [PATCH linux-next v2] signal: clarify __send_signal_locked comment in do_notify_parent fan.yu9
2025-07-29 15:40 ` Oleg Nesterov
2025-07-30 11:30 ` fan.yu9
2025-07-30 15:02 ` Oleg Nesterov [this message]
2025-07-31 14:39 ` fan.yu9
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=20250730150240.GB5339@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=fan.yu9@zte.com.cn \
--cc=frederic@kernel.org \
--cc=iro@zeniv.linux.org.uk \
--cc=joel.granados@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=xu.xin16@zte.com.cn \
--cc=yang.yang29@zte.com.cn \
/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.