From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CEDBC0218F for ; Fri, 31 Jan 2025 20:57:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D37C6B007B; Fri, 31 Jan 2025 15:57:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 983976B0082; Fri, 31 Jan 2025 15:57:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 824A96B0083; Fri, 31 Jan 2025 15:57:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 60B0E6B007B for ; Fri, 31 Jan 2025 15:57:00 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CEC2EC1205 for ; Fri, 31 Jan 2025 20:56:59 +0000 (UTC) X-FDA: 83068956558.03.0C5F1E1 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf24.hostedemail.com (Postfix) with ESMTP id 7C411180004 for ; Fri, 31 Jan 2025 20:56:57 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf24.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738357017; a=rsa-sha256; cv=none; b=fi/3ycoiBnpnT7WeI3zz8oYv+P2r8LLlpYEdygpNwIxYUS6nEujfRV7g0ZvJp+Qx5tvkOz pzXKGd0Jp6wpnm+1YilobJQygNp9CxKIy2I/aXEwN7Mdg6If5cRxUG3/570NzNMjUd8lZs io93rqe5y2nmmq0Y/8uSAJRYkvvY5oo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf24.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738357017; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OYEv/OrGR5lySjq/yE7V/JJszaeO9wYvLJZEurqw/nY=; b=GKymSXiaxpqQnr+EarP7IBgEIbbDI3TaHssfDzk/ry+YFnWScNZlqWMyaUAqsiqzZjA3Hj f9ewJ2+nvFJ8bajgl/0Wy+KUhFw9YMsw+wI6wiZLDKEYDFRef/Gjr2dDYFcI/eD8SOGC7v L0QXLmxK5xWTgWognloF7Y1AudFCCJ8= Received: from in01.mta.xmission.com ([166.70.13.51]:59982) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1tdy4O-00ArVh-15; Fri, 31 Jan 2025 13:56:56 -0700 Received: from ip72-198-198-28.om.om.cox.net ([72.198.198.28]:50098 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1tdy4N-008RBu-2v; Fri, 31 Jan 2025 13:56:55 -0700 From: "Eric W. Biederman" To: Mateusz Guzik Cc: brauner@kernel.org, oleg@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20250128160743.3142544-1-mjguzik@gmail.com> Date: Fri, 31 Jan 2025 14:55:47 -0600 In-Reply-To: <20250128160743.3142544-1-mjguzik@gmail.com> (Mateusz Guzik's message of "Tue, 28 Jan 2025 17:07:43 +0100") Message-ID: <87ikpubt4c.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1tdy4N-008RBu-2v;;;mid=<87ikpubt4c.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=72.198.198.28;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX18aFeIbJvVu5HGQ5jxISWzXSREXGfFDYmE= Subject: Re: [PATCH v2] exit: perform randomness and pid work without tasklist_lock X-SA-Exim-Connect-IP: 166.70.13.51 X-SA-Exim-Rcpt-To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, oleg@redhat.com, brauner@kernel.org, mjguzik@gmail.com X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Scanned: No (on out01.mta.xmission.com); SAEximRunCond expanded to false X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7C411180004 X-Stat-Signature: kjyssnongbahmja94j85bn53w7p6tc9z X-HE-Tag: 1738357017-960269 X-HE-Meta: U2FsdGVkX1+dGV17TV+V7HDAgT36srQ4tzO5YTDP/wGWuAaf9gLbGddiBQTKz0lLVyqUZiVx81OyBFLHZMrYXw00mkGKlsp9R69oD3HaSPzpMa071cFJyQp5isUbnPLlJQjHDTbOUUP9Yl7OJdZ3tFez7HTgVgh2zVyFA+NO8n1fBHtBqRUOjsd/Us+n5mb81zxLPpwhCVpE/tUoWuBc+wvc3g7qq8n1BSvr/3H1e0THwhclRROw8CfGi6V41opWKXn5eehLNOyQ5Z+pQ2POwS5nfknoI4wCGn0bQFlUNY+B6pkbEgJpbSTkhM8AM8vQluIsVlkeG8RVH42ezv71ouJ53F2oc6mAjWa65zYix0keZ9TwSqv+bb8aEIdLj/xW8l0PuS+q+Gv2All1CLRf/qGnDxAFbYiWFW1htUPHYbQ3ul9ThWec9NCU8lvU88tJP7a37yByAcnlNBQdX/51yMb/bt4/vcQV7mtANizEQWtD1hLe5+VdDBcaJ7vfsToCvVV6e/SGX4GOKtgjklEt7pO6YoZooWNEgn9rlvuYR77EZpBEcIMTz4TuyZMzkGDWdbitEiL+T1xQCoZW+rmXCEb/j4vdTi4NKh2+9wYU3QKhqakM9BM8hlR+6bMAPb5PDovY2HD2KhnIiGA3VPp/7mWTZDgrH6h4Yv11J2Vsq4UD636kSYM8P9yX7derw6HELajmzBs8xmRkWYBT4i1vgkHqxFFABtLUnGnRVu3+kq7wK6Dqehyncy67u8m0HyHioCkiZSCBz/ylHSzWl0rH92/3MxZXgLP5tZHQl1bNcyKq1XS68IMbA9WQHfLZeNdOv+PEAnwnW+OPtuC3Xr0rsAhydmGI8wfVvuQCN8Zec0TDnOTooaPDmL1yElfCKyJ5PlDIqMbyjjYVdyt5CypcoJ8n06vtgcilgCpet7XEFHSH4NPQPPOT30hYh1cFOzAUBOLhODQLlrSJDki0ZHm CxJ71LN0 XVaDW3/YWmdPdHC7UFYx9AXw5Iz98QgetFy+/ezKdjfofLnNQBuvFuEhy6iJiGSDmaDkm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Oleg asked that I take a look, and I took one. I very much agree with Oleg that this should be one patch per thing you want to effect as the issues can be intricate in this part of the code. Moving proc_flush_pid inside of tasklist_lock is a bad idea. The code has previously been several kinds of a sore spot. If you look at proc_invalidate_siblings_dcache you can see calls to d_invalidate, deactivate_super, and a few other vfs calls that could potentially do quite a lot of work and potentially take a number of locks. It has been a long time but I remember when we used to flush the proc entries under the tasklist_lock that there were actual deadlocks caused by some rare code paths that were trying to free memory to allocate memory to make progress. It is wrong that attach_pid/detach_pid can be performed without the tasklist_lock. There are reasonable guarantees provided by the posix standard that the set of processes sent a signal is the set of processes at a point in time. The tasklist_lock is how we provide those guarantees currently. There are two more layers to pids. The pid number allocation of alloc_pid/free_pid, and the struct pid layer maintained by get_pid, put_pid. Those two layers don't need the tasklist_lock. It is safe to move free_pid out of tasklist_lock. I am not certain how sane it is. Eric