Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1697167imm; Wed, 8 Aug 2018 23:59:17 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzgiP9iyJYuW2YcHkLoGe/nNgu0evohKwbBLWVs3axf9bDXfJ8gLqCqKU06EzFZUmJgPjEj X-Received: by 2002:a63:8f03:: with SMTP id n3-v6mr948096pgd.166.1533797957261; Wed, 08 Aug 2018 23:59:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533797957; cv=none; d=google.com; s=arc-20160816; b=jaEzxMUC+6XQGbce2YwBQ+PbGcLXI8DbFmFpRoZtfIGZsVaJ1H/gC7ijfGijezUoPI s9tzepDVSwHCkLuotUS+vymLMSEV6z3nqsAO4o/S+X4+qQO1gEIyHy2VSzTltnkQNOSM Y7cbRx4uKfGlOnPr+osgyg3+LQM7O9TCg58AQPEIN6ixxxmGwjqynQDk6wl6Y/SPy8zw U8WxTshuVyKBRZiEHxG1QJksP0hzzBkBXSN4kzxOOXVNBbPg0Hg2rZeKX9SqjrAPKvFL U1+0wlmBAWzSVb26Z5HPuH/gBwyL7uRjnSzoHJAZLpJXu7Ew+VnkaX50y2+HG0jykCqr +LeA== 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=hWffZQm8a8pI2AgnXFSpd/14in4eNulAvlh5fG/XPiI=; b=GOrAUdYVT3QTTySmGqiLGdsl3d6PaWnlQcX567gr/nyNRnWqM6DWd47LoNoAcgU1Ui 9S9Iv2yD503Q0JscPh6a79+iybzrrSfqi0Nj8934rQ8BPAM0lDij4n3ZdIzJAf5iZGLp bPNa3EFWYQc4Cv2uWM4oywGyCiM4kS0PXC9boGRJrW80kiDluDNvq8lXXOaGsGiPTV1h w7uTZNXcWw+QIS6Gao7AKlBQi+J8MHcuIIxOLbPr1WumhLvIuTzwsD9RYpsSpgYRKenL 3t05btR5WjTnL6MTCzR9tP3x8w/aEtgnwWLVf4fKKlYe9t5oLuD/XIT5Dc9zILabh2VR QVow== 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 w14-v6si5079889pgv.462.2018.08.08.23.59.02; Wed, 08 Aug 2018 23:59:17 -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 S1728469AbeHIJU4 (ORCPT + 99 others); Thu, 9 Aug 2018 05:20:56 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:43860 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725878AbeHIJU4 (ORCPT ); Thu, 9 Aug 2018 05:20:56 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fnet0-0008J8-Nh; Thu, 09 Aug 2018 00:57:30 -0600 Received: from [97.119.167.31] (helo=x220.int.ebiederm.org) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.87) (envelope-from ) id 1fnesz-00054s-JD; Thu, 09 Aug 2018 00:57:30 -0600 From: "Eric W. Biederman" To: Oleg Nesterov Cc: Andrew Morton , linux-kernel@vger.kernel.org, Wen Yang , majiang , Linus Torvalds , "Eric W. Biederman" Date: Thu, 9 Aug 2018 01:56:02 -0500 Message-Id: <20180809065605.32345-3-ebiederm@xmission.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <87wot0yqsx.fsf_-_@xmission.com> References: <87wot0yqsx.fsf_-_@xmission.com> X-XM-SPF: eid=1fnesz-00054s-JD;;;mid=<20180809065605.32345-3-ebiederm@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.119.167.31;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18DT9EfHdDJ2Z+e1Imk9CjqzeTQ82b1eDQ= X-SA-Exim-Connect-IP: 97.119.167.31 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa01.xmission.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,T_TooManySym_02, T_TooManySym_03 autolearn=disabled version=3.4.0 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 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.4994] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Oleg Nesterov X-Spam-Relay-Country: X-Spam-Timing: total 785 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.2 (0.4%), b_tie_ro: 2.1 (0.3%), parse: 1.37 (0.2%), extract_message_metadata: 28 (3.6%), get_uri_detail_list: 5.0 (0.6%), tests_pri_-1000: 10 (1.3%), tests_pri_-950: 2.0 (0.3%), tests_pri_-900: 1.61 (0.2%), tests_pri_-400: 39 (5.0%), check_bayes: 37 (4.7%), b_tokenize: 16 (2.1%), b_tok_get_all: 9 (1.1%), b_comp_prob: 5 (0.7%), b_tok_touch_all: 3.0 (0.4%), b_finish: 0.79 (0.1%), tests_pri_0: 687 (87.5%), check_dkim_signature: 1.56 (0.2%), check_dkim_adsp: 4.4 (0.6%), tests_pri_500: 8 (1.0%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH v5 3/6] 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 in02.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 anything 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 reuse the recalc_sigpending logic and get the kernel live patching folks to sort out their story later. V2: I have moved the test into schedule_tail where siglock can be grabbed and recalc_sigpending can be reused directly. Further as the last action of setting up a new task this guarantees that TIF_SIGPENDING will be properly set in the new process. The helper calculate_sigpending takes the siglock and uncontitionally sets TIF_SIGPENDING and let's recalc_sigpending clear TIF_SIGPENDING if it is unnecessary. This allows reusing the existing code and keeps maintenance of the conditions simple. Oleg Nesterov suggested the movement and pointed out the need to take siglock if this code was going to be called while the new task is discoverable. Signed-off-by: "Eric W. Biederman" --- include/linux/sched/signal.h | 1 + kernel/sched/core.c | 2 ++ kernel/signal.c | 11 +++++++++++ 3 files changed, 14 insertions(+) diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h index 94558ffa82ab..b55fd293c1e5 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(void); extern void signal_wake_up_state(struct task_struct *t, unsigned int state); diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 78d8facba456..3e4ed4b7aa2d 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2813,6 +2813,8 @@ asmlinkage __visible void schedule_tail(struct task_struct *prev) if (current->set_child_tid) put_user(task_pid_vnr(current), current->set_child_tid); + + calculate_sigpending(); } /* diff --git a/kernel/signal.c b/kernel/signal.c index dddbea558455..1e06f1eba363 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -172,6 +172,17 @@ void recalc_sigpending(void) } +void calculate_sigpending(void) +{ + /* Have any signals or users of TIF_SIGPENDING been delayed + * until after fork? + */ + spin_lock_irq(¤t->sighand->siglock); + set_tsk_thread_flag(current, TIF_SIGPENDING); + recalc_sigpending(); + spin_unlock_irq(¤t->sighand->siglock); +} + /* Given the mask, find the first available signal that should be serviced. */ #define SYNCHRONOUS_MASK \ -- 2.17.1