From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (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 C0A9C241663 for ; Mon, 19 Jan 2026 14:35:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768833353; cv=none; b=jMl+TGVDHYTSvxT9ohqbxRY0kjBTqAUtjXu3qF3Tc9j6elUv2LCtJ4W1G8l/cPRgLy8CJaPWqI0N/Nlr9T/PYil+GhnWwSESFm+t9MDWOanHhOxqxrJSmZyqIzREMCktMpfMnDqFYkfAKgVHO6NP1Jp1+fWijbU6OiQmbC18p6w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768833353; c=relaxed/simple; bh=bZp4gurbfHjK3O0u65z12ZPd50+JQtOOSP0sZ8LFzag=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=s98HpYtSwFC3KWgc8GsSJynJ7FHxBVOKGCuIEEgmJrICQ5TeIwytnwd/LzIUlOoQLefTo4W8679WJv2gQw27pUFToazyXB8FqWOwD53iNhUJgQIVUG9nOYQGhJTGfHXGg6j87XORK/cBcqdRKdbndH+hj2CuRidvypOKnyJn4P8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=eieS91i4; arc=none smtp.client-ip=209.85.219.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eieS91i4" Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-88059c28da1so36155776d6.2 for ; Mon, 19 Jan 2026 06:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768833351; x=1769438151; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=eXq+PWkPG1nHye1gMKa1/5w7nQSLXCkEOoBAppRannc=; b=eieS91i4uV8HDWVjjwZ6hJbMMIEQ/heN7IyNMRdx1j/B7N3JeCCM/5l0Wmc76CZyql TOr2ISKddHJpeXOfh7CBt4feIzcgt/qdIwGxvUSm1bLJZCsiraqS9clMAjacof6OQJNw HH0VkfgocKUrfInDQds9MaZXhpGMJZlhIeD/SQyOhP3QHzH7GbWzBVKIt2HH1jnUmYyu OYHc1ZQSJuwBRG6/x23Y11+eHG8dj/YGr8wX9u1YKWl71a8i8JUb+DGN4/wjIjFRjmis IXMWj48omISCQ4hUDQohgjQVv4bMdkeLO9h9v2ITlbkI6H5DM2GDigKFf3cWFXCNJs1G rsyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768833351; x=1769438151; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=eXq+PWkPG1nHye1gMKa1/5w7nQSLXCkEOoBAppRannc=; b=SoXPhXZ58Uh7HDg5UtcBxp93bDOu0QRStfgiU6RClYXu2O904JCZYOpzUM4QImyJKT yhbkDtQ87w9JX3ry2uRvTtwqr0gtAk8jCDGfKBEMROgV3azoFKI7XP/8lUdejbnirYrD ByVZmUV+9oZaSzxgFYchkKisLSK4/F1/DXW+FjSjHo8O0OiCIKXwuBw8uy5MQTJmTEAQ GpaTv3LSWO48Mn7eppcPsZ2ob0lzxrR2/1RadhJLflo7lV8LMNW4BYWJSMD9j85gY05y TS4h/oPmvNdmfmr57egrash6b3ndUNdgBcs4oCi3mPCLDcBFJSDaNVVA4kUEnmDpAUhK 5vBw== X-Forwarded-Encrypted: i=1; AJvYcCWcIbgmNpz2rw/ZB9HJVGLvFELMGPRnIMnAz981pmZuyG+5BCUo/NDUovvs6s9m/r2+IPgb/F/UvxO0LGM=@vger.kernel.org X-Gm-Message-State: AOJu0YxtnjymO4dY/6Nmpwq673eswzlAqSc987i087PPt6r7QyFVr2zk EOBImsm/+cwNFmnzINlF9bHsOSX6m9qWNeZ1DzgSsVB++KHbfoZ+VIFy X-Gm-Gg: AZuq6aJ0UWlu0i6JOrJBgo1BxYtNHEVi9sfv6sa4nTTifKYf0CO2glVTHUAiQaPobaU hmq53y4pxUNFwhlutS7GzutpUvX8E/zflWYewf5t0OewrcOySRWM1RYFQ9X7WlrGsZxi54ZPji+ ypgidsTISsiHpU2/z0s/fWBlSQyzZRZHhPYT9aYru9ETZWlrneZJ2GkRTH/UlcmtOMoNGmPYK33 mRwlskE1kwd6cxl0WCyRBnIQg/ZQy8qFohSFKhlmHf1XgNiGLPYjNEkra2f1r42xfkllL6joTQH MhsLpxwuam4fT8x5/S193uPM5mTVQU9OOj+wO44gedTJqJ7qRbwlRlUSvjWGolouFgLRWYd/40n 5ALT9nz0O46J6Asol8t3VMM0cyuPi5aJ0eTwpoVHNpticdPsP/3hxMkIvPEs9ioLBlBDTH1Ee4m 0AuOIwIks2OPy21opzHQBWjon0qDGVObKRuvt0bijc2hFxZblsIRZjQOsTmqluZRE4mWW4bxfSe AUlRDAzZlICmDc= X-Received: by 2002:a05:6214:1d25:b0:888:fc28:7d0a with SMTP id 6a1803df08f44-8942ddc534dmr173016936d6.51.1768833350469; Mon, 19 Jan 2026 06:35:50 -0800 (PST) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c6a72985a8sm800086285a.54.2026.01.19.06.35.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 06:35:50 -0800 (PST) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id 5C19EF40072; Mon, 19 Jan 2026 09:35:49 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 19 Jan 2026 09:35:49 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddufeejkeduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhunhcu hfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrghtth gvrhhnpeehudfgudffffetuedtvdehueevledvhfelleeivedtgeeuhfegueevieduffei vdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsoh hquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedq udejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmh gvrdhnrghmvgdpnhgspghrtghpthhtohepudekpdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehgrghrhiesghgrrhihghhuohdrnhgvthdprhgtphhtthhopegrrdhhihhnug gsohhrgheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepfhhujhhithgrrdhtohhmohhn ohhrihesghhmrghilhdrtghomhdprhgtphhtthhopehojhgvuggrsehkvghrnhgvlhdroh hrghdprhgtphhtthhopegrlhhitggvrhihhhhlsehgohhoghhlvgdrtghomhdprhgtphht thhopegrnhhnrgdqmhgrrhhirgeslhhinhhuthhrohhnihigrdguvgdprhgtphhtthhope gsjhhorhhnfegpghhhsehprhhothhonhhmrghilhdrtghomhdprhgtphhtthhopegurghk rheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepfhhrvgguvghrihgtsehkvghrnhgvlh drohhrgh X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 19 Jan 2026 09:35:48 -0500 (EST) Date: Mon, 19 Jan 2026 22:35:46 +0800 From: Boqun Feng To: Gary Guo Cc: Andreas Hindborg , FUJITA Tomonori , ojeda@kernel.org, aliceryhl@google.com, anna-maria@linutronix.de, bjorn3_gh@protonmail.com, dakr@kernel.org, frederic@kernel.org, jstultz@google.com, lossin@kernel.org, lyude@redhat.com, sboyd@kernel.org, tglx@linutronix.de, tmgross@umich.edu, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH v1] rust: hrtimer: Restrict expires() to safe contexts Message-ID: References: <20260110115838.3109895-1-fujita.tomonori@gmail.com> <877btdpyz2.fsf@t14s.mail-host-address-is-not-set> 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: On Mon, Jan 19, 2026 at 01:07:58PM +0000, Gary Guo wrote: > On Mon Jan 19, 2026 at 12:29 PM GMT, Andreas Hindborg wrote: > > "FUJITA Tomonori" writes: > > > >> HrTimer::expires() previously read node.expires via a volatile load, which > >> can race with C-side updates. Rework the API so it is only callable with > >> exclusive access or from the callback context. > >> > >> Introduce raw_expires() with an explicit safety contract, switch > >> HrTimer::expires() to Pin<&mut Self>, add > >> HrTimerCallbackContext::expires(), and route the read through > >> hrtimer_get_expires() via a Rust helper. > >> > >> Signed-off-by: FUJITA Tomonori > > > > Patch looks good to me, but I just want to check with Lyude about their > > use case in the rvkms driver. I think that is why we did the racy > > implementation originally. In C we have stuff like this: > > > > > > /** > > * drm_crtc_vblank_get_vblank_timeout - Returns the vblank timeout > > * @crtc: The CRTC > > * @vblank_time: Returns the next vblank timestamp > > * > > * The helper drm_crtc_vblank_get_vblank_timeout() returns the next vblank > > * timestamp of the CRTC's vblank timer according to the timer's expiry > > * time. > > */ > > void drm_crtc_vblank_get_vblank_timeout(struct drm_crtc *crtc, ktime_t *vblank_time) > > { > > struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc); > > struct drm_vblank_crtc_timer *vtimer = &vblank->vblank_timer; > > u64 cur_count; > > ktime_t cur_time; > > > > if (!READ_ONCE(vblank->enabled)) { > > *vblank_time = ktime_get(); > > return; > > } > > > > /* > > * A concurrent vblank timeout could update the expires field before > > * we compare it with the vblank time. Hence we'd compare the old > > * expiry time to the new vblank time; deducing the timer had already > > * expired. Reread until we get consistent values from both fields. > > */ > > do { > > cur_count = drm_crtc_vblank_count_and_time(crtc, &cur_time); > > *vblank_time = READ_ONCE(vtimer->timer.node.expires); > > } while (cur_count != drm_crtc_vblank_count_and_time(crtc, &cur_time)); > > > > if (drm_WARN_ON(crtc->dev, !ktime_compare(*vblank_time, cur_time))) > > return; /* Already expired */ > > > > /* > > * To prevent races we roll the hrtimer forward before we do any > > * interrupt processing - this is how real hw works (the interrupt > > * is only generated after all the vblank registers are updated) > > * and what the vblank core expects. Therefore we need to always > > * correct the timestamp by one frame. > > */ > > *vblank_time = ktime_sub(*vblank_time, vtimer->interval); > > } > > EXPORT_SYMBOL(drm_crtc_vblank_get_vblank_timeout); > > > > > > Also, we got some new docs for `read_volatile` that allow us to read > > memory outside Rust of any allocation that are not "valid for read" [1], > > meaning racy reads are OK as far as I understand. So the original > > implementation might actually be OK, although the number might not be > > correct always. > > The wording is for MMIO and should not be relied on if the accessed memory is > C memory. Also, `HrTimer` is going to be a Rust allocation. > Right, "memory outside Rust AM" should mean memory that outside both Rust and C in kernel (i.e. userspace, MMIO, etc.) It's not a "out-of-UB" free card. > Even if we don't treat it Rust allocation, it's also only "fine" in a sense that > you don't get UB for doing it. But the value you read can still be completely > meaningless if the updater is not atomic (it would be valid compiler > implementation to, say, turn a non-atomic write into a write of a garbage value > and then an overwrite of the actual data). > > I think the usage you quoted is just wrong, as on 32-bit platforms this could > well read a teared value. > Agreed. It's a data race any way, unless there is a proof that ->exipres won't be updated during read. Regards, Boqun > Best, > Gary