Message ID | 20250312141014.129725-1-mathieu.desnoyers@efficios.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 8CD13C28B28 for <linux-mm@archiver.kernel.org>; Wed, 12 Mar 2025 14:10:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9AAB280003; Wed, 12 Mar 2025 10:10:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4A8A280001; Wed, 12 Mar 2025 10:10:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9161B280003; Wed, 12 Mar 2025 10:10:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7259D280001 for <linux-mm@kvack.org>; Wed, 12 Mar 2025 10:10:23 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 89463160BE0 for <linux-mm@kvack.org>; Wed, 12 Mar 2025 14:10:24 +0000 (UTC) X-FDA: 83213083968.19.0A4601F Received: from smtpout.efficios.com (smtpout.efficios.com [158.69.130.18]) by imf29.hostedemail.com (Postfix) with ESMTP id D2AB6120010 for <linux-mm@kvack.org>; Wed, 12 Mar 2025 14:10:22 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=uVGW78IH; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf29.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 158.69.130.18 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741788623; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=VZ1M5G9yqFimuqnI+BpMOItPkdikFAPNOI68AvSjfaM=; b=N0g/jpNeJoqNJZ4MqGa0NKL8P4TQCCUuPYdwqsDbRdwYzjoxl9+WPlW/VbzBfbeQGK2lt+ EKJW01ifDix097HHvmCnQiExZyfmME70lfx7QFtaMRQ9wwy+biBfpbfQrYe0xa1GNKZZgM tAWK96wkpf9qvKYPCkqz5x9SS7o3dtg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741788623; a=rsa-sha256; cv=none; b=yYspLsv2jUzf+oDwbbDbPfRCJc8w06kWAGlbmoRybGeFtZmhEqt+93XndS+uEBW5ZPRbmI 6vUWFzg1x5+PE2LLh6BrHHmTIVfCL0QzAHMfjHQmZdyqGULzk+Nx0Rci+v+/G5nrrhQ2Qi kzpHp+qakYeR56hSHAUN+Eh/qe1F+J4= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=uVGW78IH; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf29.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 158.69.130.18 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1741788621; bh=MipAKpvbmNfmxW0K3rXTS/6tsgSsxzcTZj33h5g1JrI=; h=From:To:Cc:Subject:Date:From; b=uVGW78IHEoxm9gFvMdpkcmITWNsaQ5rOcxPLphPcpCZwQ0LUDP1G2hqgsniAf4bKA SfBBLPEC2tuoEKbSunREAW5o5Q/Ocv+vZ+L8VeeYcJCDvCOI96GtV1I9r/vYldcx1O aSWGWlBEd0vtoaWZA711XzQRRU5U0n6VB+ritr3GBtm6SUldiy//Rj+gz5L1I8HWf/ 1gcGbmYobSw61GINfuvxei8eRK9M0H4IAEbDyiyFZutMPqD8T4X1eMfhpS0vc1J7WY /8omuRblm0pxfJR+VL/2hz1a4K4oLo/5RvkGv5aEaekyKOKARjKJlNP9RW9/khqhyr Sas4MrG72guyQ== Received: from localhost.localdomain (96-127-217-162.qc.cable.ebox.net [96.127.217.162]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4ZCXb14tPjzV0D; Wed, 12 Mar 2025 10:10:21 -0400 (EDT) From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Lorenzo Stoakes <lorenzo.stoakes@oracle.com>, Matthew Wilcox <willy@infradead.org>, Alan Stern <stern@rowland.harvard.edu>, Andrea Parri <parri.andrea@gmail.com>, Will Deacon <will@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Boqun Feng <boqun.feng@gmail.com>, Nicholas Piggin <npiggin@gmail.com>, David Howells <dhowells@redhat.com>, Jade Alglave <j.alglave@ucl.ac.uk>, Luc Maranget <luc.maranget@inria.fr>, "Paul E. McKenney" <paulmck@kernel.org>, linux-mm@kvack.org Subject: [PATCH 1/2] mm: Add missing release barrier on PGDAT_RECLAIM_LOCKED unlock Date: Wed, 12 Mar 2025 10:10:13 -0400 Message-Id: <20250312141014.129725-1-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D2AB6120010 X-Stat-Signature: 58eg9dn3k1j1yn3p7bcxbra4cuk9thqp X-HE-Tag: 1741788622-62211 X-HE-Meta: U2FsdGVkX18YQ1xii7L/+HhkbAONAol/FXVxdHJkso+6LrzsbMrG/A/sXud7m3IXKkJyWFalpG6yAoDhG4Yqa7pidqV8Tj//5tqy3GzrZEs3Dc4O4SiKiNJ3//XZAU1+biOIYTlDvjDOv7GN5qk1IP59ytGbu6yKD2nXgO6azglzrJdLk/hFipW/lidxGzxPxgnhNL0LwJIySClUmWEmQgPSMTMWPWbKppEcS/fVzKatbXU0IK/P7+ENAjtCFLO2PUa31K3YnSBm4QC7RzxD7S9CGU+4Nxzgmnt9Fl08CSQgBCUdTwi29Xdy7GDcC099KofRGa1725K7XZps9loZHm2h3A9LQl1fNrgL887HPOjB2s9w12DWqCmDD5aYnRz3h9x3O5ErSOQSAwE1yaqRZ7oty0qXXtyZg7+RiRtZSu5KLXCIpr4HMcIHoePrUCFM5Y0kQq/mKWmL7nr204/u7rkv5N6JnhuOyt3b0NpOixWtH+cM9Xf4ymF/nY2a6iYdjyW8kN9FbXcgYoiO8eHq4b1DR1Km0wNydBMGLost1YHKwfwwHcCGQSEmIIHrMVT/+Rh0YiFEdH3FAnNQlN9jtQkqLl9RQCyZIPbx4lpUoirrU9iNExxClmC7mUsyvRHcb4kLOLJ5OXuwxocwDn2R9CZ0P/mzpG+yHHLmWur/GOFnYujwoJILVTpAMlDQmYa3ZRgZJMDdwD6MyHpNAwsfMfgArsCVh4mHo8BB1FnemFot6EsAn083jAro+Qs7oXaI5Uc6PrdhtVy14pBOoqQN53WA9ikngYV8g/l5yubVBPVZON1W7dIt3LjvwBDPUh+VKZDyOYw8HlQ3598g47t6SJ6KGtSOr6AU9I1wNA2HyCnf2SY++ggWf7Fi6Ydut6cVYftRl/97laIM1tLhgeJrCU1vp5hi9shwrKTbYDQMp4UX8pqth/J/izkcatOyw0u7R9dsNRkQX6LNfftkVPU zd4rsWRd 2hCIrzt+CKIqaXFUQlCPs6ls1SMVPixk2GEoHf8hsjT2a8FPg7vQEcoOoWRxupU6wUpuIjHBeYxuR8m8c2stkep4GJEc28mxzdkc+nVb5QbkLQzFKmjP1Nck1B6PX/4Pul8m+m379xwSz82YT0hYBzk/QFqvGnQxTIqqHtyLYNoxhOXrjJqhNi3tyCShs3cVr7Jc1yvurhhJia8Qd2+2xIHY9wBabAexH4bOar0Ay/wEgC21UkwAjLYDCJ8bGJzmkpe3/KxK6MiKwzTG8yrWD1Cc36tIDFcvnqvhs5FozH/jbhHjBJmUTJHOUgGwYSa+cF3shfEUEE8yFtyL02zn2nNyP89rbe6gaH8xYE5HX+1vX5iOy8AfjNPWjCz5+ij8EpVWJt+LJ+OhyKdaoij/cqo4OtVCuRNVEWhbOz9UwgKASzGO1vFmU9vrltzQloXoNM2MwhxfH3C/u/5GDAG0IsPN7IaHJLgQbbFDaAKQDenQWxd2KrN4WRG4LsGygWjd7/HpkHwUNq0OImxNOV2mqngVcej2kRgpn+JXOu+0p0cI0rQNVFlgwkx4AdTEx21ekvIwABavaf5O/dEx+cNZ4rYnm6UXjT37c+A+D3BGXgCL01esgDEpdDlOqPZheJ4EXLStauEMM21jf72NVCc2vnmqS6s2xMjE2AZFlvgIVbbNk14wx5l2CiUS/FTzANYWj1w07Cu1GhDh4B4jh5OzeY4Cv0A== 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
[1/2] mm: Add missing release barrier on PGDAT_RECLAIM_LOCKED unlock
|
expand
|
diff --git a/mm/vmscan.c b/mm/vmscan.c index c22175120f5d..d7e27d5c24e7 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -7571,7 +7571,7 @@ int node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned int order) return NODE_RECLAIM_NOSCAN; ret = __node_reclaim(pgdat, gfp_mask, order); - clear_bit(PGDAT_RECLAIM_LOCKED, &pgdat->flags); + clear_bit_unlock(PGDAT_RECLAIM_LOCKED, &pgdat->flags); if (ret) count_vm_event(PGSCAN_ZONE_RECLAIM_SUCCESS);
The PGDAT_RECLAIM_LOCKED bit is used to provide mutual exclusion of node reclaim for struct pglist_data using a single bit. It is "locked" with a test_and_set_bit (similarly to a try lock) which provides full ordering with respect to loads and stores done within __node_reclaim(). It is "unlocked" with clear_bit(), which does not provide any ordering with respect to loads and stores done before clearing the bit. The lack of clear_bit() memory ordering with respect to stores within __node_reclaim() can cause a subsequent CPU to fail to observe stores from a prior node reclaim. This is not an issue in practice on TSO (e.g. x86), but it is an issue on weakly-ordered architectures (e.g. arm64). Fix this by using clear_bit_unlock rather than clear_bit to clear PGDAT_RECLAIM_LOCKED with a release memory ordering semantic. This provides stronger memory ordering (release rather than relaxed). Fixes: d773ed6b856a ("mm: test and set zone reclaim lock before starting reclaim") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andrea Parri <parri.andrea@gmail.com> Cc: Will Deacon <will@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: David Howells <dhowells@redhat.com> Cc: Jade Alglave <j.alglave@ucl.ac.uk> Cc: Luc Maranget <luc.maranget@inria.fr> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: linux-mm@kvack.org --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)