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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 D7470C31E46 for ; Wed, 12 Jun 2019 13:24:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BB57F20866 for ; Wed, 12 Jun 2019 13:24:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439082AbfFLNYm convert rfc822-to-8bit (ORCPT ); Wed, 12 Jun 2019 09:24:42 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([146.101.78.151]:47946 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437469AbfFLNYm (ORCPT ); Wed, 12 Jun 2019 09:24:42 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-189-CYuI-zRlOtGfu46-Pzuvvw-1; Wed, 12 Jun 2019 14:24:38 +0100 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b::d117) by AcuMS.aculab.com (fd9f:af1c:a25b::d117) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 12 Jun 2019 14:24:38 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 12 Jun 2019 14:24:38 +0100 From: David Laight To: "'Eric W. Biederman'" CC: 'Oleg Nesterov' , '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 Thread-Topic: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask Thread-Index: AQHVH9JWknGdQ9+D0UeylJNmvFzQKKaWJ31QgAAjZdCAAbHqlYAAAXJw Date: Wed, 12 Jun 2019 13:24:38 +0000 Message-ID: References: <20190522032144.10995-1-deepa.kernel@gmail.com> <20190529161157.GA27659@redhat.com> <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> <95decc6904754004af8a5546aca0468a@AcuMS.aculab.com> <87pnnj2ca0.fsf@xmission.com> In-Reply-To: <87pnnj2ca0.fsf@xmission.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: CYuI-zRlOtGfu46-Pzuvvw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org From: Eric W. Biederman > Sent: 12 June 2019 13:56 > David Laight writes: > > > From: David Laight > >> Sent: 11 June 2019 10:52 > > ... > >> 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. > >> > >> A quick test program: > >> > >> #include > >> #include > >> #include > >> > >> #include > >> #include > >> > >> int main(int argc, char **argv) > >> { > >> fd_set readfds; > >> sigset_t sig_int; > >> struct timespec delay = {1, 0}; > >> > >> sigfillset(&sig_int); > >> sigdelset(&sig_int, SIGINT); > >> > >> sighold(SIGINT); > >> > >> for (;;) { > >> FD_ZERO(&readfds); > >> FD_SET(0, &readfds); > >> pselect(1, &readfds, NULL, NULL, &delay, &sig_int); > >> > >> poll(0,0,1000); > >> } > >> } > >> > >> Run under strace to see what is happening and send SIGINT from a different terminal. > >> The program sleeps for a second in each of the pselect() and poll() calls. > >> Send a SIGINT and in terminates after pselect() returns ERESTARTNOHAND. > >> > >> Run again, this time press enter - making fd 0 readable. > >> pselect() returns 1, but the program still exits. > >> (Tested on a 5.1.0-rc5 kernel.) > >> > >> If a signal handler were defined it should be called instead. > > > > If I add a signal handler for SIGINT it is called when pselect() > > returns regardless of the return value. > > That is odd. Is this with Oleg's fix applied? No it is a 5.1.0-rc5 kernel with no related local patches. So it is the 'historic' behaviour of pselect(). But not the original one! Under 2.6.22-5-31 the signal handler isn't caller when pselect() returns 1. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)