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=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 D891FC31E46 for ; Wed, 12 Jun 2019 13:09:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B6AB420874 for ; Wed, 12 Jun 2019 13:09:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2438905AbfFLNJi (ORCPT ); Wed, 12 Jun 2019 09:09:38 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:41908 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728322AbfFLNJh (ORCPT ); Wed, 12 Jun 2019 09:09:37 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1hb30R-00063y-2Z; Wed, 12 Jun 2019 07:09:35 -0600 Received: from ip72-206-97-68.om.om.cox.net ([72.206.97.68] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1hb30Q-00066J-7v; Wed, 12 Jun 2019 07:09:34 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: David Laight 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" 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> <20190611185548.GA31214@redhat.com> Date: Wed, 12 Jun 2019 08:09:17 -0500 In-Reply-To: (David Laight's message of "Wed, 12 Jun 2019 08:39:53 +0000") Message-ID: <874l4v0x36.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1hb30Q-00066J-7v;;;mid=<874l4v0x36.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=72.206.97.68;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19+satK9tmg8L1GuZ+k6WyPXv9z0Jmmtd4= X-SA-Exim-Connect-IP: 72.206.97.68 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Laight writes: > From: Oleg Nesterov [mailto:oleg@redhat.com] >> Sent: 11 June 2019 19:56 >> On 06/10, Eric W. Biederman wrote: >> > >> > Personally I don't think anyone sane would intentionally depend on this >> > and I don't think there is a sufficiently reliable way to depend on this >> > by accident that people would actually be depending on it. >> >> Agreed. >> >> As I said I like these changes and I see nothing wrong. To me they fix the >> current behaviour, or at least make it more consistent. >> >> But perhaps this should be documented in the changelog? To make it clear >> that this change was intentional. > > What happens if you run the test program I posted yesterday after the changes? > > It looks like pselect() and epoll_pwait() operated completely differently. > pselect() would always calls the signal handlers. > epoll_pwait() only calls them when EINTR is returned. > So changing epoll_pwait() and pselect() to work the same way > is bound to break some applications. That is not the change we are discussing. We are looking at making pselect and epoll_pwait act a little more like sigtimedwait. In particular we are discussiong signals whose handler is SIG_DFL and whose default disposition is to kill the process, such as SIGINT. When those signals are delivered and they are not blocked, we take an optimized path in complete_signal and start the process tear down. That early start of process tear down does not happen if the signal is blocked or it happens to be in real_blocked (from sigtimedwait). This matters is the small time window where the signal is received while the process has temporarily unblocked the signal, and the signal is not detected by the code and blocked and oridinarily would not be delivered until next time because of restore_sigmask_unless. If the tear down has started early. Even if we would not have returned the process normally the signal can kill the process. AKA epoll_pwait can today result in it's caller being killed without -EINTR being returned. My change fixes that behavior and disables the early process tear down for those signals, by having real_blocked match the set of signals that are normally blocked by the process. The result should be the signal will have to wait for the next call that temporarily unblocked the process. The real benefit is that that the code becomes more comprehensible. It is my patch that titled: "signal: Always keep real_blocked in sync with blocked" that causes that to happen. Eric