From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751059AbdEaAzC (ORCPT ); Tue, 30 May 2017 20:55:02 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:54394 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750824AbdEaAzA (ORCPT ); Tue, 30 May 2017 20:55:00 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Thomas Gleixner Cc: Linus Torvalds , Oleg Nesterov , LKML , Peter Zijlstra , Ingo Molnar , Michael Kerrisk , linux-man@vger.kernel.org, libc-alpha References: <20170530170414.GA22463@redhat.com> Date: Tue, 30 May 2017 19:48:10 -0500 In-Reply-To: (Thomas Gleixner's message of "Tue, 30 May 2017 22:54:38 +0200 (CEST)") Message-ID: <87wp8xn96d.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=1dFruV-0005Pc-BX;;;mid=<87wp8xn96d.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.121.81.159;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/GMda/CrabTXHM4bMswVXbKNCAQbq7awg= X-SA-Exim-Connect-IP: 97.121.81.159 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Thomas Gleixner X-Spam-Relay-Country: X-Spam-Timing: total 5303 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.9 (0.1%), b_tie_ro: 2.1 (0.0%), parse: 1.09 (0.0%), extract_message_metadata: 14 (0.3%), get_uri_detail_list: 2.9 (0.1%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.17 (0.0%), tests_pri_-900: 0.96 (0.0%), tests_pri_-400: 24 (0.5%), check_bayes: 23 (0.4%), b_tokenize: 8 (0.2%), b_tok_get_all: 8 (0.1%), b_comp_prob: 2.5 (0.0%), b_tok_touch_all: 2.7 (0.1%), b_finish: 0.64 (0.0%), tests_pri_0: 1214 (22.9%), check_dkim_signature: 0.54 (0.0%), check_dkim_adsp: 3.5 (0.1%), tests_pri_500: 4037 (76.1%), poll_dns_idle: 4031 (76.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: signals: Bug or manpage inconsistency? X-Spam-Flag: No 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > On Tue, 30 May 2017, Linus Torvalds wrote: >> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >> > Obviously this is a user-visible change and it can break something. Say, an >> > application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), this >> > will no longer work. >> >> That's an interesting special case. Yes, SIG_IGN actually has magical >> properties wrt SIGCHLD. It basically means the opposite of ignoring >> it, it's an "implicit signal handler". So I could imagine people >> using SIG_IGN to avoid the signal handler, but then block SIG_CHLD and >> using sigwait() for it. >> >> That sounds nonportable as hell, but I could imagine people doing it >> because it happens to work. > > Just that it does not work. See do_notify_parent() > > if (!tsk->ptrace && sig == SIGCHLD && > (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN || > (psig->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT))) { > /* > * We are exiting and our parent doesn't care. POSIX.1 > * defines special semantics for setting SIGCHLD to SIG_IGN > * or setting the SA_NOCLDWAIT flag: we should be reaped > * automatically and not left for our parent's wait4 call. > * Rather than having the parent do it as a magic kind of > * signal handler, we just set this to tell do_exit that we > * can be cleaned up without becoming a zombie. Note that > * we still call __wake_up_parent in this case, because a > * blocked sys_wait4 might now return -ECHILD. > * > * Whether we send SIGCHLD or not for SA_NOCLDWAIT > * is implementation-defined: we do (if you don't want > * it, just use SIG_IGN instead). > */ > autoreap = true; > if (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN) > sig = 0; > } > if (valid_signal(sig) && sig) > __group_send_sig_info(sig, &info, tsk->parent); > > So if the oarent has SIG_IGN we do not send a signal at all. So it's not a > really interesting special case and the magic properties are not that magic > either. Test case below. The parent waits forever. Which would suggests that to be consistent we should ignore blocks for other signals on send when the signal handler is SIG_IGN. Hmm. For blocked signals because there is only one siginfo ever allocated as I read it the code naturally blocks the signal until it is dequeued and rearmed. I suspect what you want to do is a little more in the magic dequeue_signal for timers and look if the signal handler is SIG_IGN. I think the clean solution would be to treat timers whose signal handler is SIG_IGN as blocked signals and simply not dequeue them. If they are not dequeued they won't reschedule and won't restart. Then when the signal handler finally changes you immediately get one pending signal and then the timers fire normally. That gets tricky though because the signal numbers are not dedicated to posix timers. It might instead require noting that the handler is SIG_IGN when dequeued and simply disabled the timer. With an enable that kicks in when someone calls sigaction and changes the handler. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: signals: Bug or manpage inconsistency? Date: Tue, 30 May 2017 19:48:10 -0500 Message-ID: <87wp8xn96d.fsf@xmission.com> References: <20170530170414.GA22463@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Thomas Gleixner's message of "Tue, 30 May 2017 22:54:38 +0200 (CEST)") Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Thomas Gleixner Cc: Linus Torvalds , Oleg Nesterov , LKML , Peter Zijlstra , Ingo Molnar , Michael Kerrisk , linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, libc-alpha List-Id: linux-man@vger.kernel.org Thomas Gleixner writes: > On Tue, 30 May 2017, Linus Torvalds wrote: >> On Tue, May 30, 2017 at 10:04 AM, Oleg Nesterov wrote: >> > Obviously this is a user-visible change and it can break something. Say, an >> > application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), this >> > will no longer work. >> >> That's an interesting special case. Yes, SIG_IGN actually has magical >> properties wrt SIGCHLD. It basically means the opposite of ignoring >> it, it's an "implicit signal handler". So I could imagine people >> using SIG_IGN to avoid the signal handler, but then block SIG_CHLD and >> using sigwait() for it. >> >> That sounds nonportable as hell, but I could imagine people doing it >> because it happens to work. > > Just that it does not work. See do_notify_parent() > > if (!tsk->ptrace && sig == SIGCHLD && > (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN || > (psig->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT))) { > /* > * We are exiting and our parent doesn't care. POSIX.1 > * defines special semantics for setting SIGCHLD to SIG_IGN > * or setting the SA_NOCLDWAIT flag: we should be reaped > * automatically and not left for our parent's wait4 call. > * Rather than having the parent do it as a magic kind of > * signal handler, we just set this to tell do_exit that we > * can be cleaned up without becoming a zombie. Note that > * we still call __wake_up_parent in this case, because a > * blocked sys_wait4 might now return -ECHILD. > * > * Whether we send SIGCHLD or not for SA_NOCLDWAIT > * is implementation-defined: we do (if you don't want > * it, just use SIG_IGN instead). > */ > autoreap = true; > if (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN) > sig = 0; > } > if (valid_signal(sig) && sig) > __group_send_sig_info(sig, &info, tsk->parent); > > So if the oarent has SIG_IGN we do not send a signal at all. So it's not a > really interesting special case and the magic properties are not that magic > either. Test case below. The parent waits forever. Which would suggests that to be consistent we should ignore blocks for other signals on send when the signal handler is SIG_IGN. Hmm. For blocked signals because there is only one siginfo ever allocated as I read it the code naturally blocks the signal until it is dequeued and rearmed. I suspect what you want to do is a little more in the magic dequeue_signal for timers and look if the signal handler is SIG_IGN. I think the clean solution would be to treat timers whose signal handler is SIG_IGN as blocked signals and simply not dequeue them. If they are not dequeued they won't reschedule and won't restart. Then when the signal handler finally changes you immediately get one pending signal and then the timers fire normally. That gets tricky though because the signal numbers are not dedicated to posix timers. It might instead require noting that the handler is SIG_IGN when dequeued and simply disabled the timer. With an enable that kicks in when someone calls sigaction and changes the handler. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html