From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754843AbcAZGoc (ORCPT ); Tue, 26 Jan 2016 01:44:32 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35407 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbcAZGoa (ORCPT ); Tue, 26 Jan 2016 01:44:30 -0500 Date: Tue, 26 Jan 2016 07:44:25 +0100 From: Ingo Molnar To: Sasha Levin Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, oleg@redhat.com, peterz@infradead.org, Linus Torvalds , Thomas Gleixner , Peter Zijlstra Subject: Re: [PATCH] signals: work around random wakeups in sigsuspend() Message-ID: <20160126064425.GA5134@gmail.com> References: <1453735306-13519-1-git-send-email-sasha.levin@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1453735306-13519-1-git-send-email-sasha.levin@oracle.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Sasha Levin wrote: > A random wakeup can get us out of sigsuspend() without TIF_SIGPENDING > being set. > > Avoid that by making sure we were signaled, like sys_pause() does. > > Signed-off-by: Sasha Levin > --- > kernel/signal.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/kernel/signal.c b/kernel/signal.c > index 5da9180..3256c7e 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -3528,8 +3528,10 @@ static int sigsuspend(sigset_t *set) > current->saved_sigmask = current->blocked; > set_current_blocked(set); > > - __set_current_state(TASK_INTERRUPTIBLE); > - schedule(); > + while (!signal_pending(current)) { > + __set_current_state(TASK_INTERRUPTIBLE); > + schedule(); > + } > set_restore_sigmask(); > return -ERESTARTNOHAND; > } So this does not appear to be anything new, right? I agree with the fix, but I'm somewhat worried about the potential ABI impact: does anything exist out there that has learned to rely on spurious returns from SyS_sigsuspend() or SyS_rt_sigsuspend() system calls? These are one of the most frequently used system calls in signal based event loops. Thanks, Ingo