From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751063AbdE3TSx (ORCPT ); Tue, 30 May 2017 15:18:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42234 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbdE3TSv (ORCPT ); Tue, 30 May 2017 15:18:51 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1A34C85540 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1A34C85540 Date: Tue, 30 May 2017 21:18:47 +0200 From: Oleg Nesterov To: Linus Torvalds Cc: Thomas Gleixner , LKML , Peter Zijlstra , Ingo Molnar , Michael Kerrisk , linux-man@vger.kernel.org, libc-alpha Subject: Re: signals: Bug or manpage inconsistency? Message-ID: <20170530191847.GA23231@redhat.com> References: <20170530170414.GA22463@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 30 May 2017 19:18:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/30, Linus Torvalds wrote: > > On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: > > > > I can't comment, I never tried to understand the rationality behind the current > > behaviour. But at least the sending path should never drop a blocked SIG_DFL > > signal, there is no other way to ensure you won't miss a signal during exec. > > Note that both SIG_DFL _and_ SIG_IGN are possible after exec, Yes, if it was already ignored before exec. But ignoring the compatibility the only important case is when it is SIG_DFL because of flush_signal_handlers(). > SIG_IGN doesn't mean "ignore signal forever". It means "ignore signals > right now", and I think that our current signal blocking semantics are > likely the correct ones, I am not saying it is incorrect, but I agree with Thomas in that this sigismember(t->blocked) in sig_ignored() doesn't look really nice. > exactly because it means "when you start > blocking signals, the kernel will not drop them". if the process is singe-threaded or the signal is private, or it is blocked by all threads. Otherwise it will wakeup another thread for no reason, the signal will be dropped in get_signal(). And again, this doesn't look consistent with do_sigaction(). It even has a comment which explains that we want to flush the ignored signals, blocked or not. Nevermind, I am not trying to argue, and > So again, I really wouldn't want to change existing semantics unless > there is a big real reason for it. Our current semantics are not > wrong. I certainly agree. Oleg.