linux-kernel - Re: [PATCH] zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240613140216.30327-1-fuweid89@gmail.com>
Date: Thu, 13 Jun 2024 22:02:16 +0800
From: Wei Fu <fuweid89@...il.com>
To: ebiederm@...ssion.com
Cc: Sudhanva.Huruli@...rosoft.com,
	akpm@...ux-foundation.org,
	apais@...ux.microsoft.com,
	axboe@...nel.dk,
	boqun.feng@...il.com,
	brauner@...nel.org,
	frederic@...nel.org,
	fuweid89@...il.com,
	j.granados@...sung.com,
	jiangshanlai@...il.com,
	joel@...lfernandes.org,
	josh@...htriplett.org,
	linux-kernel@...r.kernel.org,
	mathieu.desnoyers@...icios.com,
	michael.christie@...cle.com,
	mjguzik@...il.com,
	neeraj.upadhyay@...nel.org,
	oleg@...hat.com,
	paulmck@...nel.org,
	qiang.zhang1211@...il.com,
	rachelmenge@...ux.microsoft.com,
	rcu@...r.kernel.org,
	rostedt@...dmis.org
Subject: Re: [PATCH] zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING

> 
> Oleg Nesterov <oleg@...hat.com> writes:
> 
> > kernel_wait4() doesn't sleep and returns -EINTR if there is no
> > eligible child and signal_pending() is true.
> >
> > That is why zap_pid_ns_processes() clears TIF_SIGPENDING but this is not
> > enough, it should also clear TIF_NOTIFY_SIGNAL to make signal_pending()
> > return false and avoid a busy-wait loop.
> 
> I took a look through the code.  It used to be that TIF_NOTIFY_SIGNAL
> was all about waking up a task so that task_work_run can be used.
> io_uring still mostly uses it that way.  There is also a use in
> kthread_stop that just uses it as a TIF_SIGPENDING without having a
> pending signal.
> 
> At the point in do_exit where exit_notify and thus zap_pid_ns_processes
> is called I can't possibly see a use for TIF_NOTIFY_SIGNAL.
> exit_task_work, exit_signals, and io_uring_cancel have all been called.
> 
> So TIF_NOTIFY_SIGNAL should be spurious at this point and safe to clear.
> Why it remains set is a mystery to me.

I think there is a case that TIF_NOTIFY_SIGNAL remains set.

Init process has main-thread, sub-thread-X and iou-wrk-thread-X (created by
sub-thread-X). When main-thread enters exit_group, both sub-thread-X and
iou-wrk-thread-X are set by TIF_SIGPENDING and wake up. The sub-thread-X could
call io_uring_cancel to set TIF_NOTIFY_SIGNAL for iou-wrk-thread-X which doesn't
have chance to clear it. And then iou-wrk-thread-X gets into zap_pid_ns_processes
function with TIF_NOTIFY_SIGNAL flag. If there are active processes in that pid
namespace, it will run into this issue.

Wei