Linux Test Project
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: linuxtestproject.agent@gmail.com
Cc: ltp@lists.linux.it
Subject: Re: [LTP] tst_assert: Use 'long long' to fix 32bit compat mode truncation
Date: Fri, 25 Sep 2026 08:55:05 +0200	[thread overview]
Message-ID: <20260925065505.GB2387785@pevik> (raw)
In-Reply-To: <20260924132408.4225-1-linuxtestproject.agent@gmail.com>

Hi all,

> Hi Andrea,

> On Thu, 24 Sep 2026 13:25:12 +0200, Andrea Cervesato wrote:
> > [PATCH 1/3] tst_assert: Use 'long long' to fix 32bit compat mode truncation

> --- [PATCH 1/3] ---

> > @@ -25,16 +25,17 @@ void tst_assert_int(const char *file, const int lineno, const char *path, int va

> >  void tst_assert_ulong(const char *file, const int lineno, const char *path, unsigned long val)
> >  {
> > -	unsigned long sys_val;
> > +	unsigned long long sys_val;

> > -	safe_file_scanf(file, lineno, NULL, path, "%lu", &sys_val);
> > +	safe_file_scanf(file, lineno, NULL, path, "%llu", &sys_val);

> > -	if (val == sys_val) {
> > +	if (val == (unsigned long)sys_val) {
> >  		tst_res_(file, lineno, TPASS, "%s = %lu", path, val);
> >  		return;
> >  	}

> > -	tst_res_(file, lineno, TFAIL, "%s != %lu got %lu", path, val, sys_val);
> > +	tst_res_(file, lineno, TFAIL, "%s != %lu got %lu",
> > +		path, val, (unsigned long)sys_val);
> >  }

> Casting sys_val to (unsigned long) truncates values exceeding ULONG_MAX on
> 32-bit systems, causing false passes when (sys_val & 0xFFFFFFFF) == val and
> printing a truncated value on failure. Compare values without truncation
> using (unsigned long long)val == sys_val, and print sys_val with %llu on
> mismatch. Handling of 32-bit compat truncation for /proc/sys/kernel/shmall
> should be done in shmctl03.c instead of altering generic library assertions.

I wonder if it's safe to ignore this.

> --- [PATCH 2/3] ---

> > @@ -30,7 +30,14 @@ static void verify_ipcinfo(void)
> >  	else
> >  		tst_res(TPASS, "shmmin = 1");

> > -	TST_ASSERT_ULONG(PATH_KERN_SHMMAX, info.shmmax);
> > +	if (tst_is_compat_mode() && info.shmmax == INT_MAX) {
> > +		unsigned long long shmmax;
> > +		SAFE_FILE_SCANF(PATH_KERN_SHMMAX, "%llu", &shmmax);
> > +		TST_EXP_LE_LU(INT_MAX, shmmax);
> > +	} else {
> > +		TST_ASSERT_ULONG(PATH_KERN_SHMMAX, info.shmmax);
> > +	}
> > +

> Branching on info.shmmax == INT_MAX conditions on the result of the syscall
> under test, and TST_EXP_LE_LU(INT_MAX, shmmax) only asserts that the sysctl
> file is >= INT_MAX rather than verifying that info.shmmax was clamped.

I wonder if it's really important to verify it was clamped.

> Read PATH_KERN_SHMMAX into shmmax first, and if in compat mode with
> shmmax >= INT_MAX, assert TST_EXP_EQ_LU(info.shmmax, (unsigned long)INT_MAX);
> otherwise assert info.shmmax == shmmax.

OK, reading it twice is not optimal.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-09-25  6:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 11:25 [LTP] [PATCH v2 0/3] shmctl03: Fix shmmax clamped to INT_MAX in 32bit compat mode Petr Vorel
2026-09-24 11:25 ` [LTP] [PATCH v2 1/3] tst_assert: Use 'long long' to fix 32bit compat mode truncation Petr Vorel
2026-09-24 13:24   ` [LTP] " linuxtestproject.agent
2026-09-25  6:55     ` Petr Vorel [this message]
2026-09-25  8:01     ` [LTP] [RFC] " Petr Vorel
2026-09-24 11:25 ` [LTP] [PATCH v2 2/3] shmctl03: Fix shmmax clamped to INT_MAX in 32bit compat mode Petr Vorel
2026-09-24 11:25 ` [LTP] [PATCH v2 3/3] shmctl03: Use safe_shmctl(), TST_EXP_LE_LU() Petr Vorel
2026-09-25  6:49   ` Petr Vorel
  -- strict thread matches above, loose matches on Subject: below --
2026-09-18 12:50 [LTP] [PATCH 1/2] tst_assert: Use 'long long' to fix 32bit compat mode truncation Petr Vorel
2026-09-18 17:06 ` [LTP] " linuxtestproject.agent
2026-09-22  7:35   ` Petr Vorel

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=20260925065505.GB2387785@pevik \
    --to=pvorel@suse.cz \
    --cc=linuxtestproject.agent@gmail.com \
    --cc=ltp@lists.linux.it \
    /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