linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	"'adilger.kernel@dilger.ca'" <adilger.kernel@dilger.ca>
Subject: Subject: [PATCH next] ext4: super: Use clamp() instead of clamp_val() to bound timestamps
Date: Wed, 17 Jan 2024 22:47:16 +0000	[thread overview]
Message-ID: <364a2f251cab4b2fbd43c661d51fcdd5@AcuMS.aculab.com> (raw)

Commit 6a0678a79bb3a extended the superblock timestamps to 40 bits.
The time64_t (signed 64bit) was bounded using:
	now = clamp_val(now, 0, (1ull << 40) - 1);
which is equivalent to:
	now = clamp(now, (typeof(now))0, (typeof(now))((1ull << 40) - 1));
However clamp_val() is an 'accident waiting to happen' because it
is very easy to specify bounds that get masked by the cast.
The current clamp() only requires the three values to have the same
signedness - not the same types.
So changing the upper limit to a signed value allows clamp() be used.

This is the only place in the kernel I build where replacing clamp_val()
with clamp() generates a compile-time error.

This is a similar 'problem' to code like:
	unsigned int val = ...
	u8 bounded = min_t(u8, val, 255);
which is surprisingly common and has been a real bug.

Signed-off-by: David Laight <david.laight@aculab.com>
---
 fs/ext4/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 0980845c8b8f..714d51a1667b 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -425,7 +425,7 @@ void ext4_itable_unused_set(struct super_block *sb,
 
 static void __ext4_update_tstamp(__le32 *lo, __u8 *hi, time64_t now)
 {
-	now = clamp_val(now, 0, (1ull << 40) - 1);
+	now = clamp(now, 0, (1ll << 40) - 1);
 
 	*lo = cpu_to_le32(lower_32_bits(now));
 	*hi = upper_32_bits(now);
-- 
2.17.1

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


                 reply	other threads:[~2024-01-17 22:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=364a2f251cab4b2fbd43c661d51fcdd5@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=arnd@arndb.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).