Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp6506219imm; Mon, 23 Jul 2018 20:28:49 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeQNHN8aqu1Db/dNGE7hi4X/6iw1dMOhFHw4nMLfvzzU2ilTdxZIhPBCMtXwPjY5bLWm+uf X-Received: by 2002:a17:902:b609:: with SMTP id b9-v6mr4594148pls.321.1532402929113; Mon, 23 Jul 2018 20:28:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532402929; cv=none; d=google.com; s=arc-20160816; b=nhMQjt1M2lrOJ8o/SarGzPRelhwcMQqWuMw/Ij1iOESZFkygp1xW5QV0x02+KGqrqH lNiQmW48zz0a93qjMg9I3AX8rbQwFnAxuLTzLuY0TOAGH4E6MEeCMgt4S3yL5W42hY5F vgE9yJYgCFU+swweyqZ0COPhoX/tcIBtvT6gYU6WyqrP7sjuQWWj5CpyFgmcLTU1h5Gw 6J/HxlgshJ9jPKoJQoj1ZbHd6/YF5q3Xd11E1JfhSpYAApPKqyuIaLMxmh4+MzPg+T1+ QNu5gEKQXNm/pj5CJFvaNeowHPcgJ3roykm++g2u+sNvtg9H3AyJUs+KPWFCCsfmFCqG tJgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:references:in-reply-to:message-id :date:cc:to:from:arc-authentication-results; bh=u/5CxXb7Wupigl7D49X1Tz8KeHy2hCPjX+LuQxdP2j0=; b=oA0F+FIiRefaSKgsgYIlGkiilyg+F7DkFSM6s2j/Ge25be1wJx+CbS/1L0eCulOL0V 3JaAfcjeeqy9yDiScVqCChp0117wzl5e98jLU/X4IJDE4evbYW47zf/GLhs9FnfTCGV/ rWq2LLxvDNs3IZI3tPUtLqPLAPCOj7JNk1KNUBEmDxikDrfjQI+aFGpz/UyIHytFcIeA njGxJGWrpwQXccWjDKJcgAd11PxbFBofgreq1x1SgJI0xiCx0G1EaPGdQlqWDIz02nN9 purqOagLAyA1Bt/bnb5zKF8Amy8HoSixaYctjCtFZM7nlykaBd/U1q2GCXgXiXCrjraR yQlw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j5-v6si9935137plk.406.2018.07.23.20.28.34; Mon, 23 Jul 2018 20:28:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388513AbeGXEbz (ORCPT + 99 others); Tue, 24 Jul 2018 00:31:55 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:51377 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388199AbeGXEby (ORCPT ); Tue, 24 Jul 2018 00:31:54 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fhnz4-0007ik-5Z; Mon, 23 Jul 2018 21:27:34 -0600 Received: from [97.119.167.31] (helo=x220.int.ebiederm.org) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fhnxg-0008AK-3W; Mon, 23 Jul 2018 21:26:23 -0600 From: "Eric W. Biederman" To: Linus Torvalds Cc: Oleg Nesterov , Andrew Morton , linux-kernel@vger.kernel.org, Wen Yang , majiang , "Eric W. Biederman" Date: Mon, 23 Jul 2018 22:24:17 -0500 Message-Id: <20180724032419.20231-18-ebiederm@xmission.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <87efft5ncd.fsf_-_@xmission.com> References: <87efft5ncd.fsf_-_@xmission.com> X-XM-SPF: eid=1fhnxg-0008AK-3W;;;mid=<20180724032419.20231-18-ebiederm@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.167.31;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18qBtVUp59V8gX/MoEQMzOHRYYDx6f6e9g= X-SA-Exim-Connect-IP: 97.119.167.31 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa07.xmission.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TooManySym_01,T_TooManySym_02,T_TooManySym_03,XMNoVowels autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4999] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 15026 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.2 (0.0%), b_tie_ro: 2.2 (0.0%), parse: 1.04 (0.0%), extract_message_metadata: 12 (0.1%), get_uri_detail_list: 2.9 (0.0%), tests_pri_-1000: 2.9 (0.0%), tests_pri_-950: 1.20 (0.0%), tests_pri_-900: 1.00 (0.0%), tests_pri_-400: 25 (0.2%), check_bayes: 24 (0.2%), b_tokenize: 11 (0.1%), b_tok_get_all: 7 (0.0%), b_comp_prob: 2.2 (0.0%), b_tok_touch_all: 2.1 (0.0%), b_finish: 0.64 (0.0%), tests_pri_0: 212 (1.4%), check_dkim_signature: 0.50 (0.0%), check_dkim_adsp: 3.5 (0.0%), tests_pri_500: 14764 (98.3%), poll_dns_idle: 14754 (98.2%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 18/20] signal: Add calculate_sigpending() 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add a function calculate_sigpending to test to see if any signals are pending for a new task immediately following fork. Signals have to happen either before or after fork. Today our practice is to push all of the signals to before the fork, but that has the downside that frequent or periodic signals can make fork take much much longer than normal or prevent fork from completing entirely. So we need move signals that we can after the fork to prevent that. This updates the code to set TIF_SIGPENDING on a new task if there are signals or other activities that have moved so that they appear to happen after the fork. As the code today restarts if it sees any such activity this won't immediately have an effect, as there will be no reason for it to set TIF_SIGPENDING immediately after the fork. Adding calculate_sigpending means the code in fork can safely be changed to not always restart if a signal is pending. The new calculate_sigpending function sets sigpending if there are pending bits in jobctl, pending signals, the freezer needs to freeze the new task or the live kernel patching framework need the new thread to take the slow path to userspace. I have verified that setting TIF_SIGPENDING does make a new process take the slow path to userspace before it executes it's first userspace instruction. I have looked at the callers of signal_wake_up and the code paths setting TIF_SIGPENDING and I don't see else that needs to be handled. The code probably doesn't need to set TIF_SIGPENDING for the kernel live patching as it uses a separate thread flag as well. But at this point it seems safer to copy recalc_sigpending and get the kernel live patching folks to sort out their story later. Signed-off-by: "Eric W. Biederman" --- include/linux/sched/signal.h | 1 + kernel/fork.c | 1 + kernel/signal.c | 13 +++++++++++++ 3 files changed, 15 insertions(+) diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h index 94558ffa82ab..7cabc0bc38f6 100644 --- a/include/linux/sched/signal.h +++ b/include/linux/sched/signal.h @@ -372,6 +372,7 @@ static inline int signal_pending_state(long state, struct task_struct *p) */ extern void recalc_sigpending_and_wake(struct task_struct *t); extern void recalc_sigpending(void); +extern void calculate_sigpending(struct task_struct *new); extern void signal_wake_up_state(struct task_struct *t, unsigned int state); diff --git a/kernel/fork.c b/kernel/fork.c index 22d4cdb9a7ca..e07281254552 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1988,6 +1988,7 @@ static __latent_entropy struct task_struct *copy_process( &p->signal->thread_head); } attach_pid(p, PIDTYPE_PID); + calculate_sigpending(p); nr_threads++; } diff --git a/kernel/signal.c b/kernel/signal.c index dddbea558455..f6687c7d7a8c 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -172,6 +172,19 @@ void recalc_sigpending(void) } +void calculate_sigpending(struct task_struct *new) +{ + /* Have any signals or users of TIF_SIGPENDING been delayed + * until after fork? + */ + bool pending = (new->jobctl & JOBCTL_PENDING_MASK) || + PENDING(&new->pending, &new->blocked) || + PENDING(&new->signal->shared_pending, &new->blocked) || + freezing(new) || klp_patch_pending(new); + + update_tsk_thread_flag(new, TIF_SIGPENDING, pending); +} + /* Given the mask, find the first available signal that should be serviced. */ #define SYNCHRONOUS_MASK \ -- 2.17.1