From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ilvokhin.com (mail.ilvokhin.com [178.62.254.231]) (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 D145F3E3D9C for ; Tue, 4 Aug 2026 17:31:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.62.254.231 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785864688; cv=none; b=XBHz6ZAA9GXbOKIPTdLZ5BDrYEJCDbIlP0TZaJk4r8RMOYYDBelNXb6+QlNJGID4CkMFf/cpbAIeo+BuWSLvMdcAonvhSaq8ObJOcaN+RuaUFTPPdgUCJuuhNX66itAgqiYMyUTIsC9TI6Ov5hO5ooq8sHPVRe9xpwFUZVWUK/I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785864688; c=relaxed/simple; bh=CIhegm3zFoRee+4URICIiIa/F9EfDVMmsMZNQCxL4os=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EpC2w5j/99O+4S5wVgD1qexdO6NblMUD6jj+iNfBxjJU5VXpget5c/5LC9HwT3boKOZKb/tJdMBFwOdhJIkZzOBund3fIm66fQOXvUlDc2sMTQ/8Muo/HTBGLZIaJ6IMuZbwh06cwVis7aw92okUoJeF5HbM+AySZVGFvgyiS/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ilvokhin.com; spf=pass smtp.mailfrom=ilvokhin.com; dkim=pass (1024-bit key) header.d=ilvokhin.com header.i=@ilvokhin.com header.b=lRWZKzIs; arc=none smtp.client-ip=178.62.254.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ilvokhin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ilvokhin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ilvokhin.com header.i=@ilvokhin.com header.b="lRWZKzIs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com; s=mail; t=1785864684; bh=A4x1FwbBnHfXe3I4Sc4uIc2GCHMP6nIWar1t7QW3kZ0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=lRWZKzIsakWjnCGqr4UTqDafulmBafe5Vrry+3L0lR4U4Oky6qrQsj/g6XI84dbjq QttPfZUFClefDF8V+1YsAcemBNTIqWTWdKCABRLO0ZkG2K5dw9ewd+bJyZ/QcN4b/G hcypSLcei95PDbkUhj+1u094gIWDyKyL7epIFYjk= Received: from shell.ilvokhin.com (shell.ilvokhin.com [138.68.190.75]) (Authenticated sender: d@ilvokhin.com) by mail.ilvokhin.com (Postfix) with ESMTPSA id 07C9FE17F2; Tue, 04 Aug 2026 17:31:24 +0000 (UTC) Date: Tue, 4 Aug 2026 17:31:22 +0000 From: Dmitry Ilvokhin To: "Paul E. McKenney" Cc: Anna-Maria Behnsen , Frederic Weisbecker , Thomas Gleixner , "Peter Zijlstra (Intel)" , linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH RFC 6/9] timers: Use accessor for hrtimer_sleeper ->task field in sleep_timeout.c Message-ID: References: <20260731004019.3530210-6-paulmck@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: <20260731004019.3530210-6-paulmck@kernel.org> On Thu, Jul 30, 2026 at 05:40:16PM -0700, Paul E. McKenney wrote: > The hrtimer_sleeper structure's ->task field is used as a flag to indicate > that the associated hrtimer has expired. This means that the hrtimer > handler can be storing to this field while other code is loading from it > to check for expiry. Note that additional races appear for hrtimers that > can be restarted, which could be argued to be a user error. However, that > is no reason to let the compiler introduce additional confusion, and to > this end, the hrtimer_sleeper_task_get() was introduced, use of which also > has the benefit of avoiding open-code access to hrtimer_sleeper innards. > > Therefore, apply this accessor to schedule_hrtimeout_range_clock(). > > KCSAN located this issue. > > Signed-off-by: Paul E. McKenney Reviewed-by: Dmitry Ilvokhin