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 5AFA7E65D1D for ; Fri, 22 Nov 2024 03:54:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1BE38D0008; Thu, 21 Nov 2024 22:54:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DCA098D0007; Thu, 21 Nov 2024 22:54:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB9028D0008; Thu, 21 Nov 2024 22:54:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AE8758D0007 for ; Thu, 21 Nov 2024 22:54:39 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5C4651C81EF for ; Fri, 22 Nov 2024 03:54:39 +0000 (UTC) X-FDA: 82812363312.11.F7666A2 Received: from mail-m6032.netease.com (mail-m6032.netease.com [210.79.60.32]) by imf30.hostedemail.com (Postfix) with ESMTP id 5F9B480004 for ; Fri, 22 Nov 2024 03:52:54 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=easystack.cn; spf=pass (imf30.hostedemail.com: domain of zhen.ni@easystack.cn designates 210.79.60.32 as permitted sender) smtp.mailfrom=zhen.ni@easystack.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732247585; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bQrffEVTvm2N+uVKxMBaWb5E3dHr3w1ioZwDFgQpMBY=; b=aPWhq4beWllpviXkFqRP+ZqTwe9Qj1L4jL9i2eKt1rnIDDESfnF8a1q8xF3+1oL8Bp5qZ1 hdCTNqz4KVEtMuFJtoj1IkkRWkdOUADvYxqKcjsW7ETWoTZTE6OmAEAJOSvwFOSc5kSFF/ 2Kor2lWYAGfHaQ81/4Ya70NwPj7wktU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=easystack.cn; spf=pass (imf30.hostedemail.com: domain of zhen.ni@easystack.cn designates 210.79.60.32 as permitted sender) smtp.mailfrom=zhen.ni@easystack.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732247585; a=rsa-sha256; cv=none; b=hogN+H34XJYgT9Fv8LaRwXGiol/L2yMB9pWKNU1gxIcotEABfpA6nNyWObjCbA/irb3An+ DJDcvUtpNX5KRYbs/2HZ3TrIwmtl73jrbDTG8qgZ479KH45ew6khXYYkDYBOnz4Wr0IGMe TCveJf4gcGRlYv9mop5Z9wyXKVH2Pic= Received: from [172.16.100.41] (unknown [180.111.43.56]) by smtp.qiye.163.com (Hmail) with ESMTP id 1b2e8221; Fri, 22 Nov 2024 11:54:31 +0800 (GMT+08:00) Message-ID: <80c4fd84-ad2f-4ad4-a81c-ca426871fac4@easystack.cn> Date: Fri, 22 Nov 2024 11:54:31 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/mempolicy: Fix redundant check and refine lock protection scope in init_nodemask_of_mempolicy To: Gregory Price , David Hildenbrand Cc: akpm@linux-foundation.org, linux-mm@kvack.org References: <20241121122409.277927-1-zhen.ni@easystack.cn> <7f9c4c98-86bf-40a0-817a-858767946cb0@redhat.com> From: "zhen.ni" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWS1ZQUlXWQ8JGhUIEh9ZQVlDTUtNVkxLTU1CHxkYHk9PTVYVFAkWGhdVGRETFh oSFyQUDg9ZV1kYEgtZQVlKQ0tVSkpKVU9IVU5NWVdZFhoPEhUdFFlBWU9LSFVKS0lPT09IVUpLS1 VKQktLWQY+ X-HM-Tid: 0a935201d39d0229kunm1b2e8221 X-HM-MType: 1 X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MAg6Qgw4TDcdGUwKIk4*OkoR D0gKCiNVSlVKTEhJSU9MTUxJTkhDVTMWGhIXVQETHhVVFRI7HhoIAggPGhgQVRgVRVlXWRILWUFZ SkNLVUpKSlVPSFVOTVlXWQgBWUFJTk5DNwY+ X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5F9B480004 X-Stat-Signature: gqkctn3dgyr1uze1w45ojtrd93qrtff6 X-HE-Tag: 1732247574-344921 X-HE-Meta: U2FsdGVkX1/r4384D8OQlUlle4aoZuYH7fq4uTfF9zfY24akGLXB0N6+aKW6+eL/H3xyd3VUIPpS6VfiUZyqduykjANJj4WiV1ummOHTuKS1xj9pdGzYRGfe/iSZJpJPzn7R8+m969FBBkYe8uArSpFr9OcdqHk7A79v92VV0p+vNTrTPGcedQtfvM4ABObtvW28CVlqPT583JNyZhmZYDl8B2veXfWSAC83SGtk1VC7l2H13jI9AF5yQueqKEi1g/BwQPnPfs2uUl4QKJu2PIApJdxv0JfTBYltdJSCORWZmd5t1vqPNLrkm/pJqiPB3UKnw5S8jIZ1ZDiaYpVo0UocJrS6n6NSCmq8qMynVpJaxek1llLFk8z72uKjG44pj8f/WHXrsx6L0+NiK7T9MAfgefY0cUCC4YruOUGNn48nvnHc11X/JU8t86BU9j3eLlP6q57jWolM1ZXZ+K+xAzyiDSZXlxzjl0qs1yjM2JTkdRJAoGlQmB52PlqGEmnmougbs2MN/ciaQHeXAITwaxD1bN6VrfzJnoaE1M/Mf2KvbYTyZsiT9OqUrRXBTyn43EPQYJ5ihkCDksnIFqIrefl0ydNtBcJ+KFYjWZd43ZtCDoEiFD825wX9MhBBWSyWKWL4MUhG4FEY7V5mX5pTWjr8jgyreO2vnQkqfZdkqbkX9E7yqgSbf0WCBfwEzcRKrpkLS9wy1TB1PfkktFhz4TJA4+OsNzMu7Jx95R8OtpK5DR6ID+QvSYF5hWwr8PqgBcV2lQuI3bcXRgePAGqIimCcS2V1IykdL9YyjwgZmuJFN/OuvyUJfYUiGjlkTi7fJnkNgmvHJ2eFdoFRB8yC9OdWR0TIWvzJX4rL4pbY/mf9Q5nWEhr2LYs56DLWDQtsjKMTHl8KML4P7nOxaywvSeB0hfzvr9f+7sGmKoW6Mo5ET6xLPFe0MnTe0VipkYRBe377ygwN1Hk3BvTBlaC gs8Jta8g aOgizya9tsw9vN4p7RN62VvKv+krVUsDeQOlpVlkOMvvWXEeec4YbwFlaeUvDoGzJBpZwazHjxqr8yAN8TGOjJ93Z8saDnEoGyd6PoeRIfekWAQWh86EIP9wYz/mK6skPRor7NYU0GIaw8VVV+usvzBmpPRcZh2PG4JM/DmGA0h9Na2LEThtPf5Y8/VQcygyVvEkM 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: Hi David and Gregory,  Thank you for your detailed feedback and insights. I deeply appreciate the time you’ve taken to point out potential issues and to clarify the behavior of current->mempolicy under task_lock(). Regarding the "redundant check" in my patch, my intention was to simplify the readability of the check for mask and current->mempolicy. Your suggested alternative: if (!mask || !current->mapping) is indeed more concise and clear. I fully agree with this change and will incorporate it. On the issue of reading current->mempolicy outside the task_lock() context, I acknowledge the potential for introducing a race condition when current->mempolicy could be dereferenced after being freed. This was an oversight on my part, as I was primarily focused on reducing the lock scope. Regarding the potential performance improvement, I recognize that the optimization is minor, and in this specific context, the lock is held for such a short duration that it is unlikely to provide any meaningful benefit. I’ve revised the patch to simplify the conditional check and added a comment to clarify the behavior of current->mempolicy based on your input. Additionally, I’ve removed the lock scope optimization attempt to avoid introducing any potential race conditions. From 073e4ac5ee6a3f2b45804492f3865cf9157155e2 Mon Sep 17 00:00:00 2001 From: Zhen Ni Date: Fri, 22 Nov 2024 11:48:05 +0800 Subject: [PATCH] mm/mempolicy: Improve readability of NULL check in init_nodemask_of_mempolicy Refines the readability of the NULL check in init_nodemask_of_mempolicy. Additionally, a comment is added to clarify current->mempolicy. Signed-off-by: Zhen Ni --- mm/mempolicy.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index b646fab3e45e..0f0dd33d20d4 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -2132,7 +2132,13 @@ bool init_nodemask_of_mempolicy(nodemask_t *mask) { struct mempolicy *mempolicy; - if (!(mask && current->mempolicy)) + /* + * While current->mempolicy can race with someone changing + * current->mapping, it cannot race with changes that set it + * to NULL. Such changes are restricted to specific contexts + * (e.g., process initialization or exit). + */ + if (!mask || !current->mempolicy) return false; task_lock(current); -- 2.20.1