From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57C48C31E46 for ; Wed, 12 Jun 2019 15:38:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2C79B215EA for ; Wed, 12 Jun 2019 15:38:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731874AbfFLPiQ (ORCPT ); Wed, 12 Jun 2019 11:38:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59539 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726829AbfFLPiP (ORCPT ); Wed, 12 Jun 2019 11:38:15 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 496DF6EBA3; Wed, 12 Jun 2019 15:38:04 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.43.17.159]) by smtp.corp.redhat.com (Postfix) with SMTP id C2FBC28561; Wed, 12 Jun 2019 15:37:57 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Wed, 12 Jun 2019 17:38:04 +0200 (CEST) Date: Wed, 12 Jun 2019 17:37:57 +0200 From: Oleg Nesterov To: "Eric W. Biederman" Cc: David Laight , Andrew Morton , Deepa Dinamani , "linux-kernel@vger.kernel.org" , "arnd@arndb.de" , "dbueso@suse.de" , "axboe@kernel.dk" , "dave@stgolabs.net" , "e@80x24.org" , "jbaron@akamai.com" , "linux-fsdevel@vger.kernel.org" , "linux-aio@kvack.org" , "omar.kilani@gmail.com" , "tglx@linutronix.de" , Al Viro , Linus Torvalds , "linux-arch@vger.kernel.org" Subject: Re: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask Message-ID: <20190612153756.GD3276@redhat.com> References: <20190604134117.GA29963@redhat.com> <20190606140814.GA13440@redhat.com> <87k1dxaxcl.fsf_-_@xmission.com> <87ef45axa4.fsf_-_@xmission.com> <20190610162244.GB8127@redhat.com> <87lfy96sta.fsf@xmission.com> <9199239a450d4ea397783ccf98742220@AcuMS.aculab.com> <20190612134558.GB3276@redhat.com> <6f748b26bef748208e2a74174c0c0bfc@AcuMS.aculab.com> <87v9xayh27.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v9xayh27.fsf@xmission.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 12 Jun 2019 15:38:15 +0000 (UTC) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 06/12, Eric W. Biederman wrote: > David Laight writes: > > > From: Oleg Nesterov > >> Sent: 12 June 2019 14:46 > >> On 06/11, David Laight wrote: > >> > > >> > If I have an application that has a loop with a pselect call that > >> > enables SIGINT (without a handler) and, for whatever reason, > >> > one of the fd is always 'ready' then I'd expect a SIGINT > >> > (from ^C) to terminate the program. > > I think this gets into a quality of implementation. > > I suspect that set_user_sigmask should do: > if (signal_pending()) > return -ERESTARNOSIGHAND; /* -EINTR that restarts if nothing was pending */ > > Which should be safe as nothing has blocked yet to consume any of the > timeouts, and it should ensure that none of the routines miss a signal. Why? I don't think this makes any sense. Perhaps we could do this _after_ set_current_blocked() for the case when the already pending SIGINT was unblocked but a) I am not sure this would be really better and b) I think it is too late to change this. Oleg.