From nobody Sat Sep 26 18:54:52 2026 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 3FA8F4078FA for ; Mon, 31 Aug 2026 12:56:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788180969; cv=none; b=f/RrEjJAYXyuzcgdo4RdGpVGdDu+spwpi83ulGpRP31C2yuG5kBU+pICMRIj9N+WOiSe10MFVa82Ls8fEQZTNH1Vw0j27e26nGQ5NP+grLPSRMIp7Q2l+GodndxdSzA5sXlClWKbSGNJa7Tkp9rIUWmLxZvANh+3HYdbU3dgKBk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788180969; c=relaxed/simple; bh=vqo1fTstjQ2cPevYsFrEYAoA+m0PR9U/HfWbbwRU5ys=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bXUFyDvCCIeBiz4iuKJV4qH8ZkTUdRvAqzQir+6zf2NjQuFsL4oXrQ4qGphpUPxSbhpwlp8VSdH5sZkySWRqJX7/CqApfWQ0pzad2hjI3iaS0PKoxzLreCfUl7iz9fxIrdgJPGgbey5ui9xu58cf1Tpy8dzn6qmcBFU/UjPZBwU= 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=qypGGpaw; arc=none smtp.client-ip=209.85.216.42 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="qypGGpaw" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-398b3d66515so1976049a91.0 for ; Mon, 31 Aug 2026 05:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788180968; x=1788785768; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=NN6UX8SgchFyO1BOoLm/UThaPGREDiDtTXvCKVHtJ0U=; b=qypGGpawEIKNDdIt66SKfdb7ynh+xX41s9RQvJ9W+8ICdoJ8gHF7gjt7Dc6SzjT3bS OZcC3kJ2hLGh8sHwy2cpniIQ61fD1fSpfIaAKL+v3cx9Zz6EMbrg4+xiJuF7Y6X59pZ8 Nm/VWNFbGmoN4kTwFXKafva0PXo0sdfHwJ4W+kHKR+NKaiuBV9KpeCWLnfQUBJttHskY +qyaCd0Z8IH3ZDJxBouhHYlymCBCafEpgOJfXyKbbBy3ZuEpyEaCaNl470dwzFyNr1el V8ZaBeMk153EeR0qZw1LvweEMRLqJAoYkiL5QVDjx2tlAN27swpNXpQi+fHukm0bzV4i eQiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788180968; x=1788785768; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=NN6UX8SgchFyO1BOoLm/UThaPGREDiDtTXvCKVHtJ0U=; b=TSSjZqqGfAwS273sL2NUGxoi6B8KvSiRsYoez+uzpFVgFAQf5C0JJERfl5DTJ0ylfO iLV4wI4DFe2ZKfB1e6ognXUyzbQWaHchGfHrZcr3I04S7R9xTDnsR+TZS4nD/5VKIUh1 CfdqUQ7/Dzv6IT5StNJI4611lwKXKxHxygrXZ8YmgJspEpytdOeaufbpr8qNyyhziZCy a8358pPlKZ9CDE9hqQMNuS7cq0BZhtlTvTNOLRNPcyGCJbRTD4OJSvdhfvU3DHQwUaye enYOlaRZzD/moqCLx96yEuwJLaJD0aJn8GxQ1WnKENU0pqw8ShIQ6mCHUR+LAjhqimdD hBrA== X-Forwarded-Encrypted: i=1; AKwUvBwVSMCrzbNfGFGvJRHs27SR86KLAXIKj5aLifQaLU2JPJxOgB74uJ0ilypJzx020Z9f7vloKFgnXgMQCdA=@vger.kernel.org X-Gm-Message-State: AFuF++mGqAhU66+p8eimXgzsJOWRgDvMiLnv9cdcVjcY5PLShyVAW8Qx H75a4nPPMTHmUPtBglgVttv9ksA+nim9cMhj0pJA7ofOS1gSFJ9vNxSq X-Gm-Gg: AYBFou3gSH6xya+T2S5awSo0QG8BtQ3vjn4F20NJSMpcyr6Ix7H8ESCcPqargoPBrsB kn3sd0SdDyFh83E6DuF4aj04UoJt4i6hJTg1YLyvuZw1ElcRgzTQRcfNbbqRfWyLwPcxSW+p/9h /XJXgC/BRN4ZI3hoBs0N/IFOAXqCOR2sC4ddhqPVUzpoF7os4fQcM0Ih1JwDs7OVEArJXQFoLNR LTKeOasMSHx3ffXjiHtt2Ov42I88alNKZ6B/uvJXTwCS9HGnLSU2SWyegVQGx6emQZCqUYCHZTc hjj4iXsFQMaSYcnzzOWa24oL9ekhNUBHZHT3LeYxLBJqf+xYJNrZ+gWqhF3oCui2HFwQ3+86iGG tZYmOJ7gV9U8BmSexy12Nu4hm9AKEhwmwxXr4FrbmqomByVHEjqbtCvCxC4Dlh+/P+VeI0J86vH DXw2vvD1RQWCiUlk308zuS9k3CIxJFDVWU2wDAbhqWUle79WUwi01wmcxe2SErEpfQEMFQ8NVs X-Received: by 2002:a17:90a:e7cf:b0:38f:dec8:f7e9 with SMTP id 98e67ed59e1d1-396d0fccec0mr37935649a91.12.1788180967550; Mon, 31 Aug 2026 05:56:07 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-396d776d0dcsm5645997a91.4.2026.08.31.05.56.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Aug 2026 05:56:07 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: tglx@kernel.org, luto@kernel.org, vincenzo.frascino@arm.com Cc: thomas.weissschuh@linutronix.de, linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com Subject: [PATCH 1/3] vdso/math64: Add and use __iter_div64_u64_rem() Date: Mon, 31 Aug 2026 20:55:55 +0800 Message-ID: <20260831125557.1490398-2-zhanxusheng@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260831125557.1490398-1-zhanxusheng@xiaomi.com> References: <20260831125557.1490398-1-zhanxusheng@xiaomi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The vDSO basetimes for CLOCK_MONOTONIC and CLOCK_BOOTTIME are kept in the scaled nanoseconds of tkr_mono, so normalising them means dividing by NSEC_PER_SEC << shift, which does not fit the u32 divisor of __iter_div_u64_rem(). update_vdso_time_data() therefore open-codes the iterative division twice. Turning the loops into a plain modulo is not an option either, as the vDSO has no 64-bit division helpers on 32-bit. Add __iter_div64_u64_rem(), the u64-divisor counterpart of __iter_div_u64_rem(), keeping the asm() barrier that stops the compiler turning the loop into a division, and use it for both. No functional change. Signed-off-by: Zhan Xusheng --- include/vdso/math64.h | 21 +++++++++++++++++++++ kernel/time/vsyscall.c | 17 ++++++----------- 2 files changed, 27 insertions(+), 11 deletions(-) diff --git a/include/vdso/math64.h b/include/vdso/math64.h index 22ae212f8b28..eb39d3411981 100644 --- a/include/vdso/math64.h +++ b/include/vdso/math64.h @@ -21,6 +21,27 @@ __iter_div_u64_rem(u64 dividend, u32 divisor, u64 *remai= nder) return ret; } =20 +static __always_inline u64 +__iter_div64_u64_rem(u64 dividend, u64 divisor, u64 *remainder) +{ + u64 ret =3D 0; + + while (dividend >=3D divisor) { + /* + * Prevent the compiler from optimising this loop into a + * modulo operation. + */ + asm("" : "+rm"(dividend)); + + dividend -=3D divisor; + ret++; + } + + *remainder =3D dividend; + + return ret; +} + #if defined(CONFIG_ARCH_SUPPORTS_INT128) && defined(__SIZEOF_INT128__) =20 #ifndef mul_u64_u32_add_u64_shr diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c index aa59919b8f2c..165ad9d7f154 100644 --- a/kernel/time/vsyscall.c +++ b/kernel/time/vsyscall.c @@ -30,21 +30,21 @@ static inline void update_vdso_time_data(struct vdso_ti= me_data *vdata, struct ti { struct vdso_clock *vc =3D vdata->clock_data; struct vdso_timestamp *vdso_ts; - u64 nsec, sec; + u64 nsec_per_sec, nsec, sec; =20 fill_clock_configuration(&vc[CS_HRES_COARSE], &tk->tkr_mono); fill_clock_configuration(&vc[CS_RAW], &tk->tkr_raw); =20 + /* One second in the scaled nanoseconds of tkr_mono */ + nsec_per_sec =3D (u64)NSEC_PER_SEC << tk->tkr_mono.shift; + /* CLOCK_MONOTONIC */ vdso_ts =3D &vc[CS_HRES_COARSE].basetime[CLOCK_MONOTONIC]; vdso_ts->sec =3D tk->xtime_sec + tk->wall_to_monotonic.tv_sec; =20 nsec =3D tk->tkr_mono.xtime_nsec; nsec +=3D ((u64)tk->wall_to_monotonic.tv_nsec << tk->tkr_mono.shift); - while (nsec >=3D (((u64)NSEC_PER_SEC) << tk->tkr_mono.shift)) { - nsec -=3D (((u64)NSEC_PER_SEC) << tk->tkr_mono.shift); - vdso_ts->sec++; - } + vdso_ts->sec +=3D __iter_div64_u64_rem(nsec, nsec_per_sec, &nsec); vdso_ts->nsec =3D nsec; =20 /* Copy MONOTONIC time for BOOTTIME */ @@ -55,12 +55,7 @@ static inline void update_vdso_time_data(struct vdso_tim= e_data *vdata, struct ti =20 /* CLOCK_BOOTTIME */ vdso_ts =3D &vc[CS_HRES_COARSE].basetime[CLOCK_BOOTTIME]; - vdso_ts->sec =3D sec; - - while (nsec >=3D (((u64)NSEC_PER_SEC) << tk->tkr_mono.shift)) { - nsec -=3D (((u64)NSEC_PER_SEC) << tk->tkr_mono.shift); - vdso_ts->sec++; - } + vdso_ts->sec =3D sec + __iter_div64_u64_rem(nsec, nsec_per_sec, &nsec); vdso_ts->nsec =3D nsec; =20 /* CLOCK_MONOTONIC_RAW */ --=20 2.43.0 From nobody Sat Sep 26 18:54:52 2026 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (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 D22D740A92E for ; Mon, 31 Aug 2026 12:56:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788180973; cv=none; b=bASiN6aewb2YsBnmYIhGaMqGGpqu6rQtpQvH+Kk9r9ZwNvj7oft+EKcs9BuWoUCtZB/Bv9DgZb8sLToyNO0AcQraeRjPWV67lN3TB5tRTFUgUORewj/Qd6TWgI4IKckQunAx7wWKWnvGt0L0u7l6617L2Tf1wICqBj8zPSJ2MZk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788180973; c=relaxed/simple; bh=vMk5Gst64mIB1v2cQOjLobgDxm5sx5Wt53K2CpdA30s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hQjtIoH9+f4PdPvUACnLSOeIX9k3+px+OsDq0HJuvOcIb7kT/Z2W9X4mFSLKMfh4uxezK8SWUWGyVrWddJNVbvhwca6Ib7wWYcRUeS8X75ityldOQaYOFHqeI7xvD+e3ZEokHthqnJl26bDikQFpY8fB3AWJ8Du2cZrm0cXKWnY= 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=PL375YkJ; arc=none smtp.client-ip=209.85.215.174 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="PL375YkJ" Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-ca12086c06eso2741559a12.0 for ; Mon, 31 Aug 2026 05:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788180971; x=1788785771; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=x0axMxz8oadXve+GEcfT74nt0vh3LGcycmiqTGP+1WU=; b=PL375YkJI1XWHPeo0jev7i0Tfh/Q7MKFXEEY417Yk2kN1VzVXhkEsFLoOjWdG301tB sAk5s/uY4sSkgjHdlEfNG5ir910t5HLF/3XNjbpikUE7YkJfMLVYP5wlI7dhod6NtNQI WnUZ3Epnb9KxhAIwKNz+ZiRoASkEBqkeMx0JkSUJw1oLbz3uoFsVSxlzT1M6BwASa8DW MYuouhe70Q26ZY+AAuizp1IEr7/xkC32p2k8Kx1tKAQjATBKpZOmfe33pOiiAMglwP23 7UmXzuEjpouw6Eq8D2QMIVS1cFCOAYr7kmoOrsz4cPV0nsIkDIbBsAeWoiybfn8td6/h GT8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788180971; x=1788785771; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=x0axMxz8oadXve+GEcfT74nt0vh3LGcycmiqTGP+1WU=; b=WwsrojYE0F7U02Uh/W152H01b5FMwMgPP1fFmzraPtFQ8cuzD67bUdehbrPLHD3bKG 92+IImNZKYhyGIi19bZFX/DdUf6Iaq0BWxNetYfY2RwV6ehdp8aWDcmaQH/ai6B5lWF1 R11MltngSwVuplhRH011Kwnk8tqFVEK6t0FFuPpRa+IIvPCEsNKdzb5fWx9igZvG2qYV iubDw0+E7sMjWx6zZgsENwqLULmAHKf6oR3NnDpF6ZK7BpifxLt8BL9NyMh0ERspx43G JMSizRoTnOHjagO7eqtvM9hO5pk8+7cAFjHvK74NAAGNu3JBML6oLc5bWrjNTnuRAVTc 6DLA== X-Forwarded-Encrypted: i=1; AKwUvBxwadCHnrY3L9h30MUVUnaz37N3VhrJ1w3tjY3OKEgyPPFAN9e8KACdLXfeaWVnk2azbbDY/+iUdp0gG7I=@vger.kernel.org X-Gm-Message-State: AFuF++nV2eXvbEC81ieFGHi1tT1bvYgYQWudNVKwQ4fXlPpkYuhwo3/g DFVMyc0Vzh1oHOOPMmvfZat/BVRQNRkQZK+IpnqF38ADqC6Y1fwwqpFq X-Gm-Gg: AYBFou3FAe7LBAdbNXV/M/p4P3H5BlHKR7u/8oXXHk8f3S4fGUQTY8VjUTVt/dW+CWA MzO650IEl5Rt12C+1PaHSjRfT2NmA46T9nT488E7MYbVHbnrd2+oxgNkTmkh7EsfHveYZnwGmOs udnqatHQSupUnciAjIIhXyjjRBwcS9+9duWFMgoUUF/11EnMmrv8S9nQ/eiOLRmtKqgl1Hg16pw +IQ7rFJfoP3A6mRqhjDdN0WEGNLkcTy9KQhRPKy5jg6rig9mmGIbplm57nxUszlJgY3xvK47EGw kS7pPh9KIOJeANlfcjCMbqHqKenAu1XFmnHMFL7rpUqVNNcmLYezKODAJrDAw0MwfI5f9XPYgEV gYUhF3duPHCFRwmTIvKSI43CnVUBs1OmRbI7bOqEuRUGrDrqyTRcLL2Em5nSUeoDEr0EIJZh4bh Xllngo042LVJpXDla6SeYaRUTAeINapL50ro91rJb3D0vgCSf/3Kap1vqfx6PBT9fv3MXELwFR X-Received: by 2002:a17:90b:4a90:b0:38d:b36e:9813 with SMTP id 98e67ed59e1d1-396d0f8e9f9mr38159479a91.11.1788180970839; Mon, 31 Aug 2026 05:56:10 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-396d776d0dcsm5645997a91.4.2026.08.31.05.56.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Aug 2026 05:56:10 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: tglx@kernel.org, luto@kernel.org, vincenzo.frascino@arm.com Cc: thomas.weissschuh@linutronix.de, linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com Subject: [PATCH 2/3] vdso/vsyscall: Keep the CLOCK_AUX base scaled Date: Mon, 31 Aug 2026 20:55:56 +0800 Message-ID: <20260831125557.1490398-3-zhanxusheng@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260831125557.1490398-1-zhanxusheng@xiaomi.com> References: <20260831125557.1490398-1-zhanxusheng@xiaomi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The vDSO basetime of a clock is stored in the scaled nanoseconds of tkr_mono, so that the reader can floor the base and the cycle delta together in vdso_calc_ns(). vdso_time_update_aux() instead shifts the base down to nanoseconds, adds the offset, and shifts it back up, which zeroes the fractional nanoseconds of xtime_nsec. The reader then floors the base and the delta separately: ktime_get_aux(): base + ((delta * mult + xtime_nsec) >> shift) vdso: base + (xtime_nsec >> shift) + ((delta * mult) >> shift) Since floor(a) + floor(b) <=3D floor(a + b), the vDSO reports 0 or 1 ns below the syscall for the same clock. clock_getres() reports 1 ns for auxiliary clocks, so that is the full advertised granularity. It is not a monotonicity problem: across an update the step is floor(a + d) - floor(a) - floor(d), which is 0 or 1, never negative. Add the offset in scaled nanoseconds as the other high resolution clocks do, and normalise with __iter_div64_u64_rem() so that the stored base stays below one second and the userspace fast-path does not iterate more in __iter_div_u64_rem(). monotonic_to_aux.tv_nsec is a normalised timespec64 fraction, so it stays below NSEC_PER_SEC even for a negative offset, and the sum stays below 2 * (NSEC_PER_SEC << shift). The largest shift clocks_calc_mult_shift() can pick is 32, which makes that 8.6e18 against a u64 limit of 1.8e19. Signed-off-by: Zhan Xusheng --- kernel/time/vsyscall.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c index 165ad9d7f154..ab3ef1e7d3c8 100644 --- a/kernel/time/vsyscall.c +++ b/kernel/time/vsyscall.c @@ -137,8 +137,8 @@ void vdso_time_update_aux(struct timekeeper *tk) struct vdso_time_data *vdata =3D vdso_k_time_data; struct vdso_timestamp *vdso_ts; struct vdso_clock *vc; + u64 nsec_per_sec, nsec; s32 clock_mode; - u64 nsec; =20 vc =3D &vdata->aux_clock_data[tk->id - TIMEKEEPER_AUX_FIRST]; vdso_ts =3D &vc->basetime[VDSO_BASE_AUX]; @@ -156,10 +156,11 @@ void vdso_time_update_aux(struct timekeeper *tk) =20 vdso_ts->sec =3D tk->xtime_sec + tk->monotonic_to_aux.tv_sec; =20 - nsec =3D tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift; - nsec +=3D tk->monotonic_to_aux.tv_nsec; - vdso_ts->sec +=3D __iter_div_u64_rem(nsec, NSEC_PER_SEC, &nsec); - nsec =3D nsec << tk->tkr_mono.shift; + nsec_per_sec =3D (u64)NSEC_PER_SEC << tk->tkr_mono.shift; + + nsec =3D tk->tkr_mono.xtime_nsec; + nsec +=3D (u64)tk->monotonic_to_aux.tv_nsec << tk->tkr_mono.shift; + vdso_ts->sec +=3D __iter_div64_u64_rem(nsec, nsec_per_sec, &nsec); vdso_ts->nsec =3D nsec; } =20 --=20 2.43.0 From nobody Sat Sep 26 18:54:52 2026 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (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 4F54D40F721 for ; Mon, 31 Aug 2026 12:56:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788180976; cv=none; b=HzZKd+jy/jOu4dribgU8Nw33eR0qQlg2m21THWdcwJ0u9rJuSniiY6wLhm+z0ENnI8nUcVpCrucZgvGu4/Qw7Lpf+R9dTrZUMJnsx9NNXlZfuK7U8ZMjeD5lD6ftpbobSlq37MSXrBptAK8CyVVQoahbjEnIX3PIu5vkyQNbSqk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788180976; c=relaxed/simple; bh=Gz7pvYkZxkfDOb3BqtG9/tccf8rcqr8M6u5ct3ddE8Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kG5bdCGD3D3XVlxKfuj6a/B8Ub2sPuVIY7aCmUUMSdIH2KN7yCtgB7hY69py6DXVVhjjXcRJvipc5D5tosfTq40Cerey98M/DzhYOfc8twhoBSgzEewNyu1gU/9uTUXnOrBbgkB1wllX/s+sqOC7nwmkKrfdb0IYm5ZfaxXfKak= 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=AKqXS0cy; arc=none smtp.client-ip=209.85.216.49 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="AKqXS0cy" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-38dc4553f62so4821027a91.0 for ; Mon, 31 Aug 2026 05:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788180974; x=1788785774; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=JU/mOXCgWiPXwkuQqSrTtqCfDr2fiWKeTyG73VGlOc0=; b=AKqXS0cy/W4tzTgmR1gI7Y5LH5pd5GfgG9D0d183/Jr268L+YBaH2SDIcR771kNe/4 n3oddSfnPrVJJl2Ko7FKccHfoudegzL7QVMwTOL1YfsG6WWylL6aPZwACZD28hJyOaiA AlwDMl9L8GN/HJWUxTJpSRQct589mW2yKaVZ+ykRZNbe78LfcbvpR1vprrPLc/AzOl4n lpFY7ApB2RMazcbNJ1qVeiJhwFxxwGzcPSAaZ6KGIwxbiOPqT4URUfPfy8EWD032KHrp MmlGUhftj1pmays1TWzjxqE+cgtsszzENkFU4udEgoSZudOvpd/FFBACGR4o3H2pZu6J zkoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788180974; x=1788785774; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=JU/mOXCgWiPXwkuQqSrTtqCfDr2fiWKeTyG73VGlOc0=; b=MPiQMoVtZG1MIRirUsZY3RBkRj1XxOdDhDL+IMQ7MBnvvurJPq6wyOjnQvWLL5KnrB ZJ5R9p9UIm9jupNm6647tby2iWoC+ngiNC0eIcWFhFWVo+HlP/Rz+tpGfR49/Wgeqzox 5fG9qDGP8tEoz2F7D+WLLaewC79Y2QbCk6nfTMVHekDcbJxOks+Q02RLnAq8W7qjS7Ek iAWbp/hzbYWxCMUI+9KIFibu7ebtywT40DBg2G0Mc6fohjdnzM0ivkNW1gHDAPG+BFu2 PFewSizw2gIWoc0I1ce4vZ27Hsgys0e+oV+WhAPOqe9dSPYPMe6JhhmHyr8bK0Kw7E1R M+UQ== X-Forwarded-Encrypted: i=1; AKwUvBxQRa2omwDFqwE6bG0Bx0ivXFpyHFiEdNi5i2HUiH+18apsqFHmVmLMiVHvyFmh2xX6m5zwPOHLrliUfsw=@vger.kernel.org X-Gm-Message-State: AFuF++ksmH/+66HENWQXLec6FBKpFZfmoNhs89/mIwnf7cAVYJVJaB4p oOeBCwattjFZZkX3WMwnlW6etXat8fGerFWJqWXLGF9XEtPGO/F6Y7UM X-Gm-Gg: AYBFou2FEKJedYml7gHX/c6qmm5PuHlSdBglO4MUDPdMh3GLWq5J9vzsmw0MV48DRD0 HWahnLmsfS11BydBbYkCjYZNpYRRedGOYhcpBLncvF1z/J4ZuOlNmdM5xY7AgzkogxNukz02REc YR6jvHDVU2OLZxtdE4zPVOt/QFBYRSsWlmDbIhqZzKMptGyRBr2V344wXqVAIWItFewbKvY4t5l 7myqJWKq4vEP7liL0hd4WOe4mBdwGinty5o9qebrJRKo3qlJlNxRhUWM/3WZYCyvKZJN78w8pia S68v5dPUlF1mXyOov9lNu2u2x8NRLxoteJcaX5JubqoEfWLiUzWe2Rdh7RWsdjSCMHp2AAN9e7g HgowCVi78uYJ0t7lzlza1ErHe7Dr6LNvUF/lwWqK7mcslkHE91LJpul5B+IDhYZiFI5JwxNpJjE ThJMRW3DuMYzgtZdhHUEEbKavoyLLmjbhVYtJ9iC0nVMUoqURVEuDervQO2YG34ClP9qanRlXIV N/I72m8PaU= X-Received: by 2002:a17:90b:3c48:b0:398:9bd4:d1a with SMTP id 98e67ed59e1d1-39907ed3bcdmr776019a91.25.1788180974327; Mon, 31 Aug 2026 05:56:14 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-396d776d0dcsm5645997a91.4.2026.08.31.05.56.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Aug 2026 05:56:13 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: tglx@kernel.org, luto@kernel.org, vincenzo.frascino@arm.com Cc: thomas.weissschuh@linutronix.de, linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com Subject: [PATCH 3/3] vdso/gettimeofday: Assert that the clock id fits the dispatch mask Date: Mon, 31 Aug 2026 20:55:57 +0800 Message-ID: <20260831125557.1490398-4-zhanxusheng@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260831125557.1490398-1-zhanxusheng@xiaomi.com> References: <20260831125557.1490398-1-zhanxusheng@xiaomi.com> 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="utf-8" Content-Transfer-Encoding: quoted-printable The clock id dispatch turns the id into a bit in a u32: if (!vdso_clockid_valid(clock)) return false; msk =3D 1U << clock; vdso_clockid_valid() admits everything up to CLOCK_AUX_LAST, which is 23, so the shift is in range. Nothing states the dependency though, and raising MAX_AUX_CLOCKS past 16 would take CLOCK_AUX_LAST to 32 or beyond and make the shift undefined. Assert it at both dispatch sites. The condition is on a parameter rather than a constant, so it relies on the compiler deriving the range from the vdso_clockid_valid() bail-out above it. gcc 13 and clang 18 both do: x86 vdso64 and vdso32 build clean, and raising MAX_AUX_CLOCKS to 17 fails the assert as intended. Suggested-by: Thomas Wei=C3=9Fschuh Signed-off-by: Zhan Xusheng Reviewed-by: Thomas Wei=C3=9Fschuh --- lib/vdso/gettimeofday.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c index f7a591aba59f..ef4dcc614489 100644 --- a/lib/vdso/gettimeofday.c +++ b/lib/vdso/gettimeofday.c @@ -285,6 +285,7 @@ __cvdso_clock_gettime_common(const struct vdso_time_dat= a *vd, clockid_t clock, * Convert the clockid to a bitmask and use it to check which * clocks are handled in the VDSO directly. */ + BUILD_BUG_ON(clock >=3D BITS_PER_TYPE(msk)); msk =3D 1U << clock; if (likely(msk & VDSO_HRES)) vc =3D &vc[CS_HRES_COARSE]; @@ -438,6 +439,7 @@ bool __cvdso_clock_getres_common(const struct vdso_time= _data *vd, clockid_t cloc * Convert the clockid to a bitmask and use it to check which * clocks are handled in the VDSO directly. */ + BUILD_BUG_ON(clock >=3D BITS_PER_TYPE(msk)); msk =3D 1U << clock; if (msk & (VDSO_HRES | VDSO_RAW)) { /* --=20 2.43.0