Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp780628pxf; Thu, 25 Mar 2021 13:58:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmFFbjvatw+C6bPHTe4DAQ9KDaa8jTOPWrx0p01ntQ7rxl0mR2vMhFwkXD9RlxKB+jguv3 X-Received: by 2002:a17:906:5d06:: with SMTP id g6mr11626567ejt.216.1616705894572; Thu, 25 Mar 2021 13:58:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616705894; cv=none; d=google.com; s=arc-20160816; b=EiK/MSUpZqpnmrhSezj6RH3vLCWO2SI23jYZzPR9w92KyFJZ00LnTuIiuum19Z71Vs LpNYfmjOCiAQeHqb6HDH7QyeZGKLlAxeBYN1wQ2t4LSPzwgigoA3+Z4nL/XRoCLamaOg TMq4XtziQf7Mk5QTSKCsd3d5TdZQr31pE0LQy+3L6enIj/RJNXHMIreVwDtL9Ud2j3e8 2MAyfjef12mweN0rFkPvW3tN0+sP586qfolFBWxEyeKDgqopjJepQ661xfU39xGHO1r7 TARK7akmJFjjjXrB7Zancm6HQ8hLgALzNSxBHt1bCb9xW0ygV8HdbhjxMOnaoD058mip 1nJA== 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=kRkCmnqfo0o48nC6KsUMcWEl5ug1sPHo1SsJXp0uM2Y=; b=CPur46+Q5cGpwh20OtbnF1LsIykIII4TJkRHY1f0iGz85LaExHIyMtaG1hyhmPAfSD 6MiZ88jkn4ePYK88hG5he8ViDxplA+8NgQLIfpVgEietu+hiDziaMLLxH5UYJTm6u3UE WleUoBYGYiY6VONyKYEGywVb2fkVCANA8UVLugUmQ5A81oxvyMauqb+gue2dllq0flEw sKrsIy4hjeTdCINoqcEercjrcju/yjOwqbSi1bpk/ksqiL8pmMBloP+pyw0eGLvlAcIE oNIceKV4IHI96j16MTMfvZ1fpdh7O7nXcPDnB25yB82nuOLOnpvzR7pZyqtMpavik+mw RSQw== 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 t17si5137961ejx.576.2021.03.25.13.57.50; Thu, 25 Mar 2021 13:58:14 -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 S230189AbhCYU4r (ORCPT + 99 others); Thu, 25 Mar 2021 16:56:47 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:55486 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230042AbhCYU4Y (ORCPT ); Thu, 25 Mar 2021 16:56:24 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lPX1j-00GGQT-Ij; Thu, 25 Mar 2021 14:56:23 -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 1lPX1h-0003qr-PN; Thu, 25 Mar 2021 14:56:23 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Linus Torvalds , Jens Axboe , io-uring , Linux Kernel Mailing List , Stefan Metzmacher References: <20210325164343.807498-1-axboe@kernel.dk> <20210325204430.GE28349@redhat.com> Date: Thu, 25 Mar 2021 15:55:21 -0500 In-Reply-To: <20210325204430.GE28349@redhat.com> (Oleg Nesterov's message of "Thu, 25 Mar 2021 21:44:30 +0100") 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=1lPX1h-0003qr-PN;;;mid=;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/JsbrhQ4IeD1xkDz3HU8Jinx2474vuSMo= 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 sa07.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,T_TooManySym_03,T_TooManySym_04,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.4995] * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_04 7+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Oleg Nesterov X-Spam-Relay-Country: X-Spam-Timing: total 1393 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 10 (0.7%), b_tie_ro: 9 (0.6%), parse: 0.81 (0.1%), extract_message_metadata: 2.7 (0.2%), get_uri_detail_list: 0.93 (0.1%), tests_pri_-1000: 3.5 (0.2%), tests_pri_-950: 1.21 (0.1%), tests_pri_-900: 0.99 (0.1%), tests_pri_-90: 170 (12.2%), check_bayes: 168 (12.1%), b_tokenize: 5 (0.4%), b_tok_get_all: 6 (0.4%), b_comp_prob: 1.90 (0.1%), b_tok_touch_all: 151 (10.9%), b_finish: 1.02 (0.1%), tests_pri_0: 1173 (84.2%), check_dkim_signature: 0.47 (0.0%), check_dkim_adsp: 2.4 (0.2%), poll_dns_idle: 0.62 (0.0%), tests_pri_10: 2.9 (0.2%), tests_pri_500: 20 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc//task/ 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 Oleg Nesterov writes: > On 03/25, Linus Torvalds wrote: >> >> The whole "signals are very special for IO threads" thing has caused >> so many problems, that maybe the solution is simply to _not_ make them >> special? > > Or may be IO threads should not abuse CLONE_THREAD? > > Why does create_io_thread() abuse CLONE_THREAD ? > > One reason (I think) is that this implies SIGKILL when the process exits/execs, > anything else? A lot. The io workers perform work on behave of the ordinary userspace threads. Some of that work is opening files. For things like rlimits to work properly you need to share the signal_struct. But odds are if you find anything in signal_struct (not counting signals) there will be an io_uring code path that can exercise it as io_uring can traverse the filesystem, open files and read/write files. So io_uring can exercise all of proc. Using create_io_thread with CLONE_THREAD is the least problematic way (including all of the signal and ptrace problems we are looking at right now) to implement the io worker threads. They _really_ are threads of the process that just never execute any code in userspace. Eric