From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D64829D265 for ; Tue, 23 Jun 2026 13:25:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782221114; cv=none; b=pN5XOoUV9tNIHNesxMjGVa9Nu8VnlacnW0Fu3MEHB0dztZmGXBEdzx1+Pi3J47rb648QYtzDTOiMJauGFTlZBY0rP7yNez3zWAovTLPe30u6IoD4Lu+KuM5YAD9E2ukt9e8hwtDQnIcHVA/Ej4mpmdjpWnvfwbAReW7l2z1u6fU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782221114; c=relaxed/simple; bh=9Msg/ycwF7/VNek3/osRjcVMj4Rp71PfUH99RD9iahE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a6GGaEFUu5RSvUWshjbCTSWjuT+7cVgv9snDS4lCfVTHoTwZH8TF4iVlHXUlh8q7x2XDZPyMtcXaOMY4BoxG4DkTLaZTR10YUqBAXd1FFI2KxGDlKNg4KhD/zy7C6FTlyYfA2T0tzkrShXwShrn8B+G+Ag3ppR0xDvpTz5dPLhc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=mvF6BJEq; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="mvF6BJEq" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zaYZZ1kTHN4wf1xIU36fLgWWQPwEq1Jpd53jaXMFQNM=; b=mvF6BJEqdDjz2grio+J4mmWNb9 MQXTHTsMP0lPjomNd4dKEiHTfxDYph7onhBV49hPIaPUAABgNNhvLwurJPpFJek2DXsiEBANM2BSI byvv6rnbrbqA9+LRIRDQu/YFnMzkwmzTbaQz31TgdcJuhFl+SJ0vY3DHJwlLmOyMuEbc/Rmbwa+1i QmuYUOwL9UatvIhgrsm+s0RJwd/1TyDz4/zyU+CfCNh1aZhb7hpRLDK2lzHRcrVE9SzdcCOCbjFwG TC4zp+LzB0CgFeSaGNSlxh1A15bLd0CZp8WZev+RosPZxccb/caxxyAGoTbzOgBZZ7COU2zEiNh5t IFaKpOBg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wc17l-00000006Dmm-1wj9; Tue, 23 Jun 2026 13:25:09 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id E102530324A; Tue, 23 Jun 2026 15:25:08 +0200 (CEST) Date: Tue, 23 Jun 2026 15:25:08 +0200 From: Peter Zijlstra To: Sun Shaojie Cc: boqun@kernel.org, linux-kernel@vger.kernel.org, longman@redhat.com, mingo@redhat.com, will@kernel.org Subject: Re: [PATCH v2] locking/percpu-rwsem: Annotate intentional data race in readers_active_check() Message-ID: <20260623132508.GA1181229@noisy.programming.kicks-ass.net> References: <20260623094450.GP42921@noisy.programming.kicks-ass.net> <20260623104132.505117-1-sunshaojie@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: <20260623104132.505117-1-sunshaojie@kylinos.cn> On Tue, Jun 23, 2026 at 06:41:32PM +0800, Sun Shaojie wrote: > KCSAN reports a data race between readers_active_check() and a > concurrently executing reader: > > BUG: KCSAN: data-race in readers_active_check / percpu_down_write > > race at unknown origin, with read to 0xffff9f3eb5bf5f30 of 4 bytes > by task 1271 on cpu 14: > readers_active_check+0x... > percpu_down_write+0x152/0x1f0 > > value changed: 0xfffffff9 -> 0xfffffff8 > > readers_active_check() calls per_cpu_sum(*sem->read_count), which > iterates over all CPUs and reads each CPU's per-CPU read_count > variable. Concurrently, a reader on a remote CPU is modifying its own > CPU's read_count via this_cpu_inc() / this_cpu_dec() as it enters and > exits the critical section. These are plain reads and writes to the > same per-CPU storage, hence KCSAN flags a data race. > > This race is benign. readers_active_check() is called from the > percpu_down_write() wait loop (rcuwait_wait_event) after sem->block is > already set. At this point: > > - New readers must immediately back out (they see block set, decrement > their counter, and wake the writer), so counters can only decrease. > > - If the sum catches a reader's increment before its decrement, > readers_active_check() sees a non-zero sum and returns false. The > writer merely iterates the wait loop again -- a harmless retry. > > - A false zero (observing sum == 0 while a reader is still active) > cannot happen: per_cpu_sum() reads each CPU's counter, and each > per-CPU int read is atomic on all architectures, so an active > reader's counter is always seen as non-zero. > > Annotate the read with data_race() to suppress the KCSAN warning and > document the intentional nature of this unlocked access. Thank you, much better indeed.