From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S935457AbcA0Sjr (ORCPT <rfc822;w@1wt.eu>);
	Wed, 27 Jan 2016 13:39:47 -0500
Received: from mail.linuxfoundation.org ([140.211.169.12]:52781 "EHLO
	mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S935111AbcA0Sjp (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Jan 2016 13:39:45 -0500
Date: Wed, 27 Jan 2016 10:39:44 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Sasha Levin <sasha.levin@oracle.com>, linux-kernel@vger.kernel.org,
        mingo@kernel.org
Subject: Re: [PATCH] signals: work around random wakeups in sigsuspend()
Message-Id: <20160127103944.9216fd184af420f0c44603f1@linux-foundation.org>
In-Reply-To: <20160127164154.GB14320@redhat.com>
References: <1453735306-13519-1-git-send-email-sasha.levin@oracle.com>
	<20160125133205.36542c86ada93761d8a9ff06@linux-foundation.org>
	<20160126211009.GA4695@redhat.com>
	<20160127084443.GL6357@twins.programming.kicks-ass.net>
	<20160127164154.GB14320@redhat.com>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 27 Jan 2016 17:41:54 +0100 Oleg Nesterov <oleg@redhat.com> wrote:

> > But it did get me to
> > look at the patch again:
> >
> > +       while (!signal_pending(current)) {
> > +               __set_current_state(TASK_INTERRUPTIBLE);
> > +               schedule();
> > +       }
> >
> > That should very much be:
> >
> > 	for (;;) {
> > 		set_current_state(TASK_INTERRUPTIBLE);
> > 		if (signal_pending(current))
> > 			break;
> > 		schedule();
> > 	}
> > 	__set_current_state(TASK_RUNNING);
> 
> Why? It should work either way. Yes, signal_wakeup() can come right before
> __set_current_state(TASK_INTERRUPTIBLE) but this is fine, __schedule() must not
> sleep if signal_pending() == T, that is why it checks signal_pending_state().
> See also the comment above smp_mb__before_spinlock() in schedule().
> 
> IOW, signal_pending() is the "special" condition, you do not need to serialize
> this check with task->state setting, exactly because schedule() knows about the
> signals.

So it's non-buggy because signal_pending() is special.  But it *looks*
buggy!  And there's no comment there explaining why it looks buggy but
isn't, so someone may later come along and "fix" it for us.