Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp80764imm; Tue, 24 Jul 2018 14:25:52 -0700 (PDT) X-Google-Smtp-Source: AAOMgpegk1TrQrmJGLIFvTd3fCBJdZQZ5EC/twrjTbMlAnNbhs/WTFQhr6sOhaaDWaj00aZNUdaF X-Received: by 2002:a63:c80e:: with SMTP id z14-v6mr17448770pgg.77.1532467552086; Tue, 24 Jul 2018 14:25:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532467552; cv=none; d=google.com; s=arc-20160816; b=bR0PXx7DEEbVjDqAah0VLwfqkZ6SBeNvqOh7HKmn0qDjp/KSKQSdNkUjt1Z3l8OLNq mEsJVs55u6I0SG/0hMV1uAZ7CQwKENDg/jUYt7U8KArwRi4KS/zlkpOLLjUuM9bPOYHR /De5xS5p2DPJG9mdSR7IAgT97/rV3ZuXQ694Ji2U7PDKlKjyMB3r3pPr2iu5Fk1epUD3 bq2pMxF5o/CjvhNPWpIsLpSmfwDul4ZrCw/HnbqtLrdO1de3QuksVvXB8GiJGQgKF3qR Htjt5zic5U+qZhfhnWDHhVtbj6aUiFVRtIXyfdSU5gzZOfXTKqKRzm76yWa5EhjDpdEI c5jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from :arc-authentication-results; bh=Ara3gCLX/ErK09EKpneY8DImUwgApfJgQxBxC61yDiI=; b=JaT7xcdp3/vq7/GFNMc01r2DcsOgQTBTtcYatF6E282CLvg9CAncSzu4drPNFPNM2l 4N03zLPgQFotjFOjNN+1ICQDWFQt9Q3G40DLq7zBZzHXuL/PCyN9lPshMyYWWZMeSgrG owYCJJsK/NVDqTAuItkDah1/wynLTYO0mXVN8bXfYmXmJaAb3a21b2m6DUph7dXePDk1 UGIguzINfYwdcaj33yh7125ypds74LcG5J0m491ATGkd1H8DkMnJeb4OoILPOjt8ptoQ bywxYz2WaUKOaNqSIqN7IdSQDD/Yaack0scCnvvmCiRUzm7DcyYo3uqfrjrIataE4QHT aX/w== 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 l7-v6si12752700pgm.677.2018.07.24.14.25.36; Tue, 24 Jul 2018 14:25:52 -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 S2388597AbeGXWdG (ORCPT + 99 others); Tue, 24 Jul 2018 18:33:06 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:59052 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388476AbeGXWdG (ORCPT ); Tue, 24 Jul 2018 18:33:06 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fi4nS-0004Pk-MK; Tue, 24 Jul 2018 15:24:42 -0600 Received: from [97.119.167.31] (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 1fi4nR-0008HI-Oe; Tue, 24 Jul 2018 15:24:42 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Oleg Nesterov , Andrew Morton , Linux Kernel Mailing List , Wen Yang , majiang References: <87efft5ncd.fsf_-_@xmission.com> <20180724032419.20231-20-ebiederm@xmission.com> <874lgo5xdg.fsf@xmission.com> <87fu084cxj.fsf@xmission.com> <87a7qg4bb3.fsf_-_@xmission.com> Date: Tue, 24 Jul 2018 16:24:28 -0500 In-Reply-To: (Linus Torvalds's message of "Tue, 24 Jul 2018 13:56:05 -0700") Message-ID: <87pnzc2upf.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=1fi4nR-0008HI-Oe;;;mid=<87pnzc2upf.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.167.31;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/wSOSEwl4W8QzPAKuZoJl+dE0jUhfEIz8= 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.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,T_TooManySym_02, XMSubLong autolearn=disabled version=3.4.0 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 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.4992] * -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 X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 467 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.1 (0.7%), b_tie_ro: 2.1 (0.5%), parse: 1.32 (0.3%), extract_message_metadata: 30 (6.3%), get_uri_detail_list: 2.4 (0.5%), tests_pri_-1000: 14 (3.0%), tests_pri_-950: 1.99 (0.4%), tests_pri_-900: 1.61 (0.3%), tests_pri_-400: 28 (6.0%), check_bayes: 26 (5.6%), b_tokenize: 10 (2.2%), b_tok_get_all: 7 (1.4%), b_comp_prob: 3.8 (0.8%), b_tok_touch_all: 2.2 (0.5%), b_finish: 0.75 (0.2%), tests_pri_0: 375 (80.3%), check_dkim_signature: 0.88 (0.2%), check_dkim_adsp: 5 (1.1%), tests_pri_500: 7 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 20/20] signal: Don't restart fork when signals come in. 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 Linus Torvalds writes: > On Tue, Jul 24, 2018 at 1:40 PM Eric W. Biederman wrote: >> >> + if (signal_pending(current)) { >> + retval = restart_syscall(); >> + goto fork_out; >> + } > > Oh, the previous version had this too, but it wasn't as obvious > because it was just in a single line: > > return ERR_PTR(restart_syscall()); > > but it's just crazy. > > It should just be > > retval = -ERESTARTNOINTR; > if (signal_pending(current)) > goto fork_out; > > because it's just silly and pointless to change the code to use > restart_syscall() here. > > All restart_syscall() does is > > set_tsk_thread_flag(current, TIF_SIGPENDING); > return -ERESTARTNOINTR; > > and you just *checked* that TIF_SIGPENDING was already set. So the > above is completely pointless. > > It is not clear why you made that change. The old code had the simpler > "just return -ERESTARTNOINTR" model. > > Did the restart_syscall() thing come in by mistake from some previous > trials and it just hung around? I think this is the one place in the kernel where we can restart a system call and not set TIF_SIGPENDING. Several years ago I made the mistake in the networking code of returning -ERESTARTNOINTR and forgetting to set TIF_SIGPENDING. That wasn't fun. So I wrote restart_syscall and use it so I don't make that mistake again. In this case your suggesting will definitely generate better code so I am happy to make a V3 with that doesn't use restart_syscall. A person working in the guts of fork can reasonably be expected understand and to have all of the subtleties in cache as they work on that part of fork. Eric