From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968133AbcA0VIF (ORCPT ); Wed, 27 Jan 2016 16:08:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56592 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965902AbcA0VH5 (ORCPT ); Wed, 27 Jan 2016 16:07:57 -0500 Date: Wed, 27 Jan 2016 22:07:54 +0100 From: Oleg Nesterov To: Andrew Morton Cc: Peter Zijlstra , Sasha Levin , linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [PATCH] signals: work around random wakeups in sigsuspend() Message-ID: <20160127210754.GA1593@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> <20160127103944.9216fd184af420f0c44603f1@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160127103944.9216fd184af420f0c44603f1@linux-foundation.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/27, Andrew Morton wrote: > > On Wed, 27 Jan 2016 17:41:54 +0100 Oleg Nesterov wrote: > > > 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. perhaps we can add a comment somewhere in sched.h to explain that a task can never sleep with task->state == STATE if signal_pending_state(STATE) is true. Every user of signal_pending() in the wait-event-like loop relies on this well- known fact. Say, wait_event_interruptible() or __mutex_lock_common(). This is actually more about task->state, not about TIF_SIGPENDING imo. Oleg.