Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2261476pxf; Sat, 20 Mar 2021 09:26:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw52KtmorKk0wofXsXSlnSiuUKHKEr8mLg3RVhxKoQIartLqoAgMPjQqK9qmWCad9zy33dq X-Received: by 2002:aa7:c94b:: with SMTP id h11mr16074627edt.160.1616257612922; Sat, 20 Mar 2021 09:26:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616257612; cv=none; d=google.com; s=arc-20160816; b=E8aBjxIJCO8M12LsvJSxVy4kHrB0a0THM2Qzo7L5rESpYSRuaTopOjuWlZscBDviMj 123eXnqM4lVjn1GZgXJAP1sp5sTWhx+lpHytvU7nGHfoQDoOFl5RGbOkfSTLpOumMxsW 2usfJTSIF87vLdhVdtO26xyJ26vMkNSMbzvFbeQKPR/puewMejJsz6OA8OlsmN51ICpQ r1IKSFrewaDgSZWxgWFHRxlT/YDIOmmSZrN1LXUrlIzKsxjZwSZytbZFpTbQsXKImiWq I94YVz74drHLA6tl0EAKX0xJhkynotf1P2j3CJdYw+ijPT+TM8Z+/ZEW9WaXdGiDo300 WJ9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=dbprFV/T0HzoaCADoDp9Ly12U6y+HpPFwXMx8fDPc98=; b=n0e3YsB9FTrXYNMy3FdFV9YgrQqisleVkpBbBmXPO1xKhMMXk7IlqfeNKyQMlUvrtK 5sBF/G8eApNLG77+v9u1b2bdWnbLcsEOzT3Lnhh8Z63WAqm6J4eaV3MQcsfsgdkjAGtd 5aCfYjCkPhuN26fPtTIGaQjrTBi+NOuzrUL6+yX3W77DINvle9skIUyg1MmZMY99LcMN Xyz+4VoHF84Zf0/eHdNQm/FCV1nTunp9rMn3V0/+RG1xNsarqZfueGcK2d17J49QUi2X r3ROp7YfLXVDMXiuX32O8FRrBl6oDeKDL69mvctZCJQ9kor5FljSaGzjnRFHQE6s6OzZ J6hg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i21si6872126ejv.334.2021.03.20.09.26.30; Sat, 20 Mar 2021 09:26:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229791AbhCTQXb (ORCPT + 99 others); Sat, 20 Mar 2021 12:23:31 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:52648 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229761AbhCTQW6 (ORCPT ); Sat, 20 Mar 2021 12:22:58 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lNeNL-00GCXC-Ei; Sat, 20 Mar 2021 10:22:55 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1lNeNJ-0002he-EZ; Sat, 20 Mar 2021 10:22:55 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Jens Axboe Cc: io-uring@vger.kernel.org, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, oleg@redhat.com, Stefan Metzmacher References: <20210320153832.1033687-1-axboe@kernel.dk> <20210320153832.1033687-3-axboe@kernel.dk> Date: Sat, 20 Mar 2021 11:21:50 -0500 In-Reply-To: <20210320153832.1033687-3-axboe@kernel.dk> (Jens Axboe's message of "Sat, 20 Mar 2021 09:38:32 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lNeNJ-0002he-EZ;;;mid=;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/+h0JpbIOkzwR65kAwE6l72a6ANjW34k0= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa08.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01, T_TooManySym_02,XMNoVowels,XMSubLong autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4970] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa08 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; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Jens Axboe X-Spam-Relay-Country: X-Spam-Timing: total 1411 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 16 (1.1%), b_tie_ro: 14 (1.0%), parse: 0.98 (0.1%), extract_message_metadata: 16 (1.1%), get_uri_detail_list: 1.35 (0.1%), tests_pri_-1000: 22 (1.5%), tests_pri_-950: 1.32 (0.1%), tests_pri_-900: 1.18 (0.1%), tests_pri_-90: 1181 (83.7%), check_bayes: 1179 (83.5%), b_tokenize: 4.5 (0.3%), b_tok_get_all: 7 (0.5%), b_comp_prob: 2.0 (0.1%), b_tok_touch_all: 1159 (82.1%), b_finish: 1.68 (0.1%), tests_pri_0: 159 (11.3%), check_dkim_signature: 0.46 (0.0%), check_dkim_adsp: 2.9 (0.2%), poll_dns_idle: 1.29 (0.1%), tests_pri_10: 3.4 (0.2%), tests_pri_500: 7 (0.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 2/2] signal: don't allow STOP on PF_IO_WORKER threads 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jens Axboe writes: > Just like we don't allow normal signals to IO threads, don't deliver a > STOP to a task that has PF_IO_WORKER set. The IO threads don't take > signals in general, and have no means of flushing out a stop either. At first glance this seems safe. This is before we count all of the threads, and it needs to be a non io_uring thread. Further we can change this decision later if necessary, as this is not really exposed to userspace. But please tell me why is it not the right thing to have the io_uring helper threads stop? Why is it ok for that process to go on consuming cpu resources in a non-stoppable way. Eric > Reported-by: Stefan Metzmacher > Signed-off-by: Jens Axboe > --- > kernel/signal.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/kernel/signal.c b/kernel/signal.c > index 730ecd3d6faf..b113bf647fb4 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2349,6 +2349,10 @@ static bool do_signal_stop(int signr) > > t = current; > while_each_thread(current, t) { > + /* don't STOP PF_IO_WORKER threads */ > + if (t->flags & PF_IO_WORKER) > + continue; > + > /* > * Setting state to TASK_STOPPED for a group > * stop is always done with the siglock held,