From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 46AF440B105 for ; Thu, 13 Aug 2026 11:52:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786621974; cv=none; b=cLzjPL533bKTq5BfwIwULiOOnjI16Q1lKZWaj3eiROMrorwJdpSChYJCRcNDFu0c7Qldqq581UeunQXsxRv0TOgcbMZvDIhVzgWqzX/kx8z+XFMMHB4rWXWk+dUcZYIUXIFMXJagCqBrdSWAP0h8AaeqzEalCGwioKdhc23f21I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786621974; c=relaxed/simple; bh=AuHq3qgQq4YtsALpAo8Psk1vtzIZha5h3SBm3BFWw4o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dW1NjtMsN5d1bDHJy9RFt6Ey+0ovI00EJjBBr+/vtNL+ug5GYMc5dLYJqyWUrUJaLUyOEoQCSpwq7rcD/qgX4rUdrUaEbd4ZdfxNsImfNMcIprMNKrXP2WQ/1IAKING5rW7GUXDBAIbiJ4x5PDR2vLPdsTihPBJE95rH+o5ZFhk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=iS3o6exY; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="iS3o6exY" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=KZID0CmTiXTuH0cE/dn5dLCjcrzH6iTndselgUp+uLc=; b=iS3o6exYRraxhdw7VlU6QErwot Q8VsvFjxZejgsD+fYvF8BZlk3e3z7CbL4qomIPJx6eaYBOcDXs/a3ldN1hdN2ebVg+z2Hhy4F5u25 jtw54UcKyaY/Mf6JJ79BTEf9Yo4t04luUQibEMABWOp3M7GqiTDcsfPkAaf3p0XPRsJORYhLFGBUk ruLl79egR2f8p8NJm799mX/lzMTTfhM2FBritXb2bqXY6JMNBaWDLNOndWXH3PBVNxCswHACfqYPM S8wkB3GLtGFMrReTvLveUGsCuCLJ0Cn58O99tdRDbRwL0jqtZBcx+tr+H+gv43m3v5pCIZXlJ6H+O KD7Dm3Ag==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wuTzJ-0055dS-2H; Thu, 13 Aug 2026 11:52:45 +0000 Date: Thu, 13 Aug 2026 04:52:42 -0700 From: Breno Leitao To: Tejun Heo Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, kernel-team@meta.com, Bradley Morgan Subject: Re: [PATCH v2] workqueue: annotate racy p->wake_cpu accesses in kick_pool_pick() Message-ID: References: <20260811-wq_race_kick-v2-1-6e66ff12d8ae@debian.org> <90e44e95a0b95c74dfb260a335ab0fea@kernel.org> 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: <90e44e95a0b95c74dfb260a335ab0fea@kernel.org> X-Debian-User: leitao Hello Tejun, On Wed, Aug 12, 2026 at 08:25:28AM -1000, Tejun Heo wrote: > On Tue, Aug 11, 2026 at 02:55:56AM -0700, Breno Leitao wrote: > > The race is harmless, this patch only acknowledge that this is racy and > > it is fine, silenting KCSAN. > > Can you say why it's harmless? wake_cpu is a best-effort placement hint. > Every writer stores a valid CPU id and the wakeup path validates it > through select_task_rq(), so a racy value only affects where the worker > wakes up. Also, s/acknowledge/acknowledges/ and s/silenting/silencing/. Ack. I will spell that out in v3: wake_cpu is only a placement hint, every writer stores a valid CPU id, and select_task_rq() validates it at wakeup, so a stale value _at most_ wakes the worker on a suboptimal CPU. > > - if (!pool->attrs->affn_strict && > > - !cpumask_test_cpu(p->wake_cpu, pool->attrs->__pod_cpumask)) { > > + bool wake_cpu_in_pod = cpumask_test_cpu(READ_ONCE(p->wake_cpu), > > + pool->attrs->__pod_cpumask); > > + > > + if (!pool->attrs->affn_strict && !wake_cpu_in_pod) { > > The hoist drops the !affn_strict short-circuit and adds a declaration > after statements. Can you keep the test inline in the condition? > > if (!pool->attrs->affn_strict && > !cpumask_test_cpu(READ_ONCE(p->wake_cpu), > pool->attrs->__pod_cpumask)) { Ack. It also keeps per-CPU pools (affn_strict) from paying for a mask test they used to skip. Thanks for the review, --breno