From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD9821862A for ; Thu, 25 Jun 2026 09:31:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782379898; cv=none; b=J0fqhysLwcP6T/1OIbcqQna31KopGMJ9fkM6/zZYyUlO+L8t77Hov98Nk9RYNhZfiAT/Duct/rhffhfn5hG5TaK2NOpQVuhp4J6+WgjhliB1bix4XhkTGcuVkerr58Czw/tGYldbsXyLZNJ3qLUDoHF3twHBD282yt3vAwWvNos= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782379898; c=relaxed/simple; bh=fkf7yd1YPfuqOPlbSc/X6yN0iroGaC2l49WBsAjHmlg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MmodgddhDCLs8Yd46qz3Tb2ooVllfpcPo6nXsobBBfkjLfvrGeR38kB0zmA6E258c8hzY3nGVdET7zjVG5vZVeBseWNWyq/AY04ygf4UigT2BSWafiJwloCL0+NvfES5mY4triyL3zBvsoPY+YYd5tRBeLDgTc9wRhculx78qWg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=VsYM/5f9; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=0eBLQUrl; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=E6c4Pc2b; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=tqlubKtT; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="VsYM/5f9"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="0eBLQUrl"; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="E6c4Pc2b"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="tqlubKtT" Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id F37EF719E9; Thu, 25 Jun 2026 09:31:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1782379889; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=94hiD9d2NnJ31ei1N1NiQfwNES0m5KtvpFc7BqgKwu8=; b=VsYM/5f9VB+jp2qmMFx0NZtc6n4KIkwB4xQaSqPWfNnfwf7hCmMY+86JiumHgGGhgf7idI aKGK7Qz4gZ062kQzk3f95bG4U2f3RkRv8Syebwav3RAlmdiJd09qpaEM49AIEpbeJXgqQ7 VFqiqKO5EG72TaF3S4mfxqPpP4A+eaY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1782379889; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=94hiD9d2NnJ31ei1N1NiQfwNES0m5KtvpFc7BqgKwu8=; b=0eBLQUrla28s68U2rcaeuoxTfoURQlKvLOWQT8Fc/Zi3ghjSKFfVBkl0ZL/5fQN40H0AJN 3K+GKP7bJnUS4YCQ== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1782379888; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=94hiD9d2NnJ31ei1N1NiQfwNES0m5KtvpFc7BqgKwu8=; b=E6c4Pc2beWve9l24by2fDSAz2ofzvp1dURuA+vTP4DOGeB0l2uo8b5UEoxk4ilAmcKaBpv iqId3jvsClJPA0GnLur7TB4Iu+6W9+DN8brqrTTCwm7LI5iJF4wiTnEV9IUVF4J9l2nvaK 9yxjbNea1cP5fM0BhByhGPSbHb+XNro= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1782379888; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=94hiD9d2NnJ31ei1N1NiQfwNES0m5KtvpFc7BqgKwu8=; b=tqlubKtTxOPI3bbc223oR0p4/BTXcuaHxI3E3dH9sT7nf0UhvK4VO7Ag8C769SShDtMjPM qmpqGWugwzqGf9Dg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2A5B7779A8; Thu, 25 Jun 2026 09:31:26 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id iyAMB271PGpodwAAD6G6ig (envelope-from ); Thu, 25 Jun 2026 09:31:26 +0000 Date: Thu, 25 Jun 2026 10:31:24 +0100 From: Pedro Falcato To: Xuewen Wang Cc: akpm@linux-foundation.org, liam@infradead.org, ljs@kernel.org, vbabka@kernel.org, jannh@google.com, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, baoquan.he@linux.dev, baohua@kernel.org, youngjun.park@lge.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, david@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: annotate data-race in cpu_needs_drain() and need_mlock_drain() Message-ID: References: <20260625065153.1581419-1-wangxuewen@kylinos.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260625065153.1581419-1-wangxuewen@kylinos.cn> X-Spam-Flag: NO X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWELVE(0.00)[21]; FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[linux-foundation.org,infradead.org,kernel.org,google.com,tencent.com,huaweicloud.com,gmail.com,linux.dev,lge.com,kvack.org,vger.kernel.org]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[pedro-suse.lan:mid,imap1.dmz-prg2.suse.org:helo,kylinos.cn:email] X-Spam-Level: X-Spam-Score: -4.30 On Thu, Jun 25, 2026 at 02:51:53PM +0800, Xuewen Wang wrote: > KCSAN reports a data-race when cpu_needs_drain() reads another CPU's > per-cpu folio_batch->nr without locking, while the owning CPU writes > to it via folio_batch_add(). The same race exists in need_mlock_drain() > which is called from cpu_needs_drain(). > > Reading a slightly stale value is harmless -- cpu_needs_drain() only > decides whether to schedule a drain, and the next iteration of > __lru_add_drain_all() will re-check. > > All other callers of folio_batch_count() either use stack variables or > access their own CPU's per-cpu data where no race exists, so > data_race() is added at the call sites rather than in > folio_batch_count() itself to avoid suppressing KCSAN warnings for > future callers that may have real bugs. > > Signed-off-by: Xuewen Wang > --- > Changes in v2: > - Use data_race() instead of READ_ONCE() in folio_batch_count(), as > suggested by Lorenzo. READ_ONCE() is unnecessary for a single-byte > read and imposes overhead on all callers, most of which have no race. > - Move the annotation from folio_batch_count() to the actual call sites > (cpu_needs_drain() and need_mlock_drain()) where the cross-CPU race > occurs, rather than affecting all callers. > - Add need_mlock_drain() which has the same cross-CPU race. > - Add comments explaining why the data race is safe. > v1: > https://lore.kernel.org/all/20260624092606.1083449-1-wangxuewen@kylinos.cn/ > --- > mm/mlock.c | 2 +- > mm/swap.c | 12 ++++++------ > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/mm/mlock.c b/mm/mlock.c > index 8c227fefa2df..fbdb5018e2c3 100644 > --- a/mm/mlock.c > +++ b/mm/mlock.c > @@ -232,7 +232,7 @@ void mlock_drain_remote(int cpu) > > bool need_mlock_drain(int cpu) > { > - return folio_batch_count(&per_cpu(mlock_fbatch.fbatch, cpu)); > + return data_race(folio_batch_count(&per_cpu(mlock_fbatch.fbatch, cpu))); > } > > /** > diff --git a/mm/swap.c b/mm/swap.c > index 588f50d8f1a8..d046428caed6 100644 > --- a/mm/swap.c > +++ b/mm/swap.c > @@ -828,12 +828,12 @@ static bool cpu_needs_drain(unsigned int cpu) > struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu); > > /* Check these in order of likelihood that they're not zero */ > - return folio_batch_count(&fbatches->lru_add) || > - folio_batch_count(&fbatches->lru_move_tail) || > - folio_batch_count(&fbatches->lru_deactivate_file) || > - folio_batch_count(&fbatches->lru_deactivate) || > - folio_batch_count(&fbatches->lru_lazyfree) || > - folio_batch_count(&fbatches->lru_activate) || > + return data_race(folio_batch_count(&fbatches->lru_add)) || > + data_race(folio_batch_count(&fbatches->lru_move_tail)) || > + data_race(folio_batch_count(&fbatches->lru_deactivate_file)) || > + data_race(folio_batch_count(&fbatches->lru_deactivate)) || > + data_race(folio_batch_count(&fbatches->lru_lazyfree)) || > + data_race(folio_batch_count(&fbatches->lru_activate)) || > need_mlock_drain(cpu) || > has_bh_in_lru(cpu, NULL); > } eww. How about: static bool cpu_needs_drain(unsigned int cpu) { struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu); /* Check these in order of likelihood that they're not zero */ return data_race( folio_batch_count(&fbatches->lru_add) || folio_batch_count(&fbatches->lru_move_tail) || folio_batch_count(&fbatches->lru_deactivate_file) || folio_batch_count(&fbatches->lru_deactivate) || folio_batch_count(&fbatches->lru_lazyfree) || folio_batch_count(&fbatches->lru_activate) || need_mlock_drain(cpu)) || has_bh_in_lru(cpu, NULL); } this should work equally well, while being far more aesthetically pleasing :) > -- > 2.25.1 > -- Pedro