Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Shuah Khan <shuah@kernel.org>,
	Amit Daniel Kachhap <amit.kachhap@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 5/8] kselftest/arm64: mte: fix printf type warning about mask
Date: Fri, 16 Aug 2024 17:55:48 +0100	[thread overview]
Message-ID: <20240816175548.01b0c515@donnerap.manchester.arm.com> (raw)
In-Reply-To: <1afb487d-b5ba-499e-bae1-8579d7b3303c@sirena.org.uk>

On Fri, 16 Aug 2024 17:30:14 +0100
Mark Brown <broonie@kernel.org> wrote:

Hi Mark,

thanks for having a look!

> On Fri, Aug 16, 2024 at 04:32:48PM +0100, Andre Przywara wrote:
> > When masking the return value of a prctl, which is clearly an "int", we
> > use a uapi header provided mask, which is defined using an "UL" modifier,
> > so the whole expression is promoted to a long. This upsets the compiler's
> > printf type checker, because we use "%x" in the format string.
> > 
> > While we could simply upgrade this to a "%lx", it sounds wrong to
> > promote the "ret" variable, that is clearly an int.
> > Downcast the mask instead, to keep the type correct.  
> 
> This suggests that we've got some confusion with the UAPI, these flags
> need to go through a prctl() return so they shouldn't be unsigned
> long...  That said, it's UAPI so I'm not sure that's fixable.

My thoughts, exactly. Not sure if this mask is used on some larger types
somewhere else, but it's indeed moot since it's UAPI.

> > -	if ((ret & PR_MTE_TCF_MASK) == mask) {
> > +	if ((ret & (int)PR_MTE_TCF_MASK) == mask) {
> >  		ksft_test_result_pass("%s\n", name);
> >  	} else {
> >  		ksft_print_msg("Got %x, expected %x\n",
> > -			       (ret & PR_MTE_TCF_MASK), mask);
> > +			       (ret & (int)PR_MTE_TCF_MASK), mask);
> >  		ksft_test_result_fail("%s\n", name);  
> 
> TBH my inclination is that this is worse than letting the value be
> promoted, casts (particularly casts of constants) are just obviously
> suspect in a way that printf() formats aren't.

Fair enough, I wasn't sure about this either, and indeed this down-cast of
a constant smells dodgy. So shall I just use %lx, and rely on the
promotion (so the MASK being defined as UL), or cast "ret" to long?

Cheers,
Andre



  reply	other threads:[~2024-08-16 16:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16 15:32 [PATCH 0/8] kselftest/arm64: various compilation fixes Andre Przywara
2024-08-16 15:32 ` [PATCH 1/8] kselftest/arm64: signal: drop now redundant GNU_SOURCE definition Andre Przywara
2024-08-16 16:24   ` Mark Brown
2024-08-16 15:32 ` [PATCH 2/8] kselftest/arm64: hwcap: fix f8dp2 cpuinfo name Andre Przywara
2024-08-16 16:24   ` Mark Brown
2024-08-16 15:32 ` [PATCH 3/8] kselftest/arm64: mte: use proper SKIP syntax Andre Przywara
2024-08-16 16:25   ` Mark Brown
2024-08-16 15:32 ` [PATCH 4/8] kselftest/arm64: mte: use string literal for printf-style functions Andre Przywara
2024-08-16 16:26   ` Mark Brown
2024-08-16 15:32 ` [PATCH 5/8] kselftest/arm64: mte: fix printf type warning about mask Andre Przywara
2024-08-16 16:30   ` Mark Brown
2024-08-16 16:55     ` Andre Przywara [this message]
2024-08-16 17:07       ` Mark Brown
2024-08-16 15:32 ` [PATCH 6/8] kselftest/arm64: mte: fix printf type warnings about __u64 Andre Przywara
2024-08-16 16:31   ` Mark Brown
2024-08-16 15:32 ` [PATCH 7/8] kselftest/arm64: mte: fix printf type warnings about pointers Andre Przywara
2024-08-16 16:32   ` Mark Brown
2024-08-16 16:59     ` Andre Przywara
2024-08-16 17:12       ` Mark Brown
2024-08-16 15:32 ` [PATCH 8/8] kselftest/arm64: mte: fix printf type warnings about longs Andre Przywara
2024-08-16 16:33   ` Mark Brown
2024-10-17 17:59 ` (subset) [PATCH 0/8] kselftest/arm64: various compilation fixes Catalin Marinas

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=20240816175548.01b0c515@donnerap.manchester.arm.com \
    --to=andre.przywara@arm.com \
    --cc=amit.kachhap@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=will@kernel.org \
    /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