From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09B6E1C3F3B for ; Fri, 20 Dec 2024 13:06:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734699995; cv=none; b=n9D72p3SdKJYshmtogUSiIPXDbbqLEkzEJ26kHWxQsLDI2r76NdWIfMJ3tgNdSzbZDEY/JUvpEczoPYIpKcgSi6toA1+YDiq+Xvnno9vd46wYDxuRFYxmqe3ELJBRozGg1XnS1nL4DMFKDRSY+Sf3ofxLI5HjYX4eDsHnUBx+/Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734699995; c=relaxed/simple; bh=yrQbu6T5rv5acquq4V/I/qEirbMpC6UBVDiQ3j5+UFI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AUrks7ex27psndjaWpKjoutajYNwfbk3vfvrxednZznMTDRZyrj5AkpBlTjrSwPGTwYi5SdQUINmTUkeyLffQRPgVDfT2Uaw3rwETzkUVkMmKVwuR7kQETOv48OcEtfVU21cYDtlh/rJN/gyGlIFrREl6pYHslMX9JTjNyJKiaQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PCK2ZXH+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PCK2ZXH+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3882AC4CEDC; Fri, 20 Dec 2024 13:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734699994; bh=yrQbu6T5rv5acquq4V/I/qEirbMpC6UBVDiQ3j5+UFI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PCK2ZXH+wffHUVTRjG/MEK2fMGvUDhnKQZogzDe/uSwbrgk6AwjUByotguCVLmcUX dQCa8r+fy+tIugbF4qtce8wcPjJX7bFRcpssAoh/tvHPXvZ7LpGEijDzepOREYmJNo /saIwxDKistHtokC1ZEAhDJ4IIyEHUltQpa4/N95fc311lMlR+0qHmGPgjSaXYX126 48mQ8b4bxu5ivKLS4w+KHA2sfplw2BwYS3n12DlZYJ/U+kUdZCmgcT9hPLhhGiEZTg NEUxofsETW39dnoEOFIlpQsfEQoXkPtrdS0QibcdI7aWrCdaNUe8F3nVQG9z8xqslW XK4OjccUDQftg== Date: Fri, 20 Dec 2024 14:06:31 +0100 From: Frederic Weisbecker To: Thomas Gleixner Cc: syzbot , anna-maria@linutronix.de, linux-kernel@vger.kernel.org, peterz@infradead.org, syzkaller-bugs@googlegroups.com, Eric Biederman , Oleg Nesterov Subject: Re: [PATCH] signal/posixtimers: Handle ignore/blocked sequences correctly Message-ID: References: <6761b16e.050a0220.29fcd0.006d.GAE@google.com> <87ikrf78xa.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ikrf78xa.ffs@tglx> Le Thu, Dec 19, 2024 at 08:46:25PM +0100, Thomas Gleixner a écrit : > kernel/signal.c | 38 +++++++++++++++++++++++++++++--------- > 1 file changed, 29 insertions(+), 9 deletions(-) > > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2007,11 +2007,23 @@ void posixtimer_send_sigqueue(struct k_i > > if (!list_empty(&q->list)) { > /* > - * If task group is exiting with the signal already pending, > - * wait for __exit_signal() to do its job. Otherwise if > - * ignored, it's not supposed to be queued. Try to survive. > + * The signal was ignored and blocked. The timer > + * expiry queued it because blocked signals are > + * queued independent of the ignored state. > + * > + * The unblocking set SIGPENDING, but the signal > + * was not yet dequeued from the pending list, > + * which would have put it back on the ignore list. I must be missing something. I don't see dequeue_signal() checking if a signal is ignored upon delivery. > + * So prepare_signal() sees unblocked and ignored, > + * which ends up here. Leave it queued like a > + * regular signal. > + * > + * The same happens when the task group is exiting > + * and the signal is already queued. > + * prepare_signal() treats SIGNAL_GROUP_EXIT as > + * ignored independent of its queued state. This > + * gets cleaned up in __exit_signal(). > */ > - WARN_ON_ONCE(!(t->signal->flags & SIGNAL_GROUP_EXIT)); > goto out; > } > > @@ -2046,17 +2058,25 @@ void posixtimer_send_sigqueue(struct k_i > goto out; > } > > - /* This should never happen and leaks a reference count */ > - if (WARN_ON_ONCE(!hlist_unhashed(&tmr->ignored_list))) > - hlist_del_init(&tmr->ignored_list); > - > if (unlikely(!list_empty(&q->list))) { > /* This holds a reference count already */ > result = TRACE_SIGNAL_ALREADY_PENDING; > goto out; > } > > - posixtimer_sigqueue_getref(q); > + /* > + * If the signal is on the ignore list, it got blocked after it was > + * ignored earlier. But nothing lifted the ignore. Move it back to > + * the pending list to be consistent with the regular signal > + * handling. If it gets unblocked, it will be ignored again unless I'm not sure about that. If I follow the sigprocmask() path, set_task_blocked() doesn't take care about that. And later on, dequeue_signal() doesn't seem to check either... Thanks. > + * a handler has been installed before unblocking. If it's not on > + * the ignore list acquire a reference count. > + */ > + if (likely(hlist_unhashed(&tmr->ignored_list))) > + posixtimer_sigqueue_getref(q); > + else > + hlist_del_init(&tmr->ignored_list); > + > posixtimer_queue_sigqueue(q, t, tmr->it_pid_type); > result = TRACE_SIGNAL_DELIVERED; > out: