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 5A526C77B7C for ; Thu, 3 Jul 2025 16:39:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB9C66B015A; Thu, 3 Jul 2025 12:39:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C6AD76B015B; Thu, 3 Jul 2025 12:39:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA7C26B015D; Thu, 3 Jul 2025 12:39:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A7C366B015A for ; Thu, 3 Jul 2025 12:39:41 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5DD8216029A for ; Thu, 3 Jul 2025 16:39:41 +0000 (UTC) X-FDA: 83623514562.25.93F58CA Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf25.hostedemail.com (Postfix) with ESMTP id B27AAA0012 for ; Thu, 3 Jul 2025 16:39:39 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=V0mYxwTW; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.hostedemail.com: domain of tj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=tj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751560779; a=rsa-sha256; cv=none; b=yzL2q/i/Ng4FSR0sZBfWeTLpVWxynWU6GGVCew2c5gJk3LsJuSxcx1yXwBWf436IOa9M9n W8sjnHfVT1HxK8P7iW0/hfFwjGrRP9HIME55KgWiq8be/l8U5rK951FOe7BCpB3djb8O8+ bGbxSd00rAdpVdxNPCbGzPWynMXZgDA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=V0mYxwTW; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.hostedemail.com: domain of tj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=tj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751560779; 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:dkim-signature; bh=RGXjnnm3K/YxLIGOnINcenY3UQSoSKlez8JTsGi4lMM=; b=uOX2YXinWmCcd3Md7XHe8M4iY7cCcuLtGIzrze76l2DIr2AbHSAcs48G+cRBQBcBlALc0V ZiJ77QhW0MnFvYsuyuyuybf5GNTNvgcgl4bMZZiehoGnGmcpSl4VeDw8iRwmYdrRUee5mO uaHl4oo93I0IQVmp+c8kOvwg0blmRKU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 090E8A53980; Thu, 3 Jul 2025 16:39:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8ADE2C4CEED; Thu, 3 Jul 2025 16:39:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751560778; bh=WdgPxngTX8VmRp7AvbeAk+y0bbhMCt+pYEZaff3TjUA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V0mYxwTWgqT/SaprqM4Hz6+4OMFs+JMUZzMUJ60f95xXTdHt51yfk6ZV5y6Wsoro0 xKbmUKPPH8SNta23aMCBepvlF+5wcnHxa71GVF27dLN52/3dkFpIDddZGvS4+Qg9uf LCPifV0I7r/wDTcJsJxYhoJKdbQ89wkENODISw5LymzTgQvBrOio2pecjBs1fCJmWL Tl3QKoV7sjPJw8qhSF/87Ow5rfgkdM+yDX4HmIzH7P9KdMMDH2yKmaOs8LxnaDJq9l B7gxoPs/KGpSlCDmDd3P0ljdicWj1tG32DJ19q2M9j5+z76T38wwJNJRTY17wmLaro EzNXDdVlBZmqQ== Date: Thu, 3 Jul 2025 06:39:37 -1000 From: Tejun Heo To: Dennis Zhou Cc: Jeongjun Park , "Christoph Lameter (Ampere)" , akpm@linux-foundation.org, vbabka@suse.cz, rientjes@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+e5bd32b79413e86f389e@syzkaller.appspotmail.com Subject: Re: [PATCH] mm/percpu: prevent concurrency problem for pcpu_nr_populated read with spin lock Message-ID: References: <20250702082749.141616-1-aha310510@gmail.com> <7b7d353f-f38b-3205-8fd4-1072dbf69cb6@gentwo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B27AAA0012 X-Stat-Signature: i969eij616ae36af98q7rrokyi1fqsou X-HE-Tag: 1751560779-164093 X-HE-Meta: U2FsdGVkX19dp/6kI6fwzpnzPJg8o4MSU5hgs6uYRjA4eOT9DgxL++h0voiVDc3TQZrNYSye+lEjAt1l9ZbRfu5Phaz/NtuR8BWf1F29JWQjo22wU3F4sw6d2f6wIvHwXJxjLVhkVsICEysvT7+MqapT4xJa2aAGPrqnwP1a6I9NLqk6WfT5mgHCr1fg6jXTe3AiOu1NcUJsVgy0SFl6HOoMF2hFJm2xkwg1H0ol9QOxUJAJDvVxRPuS/q+NRDkN7GWVvljKtPAIC9MuO8WaPiOGRp8VjC49dOHJx/ryDW70EIBXhsXWoV/V3WLM4FgtengZ1isl0AvMiqmkIMIV5ggBESzZb5MoNn048igjUDClytkDoaFHkiQRfh3CXAeGLxCMG+SHWDxXE+swZrr52YsHg7m8/PJAstUTSR9QthM6Su/UmG+GSmuPr/yJPaDNkWR4uTE7nGtcKdAknhkdi5bIDfcswpFC2jh15+UlTwBGRF5tm4TAcmfFHXjYNbSWEvtUHf2vDUuUUwX8LtRx9MTN6se+r9hCcXf8p76dGdMy631+dRky2TVge1H2I5Wd2kQMTYVVHQHWowtn/pKsACxfprsODyVKsMBLywxpPoC19c+xbdX3vTjyZrBXk1rx45cIS3Huc0MeAZyC7nRS5cNhy0tubst4H5iZz/C7CVBRcHcmZeDNGfAybfXZq6bOCLRDdc4bi/IU6AzlFRMDMmJ3biCSMnx3g8Mf5ZP9hcxOC5Diu63+SQm4NacsrE1cYXryFMHmm9BMLigbQlU7wDfRpvF7QD7KOYvFwbx5vJtJkGC5XM2nVS9QGEkGhxZEFxjfGzfHkYlsedZLLiQvWSNgnkzA28vBZeH4iQSw3X7ZEN7a3xdMyCJxse+3KL/UbszK+527FjMqR+iUARESuV4S3jhZZL9oj2ziu0TR/OcgMXJz0fyJivj+COlpfu4Ze+fcKk/NzNRUO09LIby t5jp/v6b 8icSeG2kbqTJcI6rT92wMGBJpZL5+669lbaU3MdEtq7tG6LAlzZM4t+r9bqjl4bPP3RSX+4DoctMmuEhQJJ/M8WHqfLDsbYvFbMU8l8dbT/rPjNfLZOCGYOuk3arcKU191Ow+F8FkCrq9v9q2DfOLlyEaxGtxTx6ZtDLClmCCJK2J8H5QG5PWSE6MsUUp7fiLwc5OEx4O2k5iLH0+Hx3LAbXLo19Eb6YKN4dfAEFCwcZoq03VQGMzn6HTWe533/GJbHiBaBtVYtQykxUc3ZcZH9yp5LYqQpRGoSr3TLfC0gk6ahPWKJtO/Y8UDJ8TSgrZHO1VRIVp9HFJUJx5gvjJv9mnl5phn1YaKj5D 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: On Wed, Jul 02, 2025 at 10:51:25PM -0700, Dennis Zhou wrote: > > However, since pcpu_nr_pages(), which performs a read operation on > > pcpu_nr_populated, is not protected by pcpu_lock, races between read/write > > can easily occur. > > > > Therefore, I think it is appropriate to protect it through pcpu_lock > > according to the comment written in the definition of pcpu_nr_populated. > > You're right that this is a race condition, but this was an intention > choice done because the value read here is only being used to pass > information to userspace for /proc/meminfo. As Christoph mentioned, the > caller of pcpu_nr_pages() will never see an invalid value nor does it > really matter either. This isn't an actual race condition. The value can be read atomically and an unprotected read can't lead to a result which wouldn't be possible when reading under the lock. ie. Whether the lock is added or not, the end result doesn't change. It's just that syzbot can't tell the difference. Thanks. -- tejun