[PATCH v2] tracing: Make is_signed_type() compatible with sparse

[PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

Using a __bitwise type in a tracing __field() definition triggers four
sparse warnings in stage 4 of expanding the TRACE_EVENT() macro. These
warnings are triggered by the is_signed_type() macro implementation.
Fix this by using _Generic() in the is_signed_type() implementation
instead of an integer comparison.

An earlier attempt to fix this issue is available here:
https://lore.kernel.org/all/20220717151047.19220-1-bvanassche@acm.org/

Cc: Christoph Hellwig <hch@lst.de>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---

Changes compared to v1: removed #ifdef __CHECKER__.

 include/linux/compiler.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index cb2f6050bdf7..ba9c7e16802d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -326,7 +326,14 @@ static inline void *offset_to_ptr(const int *off)
  * Whether 'type' is a signed type or an unsigned type. Supports scalar types,
  * bool and also pointer types.
  */
-#define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_signed_type(type) _Generic((type)0,	\
+	signed char: true,			\
+	signed short: true,			\
+	signed int: true,			\
+	signed long: true,			\
+	signed long long: true,			\
+	char: ((char)-1 < (char)1),		\
+	default: false)
 #define is_unsigned_type(type) (!is_signed_type(type))
 
 /*

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 8/7/26 10:00 AM, Bart Van Assche wrote:
> Using a __bitwise type in a tracing __field() definition triggers four
> sparse warnings in stage 4 of expanding the TRACE_EVENT() macro. These
> warnings are triggered by the is_signed_type() macro implementation.
> Fix this by using _Generic() in the is_signed_type() implementation
> instead of an integer comparison.
> 
> An earlier attempt to fix this issue is available here:
> https://lore.kernel.org/all/20220717151047.19220-1-bvanassche@acm.org/
> 
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> 
> Changes compared to v1: removed #ifdef __CHECKER__.
> 
>   include/linux/compiler.h | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index cb2f6050bdf7..ba9c7e16802d 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -326,7 +326,14 @@ static inline void *offset_to_ptr(const int *off)
>    * Whether 'type' is a signed type or an unsigned type. Supports scalar types,
>    * bool and also pointer types.
>    */
> -#define is_signed_type(type) (((type)(-1)) < (__force type)1)
> +#define is_signed_type(type) _Generic((type)0,	\
> +	signed char: true,			\
> +	signed short: true,			\
> +	signed int: true,			\
> +	signed long: true,			\
> +	signed long long: true,			\
> +	char: ((char)-1 < (char)1),		\
> +	default: false)
>   #define is_unsigned_type(type) (!is_signed_type(type))
(replying to my own email)

Hi Steven,

This patch still applies on Linux kernel v7.3-r1c. Do you agree that
this patch is ready to be queued for the next merge window?

Thanks,

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Sun, 30 Aug 2026 17:20:37 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> This patch still applies on Linux kernel v7.3-r1c. Do you agree that
> this patch is ready to be queued for the next merge window?

Could you please Cc: linux-trace-kernel@vger.kernel.org

If it's not in patchwork, I don't see it ;-)

-- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[David Laight]

On Fri,  7 Aug 2026 10:00:56 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> Using a __bitwise type in a tracing __field() definition triggers four
> sparse warnings in stage 4 of expanding the TRACE_EVENT() macro. These
> warnings are triggered by the is_signed_type() macro implementation.
> Fix this by using _Generic() in the is_signed_type() implementation
> instead of an integer comparison.

Does adding __force to the LH cast remove the warning?
Is so that would be a much better fix.

David

> 
> An earlier attempt to fix this issue is available here:
> https://lore.kernel.org/all/20220717151047.19220-1-bvanassche@acm.org/
> 
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
> 
> Changes compared to v1: removed #ifdef __CHECKER__.
> 
>  include/linux/compiler.h | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index cb2f6050bdf7..ba9c7e16802d 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -326,7 +326,14 @@ static inline void *offset_to_ptr(const int *off)
>   * Whether 'type' is a signed type or an unsigned type. Supports scalar types,
>   * bool and also pointer types.
>   */
> -#define is_signed_type(type) (((type)(-1)) < (__force type)1)
> +#define is_signed_type(type) _Generic((type)0,	\
> +	signed char: true,			\
> +	signed short: true,			\
> +	signed int: true,			\
> +	signed long: true,			\
> +	signed long long: true,			\
> +	char: ((char)-1 < (char)1),		\
> +	default: false)
>  #define is_unsigned_type(type) (!is_signed_type(type))
>  
>  /*
> 

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 8/31/26 1:44 PM, David Laight wrote:
> On Fri,  7 Aug 2026 10:00:56 -0700
> Bart Van Assche <bvanassche@acm.org> wrote:
> 
>> Using a __bitwise type in a tracing __field() definition triggers four
>> sparse warnings in stage 4 of expanding the TRACE_EVENT() macro. These
>> warnings are triggered by the is_signed_type() macro implementation.
>> Fix this by using _Generic() in the is_signed_type() implementation
>> instead of an integer comparison.
> 
> Does adding __force to the LH cast remove the warning?
> Is so that would be a much better fix.
I have tried this, but unfortunately this doesn't suppress the sparse
complaints about the casts in the is_signed_type() implementation.

Thanks,

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[David Laight]

On Mon, 31 Aug 2026 14:19:10 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> On 8/31/26 1:44 PM, David Laight wrote:
> > On Fri,  7 Aug 2026 10:00:56 -0700
> > Bart Van Assche <bvanassche@acm.org> wrote:
> >   
> >> Using a __bitwise type in a tracing __field() definition triggers four
> >> sparse warnings in stage 4 of expanding the TRACE_EVENT() macro. These
> >> warnings are triggered by the is_signed_type() macro implementation.
> >> Fix this by using _Generic() in the is_signed_type() implementation
> >> instead of an integer comparison.  
> > 
> > Does adding __force to the LH cast remove the warning?
> > Is so that would be a much better fix.  
> I have tried this, but unfortunately this doesn't suppress the sparse
> complaints about the casts in the is_signed_type() implementation.

The _Generic() version just doesn't work.
You need to explicitly specify all the qualified types, so you need
'int', 'const int', 'volatile int', 'const volatile int' (etc).
And, IIRC, there is another qualified in the latest C version that
would need to be allowed for as well.

I suspect you need to change the TRACE_EVENT() calls to remove the
__bitwise marker.

David

> 
> Thanks,
> 
> Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/1/26 1:20 AM, David Laight wrote:
> I suspect you need to change the TRACE_EVENT() calls to remove the
> __bitwise marker.

How to remove the __bitwise marker? Removing the __bitwise marker is not
supported by sparse, isn't it?

How about the changes shown below (should be split into two patches)?

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index cb2f6050bdf7..54c99a25caa5 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -326,7 +326,14 @@ static inline void *offset_to_ptr(const int *off)
   * Whether 'type' is a signed type or an unsigned type. Supports 
scalar types,
   * bool and also pointer types.
   */
-#define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_signed_type(type) _Generic(((TYPEOF_UNQUAL(type))0),	\
+	signed char: true,			\
+	signed short: true,			\
+	signed int: true,			\
+	signed long: true,			\
+	signed long long: true,			\
+	char: ((char)-1 < (char)1),		\
+	default: false)
  #define is_unsigned_type(type) (!is_signed_type(type))

  /*
diff --git a/lib/tests/is_signed_type_kunit.c 
b/lib/tests/is_signed_type_kunit.c
index 88adbe813f3a..b72da7f6084f 100644
--- a/lib/tests/is_signed_type_kunit.c
+++ b/lib/tests/is_signed_type_kunit.c
@@ -22,6 +22,8 @@ static void is_signed_type_test(struct kunit *test)
  	KUNIT_EXPECT_EQ(test, is_signed_type(signed char), true);
  	KUNIT_EXPECT_EQ(test, is_signed_type(unsigned char), false);
  	KUNIT_EXPECT_EQ(test, is_signed_type(char), false);
+	KUNIT_EXPECT_EQ(test, is_signed_type(short), true);
+	KUNIT_EXPECT_EQ(test, is_signed_type(unsigned short), false);
  	KUNIT_EXPECT_EQ(test, is_signed_type(int), true);
  	KUNIT_EXPECT_EQ(test, is_signed_type(unsigned int), false);
  	KUNIT_EXPECT_EQ(test, is_signed_type(long), true);
@@ -32,6 +34,13 @@ static void is_signed_type_test(struct kunit *test)
  	KUNIT_EXPECT_EQ(test, is_signed_type(enum signed_enum), true);
  	KUNIT_EXPECT_EQ(test, is_signed_type(void *), false);
  	KUNIT_EXPECT_EQ(test, is_signed_type(const char *), false);
+	KUNIT_EXPECT_EQ(test, is_signed_type(int (*)(void)), false);
+
+	KUNIT_EXPECT_EQ(test, is_signed_type(const int), true);
+	KUNIT_EXPECT_EQ(test, is_signed_type(const unsigned int), false);
+
+	KUNIT_EXPECT_EQ(test, is_signed_type(volatile int), true);
+	KUNIT_EXPECT_EQ(test, is_signed_type(volatile unsigned int), false);
  }

  static struct kunit_case is_signed_type_test_cases[] = {

Thanks,

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Tue, 1 Sept 2026 at 11:05, Bart Van Assche <bvanassche@acm.org> wrote:
>
> How about the changes shown below (should be split into two patches)?

This really is too ugly.

I think we should fix this in sparse, not in the kernel.

There is no reason for "is this a signed type" to be that complicated,
and add that kind of nasty code in a header that is this fundamental
to the kernel and gets included in every single file that gets
compiled.

Basic rule: sparse should never make the kernel worse.

            Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/1/26 11:45 AM, Linus Torvalds wrote:
> I think we should fix this in sparse, not in the kernel.
> 
> There is no reason for "is this a signed type" to be that complicated,
> and add that kind of nasty code in a header that is this fundamental
> to the kernel and gets included in every single file that gets
> compiled.
> 
> Basic rule: sparse should never make the kernel worse.

Hi Linus,

Four years ago the following sparse change was proposed:

  static int restricted_value(struct expression *v, struct symbol *type)
  {
-       if (v->type == EXPR_CAST)
+       if (v->type == EXPR_CAST || v->type == EXPR_FORCE_CAST)
                 v = v->cast_expression;

Source: 
https://lore.kernel.org/all/CAHk-=wjQGnVfb4jehFR0XyZikdQvCZouE96xR_nnf5kqaM5qqQ@mail.gmail.com/

Is that change still considered the best fix for sparse? If so, who can
apply that change to the sparse code base?

Thanks,

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Tue, 1 Sept 2026 at 12:22, Bart Van Assche <bvanassche@acm.org> wrote:
>
> Four years ago the following sparse change was proposed:
>
>   static int restricted_value(struct expression *v, struct symbol *type)
>   {
> -       if (v->type == EXPR_CAST)
> +       if (v->type == EXPR_CAST || v->type == EXPR_FORCE_CAST)
>                  v = v->cast_expression;

Oh, that's why I've not seen that issue. Because I still have that
exact thing in my tree, and have had it forever:

commit 32eb1e2c4fa0ae77b72aeaff963d49c309ab867a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Oct 20 18:10:07 2022 -0700

    Allow both regular casts and forced casts for restricted values

    We probably should just just a single expression type for the two cases,
    and distinguish forced casts some other way, but that's a separate
    issue.

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

but I think I stopped pushing out my own tree long ago I started
rebasing things and others maintained sparse better.

> Is that change still considered the best fix for sparse? If so, who can
> apply that change to the sparse code base?

Well, I pushed out my own random branch to my tree, but my sparse tree
really is a horrible mess of rebased code. So it for example has been
rebased on top of Al's __VA_OPT__ code from earlier this year, and
then has my own random old local patches from four years ago on top of
that.

So no, that tree is *not* a good tree, but I pushed it out anyway
since that horribly ugly tree is at least somewhat relevant to this
discussion.

Does that tree at least work for you? Maybe we can convince somebody
who is a better maintainer than I clearly have ever been to make my
messy branch be something actually palatable...

            Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Tue, 1 Sept 2026 at 12:35, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Well, I pushed out my own random branch to my tree

Just to clarify:

   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git/

and to make it *really* clear: that branch really is garbage. I think
the individual commits are all well-intentioned, but I don't think
I've ever even run the test-suite on it.

I'm a bad bad person. I should feel bad. But I'm too lazy for even that.

            Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/1/26 12:35 PM, Linus Torvalds wrote:
> Does that tree at least work for you? Maybe we can convince somebody
> who is a better maintainer than I clearly have ever been to make my
> messy branch be something actually palatable...

Hi Linus,

With the master branch of your sparse tree
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git/)
sparse does not complain about the is_signed_type() implementation.
Please note that I have not tried to verify whether any false negatives
have been introduced by sparse commit 32eb1e2c4fa0 ("Allow both regular
casts and forced casts for restricted values").

This makes me wonder whether I should switch from the official sparse
tree (git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git) to
your tree?

Thanks,

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Tue, 1 Sept 2026 at 13:06, Bart Van Assche <bvanassche@acm.org> wrote:
>
> This makes me wonder whether I should switch from the official sparse
> tree (git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git) to
> your tree?

That's an option, but honestly, I don't know how good the state of
that tree is. And I'm not going to be a good maintainer of it.

If we really have lost sparse maintenance again, and nobody is willing
to step up, I can try to do a minimal job at it.

But I'll be honest: I think it's been exactly two decades since I
really worked on sparse, because I think I stopped Sept 2006, and Josh
Triplett took over, and then we've had Chris Li and Luc Van Oostenryck
doing maintenance.

So I'd treat it like I treat my microemacs "maintainance" - sporadic,
and probably with an LLM. Because I'm not really willing to put in a
lot of effort.

This is partly me fishing for some poor soul who actually *wants* to
maintain this. Because if somebody sees that "I'll use an LLM" as a
threat: that's exactly how it's meant.

But Bart, maybe you'd like a new hobby? Think of all the glory. People
stopping you in the streets, asking you whether you're the sparse
maintainer and asking for selfies.

You won't be a rock star or an astronaut (or a fireman, or a dinosaur,
or whatever you dreamt of being when you were a wee tyke), but it's
the closest us geeks will ever get.

             Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/1/26 1:24 PM, Linus Torvalds wrote:
> This is partly me fishing for some poor soul who actually *wants* to
> maintain this.
It is well known that the official repository for sparse is
git://git.kernel.org/pub/scm/devel/sparse/sparse.git so I think we
should keep that URL. Pushing changes to that repository requires a
kernel.org account. I lost my kernel.org PGP key about nine years ago so
I will have to create a new one and get it signed again. I will let you
know when my new PGP key has been signed and when Konstantin Ryabitsev
has reactivated my kernel.org account.

Thanks,

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

Hello Bart,

On Tue, Sep 01, 2026 at 03:46:45PM -0700, Bart Van Assche wrote:
> On 9/1/26 1:24 PM, Linus Torvalds wrote:
> > This is partly me fishing for some poor soul who actually *wants* to
> > maintain this.
> It is well known that the official repository for sparse is
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git so I think we
> should keep that URL. Pushing changes to that repository requires a
> kernel.org account. I lost my kernel.org PGP key about nine years ago so
> I will have to create a new one and get it signed again.

There is a certificate 8352E32F03C2DFEC with your name on it in
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/. I guess that's
the one you lost access to? There is another certificate
715C3D35C5CE1009 that is not in that keyring which has the email address
you're still using; or is it that one?

I guess we should delete 8352E32F03C2DFEC, and ideally Doug Ledford
should revert their signature on it? (There are two more weak signatures
by Christoph Hellwig and Martin K. Petersen that are probably not worth
handling.)

I recommend using an expiry date on your new key and joining
https://lore.kernel.org/all/lpcosse2026-keysigning@baylibre.com/ to get
signatures on it if you're in Prague for LPC and/or OSSummit.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[David Laight]

On Tue, 1 Sep 2026 11:05:18 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> On 9/1/26 1:20 AM, David Laight wrote:
> > I suspect you need to change the TRACE_EVENT() calls to remove the
> > __bitwise marker.  
> 
> How to remove the __bitwise marker? Removing the __bitwise marker is not
> supported by sparse, isn't it?

Wont (__force u32)u32_bitwise_var remove it - you just have to know the
type.

David
 

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/1/26 2:29 PM, David Laight wrote:
> On Tue, 1 Sep 2026 11:05:18 -0700
> Bart Van Assche <bvanassche@acm.org> wrote:
> 
>> On 9/1/26 1:20 AM, David Laight wrote:
>>> I suspect you need to change the TRACE_EVENT() calls to remove the
>>> __bitwise marker.
>>
>> How to remove the __bitwise marker? Removing the __bitwise marker is not
>> supported by sparse, isn't it?
> 
> Wont (__force u32)u32_bitwise_var remove it - you just have to know the
> type.

Yes, removing __bitwise is possible if the underlying type is known. In
the context of the is_signed_type() macro, the underlying type is not
passed as an argument to that macro.

The implementation in sparse of __type_unqual__ does not remove
__attribute__((bitwise)) as far as I know. __typeof_unqual__ only strips
C type qualifiers: const, volatile, restrict, and _Atomic.

The only generic way I know of to remove the __bitwise marker is by
using _Generic(). But that approach has been rejected by Linus.

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Tue, 1 Sept 2026 at 14:43, Bart Van Assche <bvanassche@acm.org> wrote:
>
> The only generic way I know of to remove the __bitwise marker is by
> using _Generic(). But that approach has been rejected by Linus.

Note that what I rejected was the "check for signedness using
_Generic()". I think that's both disgusting and fragile, because it
just lists a random number of types and then a "default: false".

IOW, that use of _Generic() is just *wrong*. It would perfectly
happily take a 'float', and say that it's not signed - no warnings
anywhere. Now, we don't have that in the kernel, but it's a random
example of why that complicated macro is garbage.

In contrast, the existing macro is *not* garbage. It just says "does
casting -1 end up being larger than casting 1". Admittedly it *should*
cast 0, but then compilers are unhappy about comparing unsigned values
against zero, so it's not great, but it's *simple*. It still gives
random results for 'bool', I guess, but is bool signed? I don't know,
I don't care. So at least it's simple and not clearly broken like the
_Generic() case is.

So I think the right thing to do is to make sparse happy with that
expression. _Generic() is *WRONG*.

This has absolutely nothing to do with "removing __bitwise". Because
__bitwise shouldn't be removed.

             Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Tue, 1 Sep 2026 14:56:01 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> In contrast, the existing macro is *not* garbage. It just says "does
> casting -1 end up being larger than casting 1". Admittedly it *should*
> cast 0, but then compilers are unhappy about comparing unsigned values

It originally did but was changed to 1 for exactly that reason [1].

> against zero, so it's not great, but it's *simple*. It still gives
> random results for 'bool', I guess, but is bool signed? I don't know,
> I don't care.

Yeah, it was originally used for the tracing format files so that
tooling can know how to display the raw values it parses. Also it is
used for the filtering logic to know how to compare to the raw values.

I see is_signed_type() has picked up some use cases outside of tracing,
so I'm not sure how much those other areas care about things like
"bool".

-- Steve


[1] d2802d0739dcc ("tracing: Compare to 1 instead of zero for is_signed_type()")

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[David Laight]

On Tue, 1 Sep 2026 19:25:23 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 1 Sep 2026 14:56:01 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > 
> > In contrast, the existing macro is *not* garbage. It just says "does
> > casting -1 end up being larger than casting 1". Admittedly it *should*
> > cast 0, but then compilers are unhappy about comparing unsigned values  
> 
> It originally did but was changed to 1 for exactly that reason [1].

FWIW I suspect the 1 doesn't need a cast.
And I think the warning for (unsigned_var < 0) is currently disabled
because of too many annoying false positives.
(Thinks... (x >= 0) and (x < 0) could be treated differently!)

> > against zero, so it's not great, but it's *simple*. It still gives
> > random results for 'bool', I guess, but is bool signed? I don't know,
> > I don't care.  
> 
> Yeah, it was originally used for the tracing format files so that
> tooling can know how to display the raw values it parses. Also it is
> used for the filtering logic to know how to compare to the raw values.

And, in this case, the value is __bitwise so the 'tooling' doesn't know
how to display/compare them and you get a compile error.
Doesn't seem wrong :-)

David
 
> 
> I see is_signed_type() has picked up some use cases outside of tracing,
> so I'm not sure how much those other areas care about things like
> "bool".
> 
> -- Steve
> 
> 
> [1] d2802d0739dcc ("tracing: Compare to 1 instead of zero for is_signed_type()")
> 

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Wed, 2 Sep 2026 09:24:37 +0100
David Laight <david.laight.linux@gmail.com> wrote:

> > Yeah, it was originally used for the tracing format files so that
> > tooling can know how to display the raw values it parses. Also it is
> > used for the filtering logic to know how to compare to the raw values.  
> 
> And, in this case, the value is __bitwise so the 'tooling' doesn't know
> how to display/compare them and you get a compile error.
> Doesn't seem wrong :-)

Where is __bitwise used for a trace event field? Or is this an issue for
one of the other users of is_signed_type()?

-- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[David Laight]

On Wed, 2 Sep 2026 09:36:44 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 2 Sep 2026 09:24:37 +0100
> David Laight <david.laight.linux@gmail.com> wrote:
> 
> > > Yeah, it was originally used for the tracing format files so that
> > > tooling can know how to display the raw values it parses. Also it is
> > > used for the filtering logic to know how to compare to the raw values.    
> > 
> > And, in this case, the value is __bitwise so the 'tooling' doesn't know
> > how to display/compare them and you get a compile error.
> > Doesn't seem wrong :-)  
> 
> Where is __bitwise used for a trace event field?

Not sure, it wasn't in any of the emails.

David

> Or is this an issue for
> one of the other users of is_signed_type()?
> 
> -- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/2/26 6:36 AM, Steven Rostedt wrote:
> On Wed, 2 Sep 2026 09:24:37 +0100
> David Laight <david.laight.linux@gmail.com> wrote:
> 
>>> Yeah, it was originally used for the tracing format files so that
>>> tooling can know how to display the raw values it parses. Also it is
>>> used for the filtering logic to know how to compare to the raw values.
>>
>> And, in this case, the value is __bitwise so the 'tooling' doesn't know
>> how to display/compare them and you get a compile error.
>> Doesn't seem wrong :-)
> 
> Where is __bitwise used for a trace event field? Or is this an issue for
> one of the other users of is_signed_type()?

An example is any code that traces blk_opf_t or enum req_op values 
(there are probably more examples):

$  git grep -nHE '__field.*(blk_opf_t|enum req_op)' include/trace
include/trace/events/f2fs.h:1185:		__field(enum req_op, op)
include/trace/events/f2fs.h:1186:		__field(blk_opf_t, op_flags)
include/trace/events/f2fs.h:1241:		__field(enum req_op,	op)
include/trace/events/f2fs.h:1242:		__field(blk_opf_t,	op_flags)
include/trace/events/jbd2.h:364:		__field(    blk_opf_t,  write_flags		)
include/trace/events/nilfs2.h:207:		    __field_struct(enum req_op, mode)

Thanks,

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Wed, 2 Sep 2026 09:31:41 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> $  git grep -nHE '__field.*(blk_opf_t|enum req_op)' include/trace
> include/trace/events/f2fs.h:1185:		__field(enum req_op, op)
> include/trace/events/f2fs.h:1186:		__field(blk_opf_t, op_flags)
> include/trace/events/f2fs.h:1241:		__field(enum req_op,	op)
> include/trace/events/f2fs.h:1242:		__field(blk_opf_t,	op_flags)
> include/trace/events/jbd2.h:364:		__field(    blk_opf_t,  write_flags		)
> include/trace/events/nilfs2.h:207:		    __field_struct(enum req_op, mode)

Perhaps these should be converted to normal types and assigned with
__force. There's no reason to have the value in the ring buffer be of a
__bitwise type.

-- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/2/26 9:39 AM, Steven Rostedt wrote:
> On Wed, 2 Sep 2026 09:31:41 -0700
> Bart Van Assche <bvanassche@acm.org> wrote:
> 
>> $  git grep -nHE '__field.*(blk_opf_t|enum req_op)' include/trace
>> include/trace/events/f2fs.h:1185:		__field(enum req_op, op)
>> include/trace/events/f2fs.h:1186:		__field(blk_opf_t, op_flags)
>> include/trace/events/f2fs.h:1241:		__field(enum req_op,	op)
>> include/trace/events/f2fs.h:1242:		__field(blk_opf_t,	op_flags)
>> include/trace/events/jbd2.h:364:		__field(    blk_opf_t,  write_flags		)
>> include/trace/events/nilfs2.h:207:		    __field_struct(enum req_op, mode)
> 
> Perhaps these should be converted to normal types and assigned with
> __force. There's no reason to have the value in the ring buffer be of a
> __bitwise type.

Yikes. Typecasts in general and __force casts in particular should be 
avoided whenever possible, isn't it?

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Wed, 2 Sep 2026 09:44:49 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> > Perhaps these should be converted to normal types and assigned with
> > __force. There's no reason to have the value in the ring buffer be of a
> > __bitwise type.  
> 
> Yikes. Typecasts in general and __force casts in particular should be 
> avoided whenever possible, isn't it?

It's recording a value into a ring buffer to be read by user space tooling
that is figuring out how to read it via the format files (the thing that
uses is_signed_type()).

What use does using __bitwise have with that?

If anything, using __bitwise in the field makes things much worse, as you
are finding out now.

-- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Wed, 2 Sept 2026 at 09:53, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> If anything, using __bitwise in the field makes things much worse, as you
> are finding out now.

Stop it. __bitwise makes absolutely nothing worse. It's the right
type. If you are recording a value with any type at all, the type
should either match the original, or the original type shouldn't
matter AT ALL.

The whole __field() macro very much ON PURPOSE takes a type. Christ -
it's literally the *point* of that macro. You want to assign a value
that comes from that type from the kernel - so it needs to match the
type you are tracing. Including __bitwise. Exactly like it needs to
match in sign and in size.

Are you suggesting throwing away the size of the type too? Or the sign?

If you are not suggesting that, then stop the idiocy of suiggesting
throwing out __bitwise. Because dammit, that is part of the type,
exactly like the size is, and exactly like the signedness.

And NONE of the issues have anything to do with the kernel.

I already NAK'ed the whole idiotic _Generic() macro garbage.

WE DO NOT MAKE THE KERNEL WORSE BECAUSE OF TOOLING BUGS, WHEN THE
TOOLING CAN BE FIXED.

Why are you people not getting it?

                   Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Wed, 2 Sep 2026 10:04:48 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, 2 Sept 2026 at 09:53, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > If anything, using __bitwise in the field makes things much worse, as you
> > are finding out now.  
> 
> Stop it. __bitwise makes absolutely nothing worse. It's the right
> type. If you are recording a value with any type at all, the type
> should either match the original, or the original type shouldn't
> matter AT ALL.

Relax. I was thinking this was more than for sparse, as I was confused by
David's comment of:

  And, in this case, the value is __bitwise so the 'tooling' doesn't know
  how to display/compare them and you get a compile error. Doesn't seem
  wrong :-)

And was under the impression there was something here that caused a
compiler error. If it's just a sparse bug, then I don't care about it
either.

-- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[David Laight]

On Wed, 2 Sep 2026 09:44:49 -0700
Bart Van Assche <bvanassche@acm.org> wrote:

> On 9/2/26 9:39 AM, Steven Rostedt wrote:
> > On Wed, 2 Sep 2026 09:31:41 -0700
> > Bart Van Assche <bvanassche@acm.org> wrote:
> >   
> >> $  git grep -nHE '__field.*(blk_opf_t|enum req_op)' include/trace
> >> include/trace/events/f2fs.h:1185:		__field(enum req_op, op)
> >> include/trace/events/f2fs.h:1186:		__field(blk_opf_t, op_flags)
> >> include/trace/events/f2fs.h:1241:		__field(enum req_op,	op)
> >> include/trace/events/f2fs.h:1242:		__field(blk_opf_t,	op_flags)
> >> include/trace/events/jbd2.h:364:		__field(    blk_opf_t,  write_flags		)
> >> include/trace/events/nilfs2.h:207:		    __field_struct(enum req_op, mode)  
> > 
> > Perhaps these should be converted to normal types and assigned with
> > __force. There's no reason to have the value in the ring buffer be of a
> > __bitwise type.  

There are already a shed load (or two) of __force casts in the defines
(further up the same file) that handle some of those fields.
They probably go away if the __field() used u32 and any casts added to
the TP_fast_assign() expansion instead.

> Yikes. Typecasts in general and __force casts in particular should be 
> avoided whenever possible, isn't it?

Anything __bitwise is pretty much going to need an __force cast before the
value can be actually used.
But the syntax should have been __force(type, value) so that the compiler
doesn't see a cast.

David
 
> 
> Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Wed, 2 Sep 2026 19:06:32 +0100
David Laight <david.laight.linux@gmail.com> wrote:

> On Wed, 2 Sep 2026 09:44:49 -0700
> Bart Van Assche <bvanassche@acm.org> wrote:
> 
> > On 9/2/26 9:39 AM, Steven Rostedt wrote:  
> > > On Wed, 2 Sep 2026 09:31:41 -0700
> > > Bart Van Assche <bvanassche@acm.org> wrote:
> > >     
> > >> $  git grep -nHE '__field.*(blk_opf_t|enum req_op)' include/trace
> > >> include/trace/events/f2fs.h:1185:		__field(enum req_op, op)
> > >> include/trace/events/f2fs.h:1186:		__field(blk_opf_t, op_flags)
> > >> include/trace/events/f2fs.h:1241:		__field(enum req_op,	op)
> > >> include/trace/events/f2fs.h:1242:		__field(blk_opf_t,	op_flags)
> > >> include/trace/events/jbd2.h:364:		__field(    blk_opf_t,  write_flags		)
> > >> include/trace/events/nilfs2.h:207:		    __field_struct(enum req_op, mode)    
> > > 
> > > Perhaps these should be converted to normal types and assigned with
> > > __force. There's no reason to have the value in the ring buffer be of a
> > > __bitwise type.    
> 
> There are already a shed load (or two) of __force casts in the defines
> (further up the same file) that handle some of those fields.
> They probably go away if the __field() used u32 and any casts added to
> the TP_fast_assign() expansion instead.
> 
> > Yikes. Typecasts in general and __force casts in particular should be 
> > avoided whenever possible, isn't it?  
> 
> Anything __bitwise is pretty much going to need an __force cast before the
> value can be actually used.
> But the syntax should have been __force(type, value) so that the compiler
> doesn't see a cast.

Linus has made it clear that this "fix" will not make any changes to the
kernel. Sparse simply needs to be updated to figure out that the existing
code is OK.

-- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[David Laight]

On Wed, 2 Sep 2026 14:21:07 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 2 Sep 2026 19:06:32 +0100
> David Laight <david.laight.linux@gmail.com> wrote:
> 
> > On Wed, 2 Sep 2026 09:44:49 -0700
> > Bart Van Assche <bvanassche@acm.org> wrote:
> >   
> > > On 9/2/26 9:39 AM, Steven Rostedt wrote:    
> > > > On Wed, 2 Sep 2026 09:31:41 -0700
> > > > Bart Van Assche <bvanassche@acm.org> wrote:
> > > >       
> > > >> $  git grep -nHE '__field.*(blk_opf_t|enum req_op)' include/trace
> > > >> include/trace/events/f2fs.h:1185:		__field(enum req_op, op)
> > > >> include/trace/events/f2fs.h:1186:		__field(blk_opf_t, op_flags)
> > > >> include/trace/events/f2fs.h:1241:		__field(enum req_op,	op)
> > > >> include/trace/events/f2fs.h:1242:		__field(blk_opf_t,	op_flags)
> > > >> include/trace/events/jbd2.h:364:		__field(    blk_opf_t,  write_flags		)
> > > >> include/trace/events/nilfs2.h:207:		    __field_struct(enum req_op, mode)      
> > > > 
> > > > Perhaps these should be converted to normal types and assigned with
> > > > __force. There's no reason to have the value in the ring buffer be of a
> > > > __bitwise type.      
> > 
> > There are already a shed load (or two) of __force casts in the defines
> > (further up the same file) that handle some of those fields.
> > They probably go away if the __field() used u32 and any casts added to
> > the TP_fast_assign() expansion instead.
> >   
> > > Yikes. Typecasts in general and __force casts in particular should be 
> > > avoided whenever possible, isn't it?    
> > 
> > Anything __bitwise is pretty much going to need an __force cast before the
> > value can be actually used.
> > But the syntax should have been __force(type, value) so that the compiler
> > doesn't see a cast.  
> 
> Linus has made it clear that this "fix" will not make any changes to the
> kernel. Sparse simply needs to be updated to figure out that the existing
> code is OK.

Actually it wouldn't really to any harm to nuke the __bitwise on those fields.
It seems to be an attempt to generate strongly typed integers, but it doesn't
stop you mixing up the values between the fields - there is only one kind
of __bitwise.
There are methods of ensuring that the correct constants are used for flag
variables - usually accessor functions that token-paste prefixes.

David 

> 
> -- Steve

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Bart Van Assche]

On 9/2/26 1:50 PM, David Laight wrote:
> It seems to be an attempt to generate strongly typed integers, but it doesn't
> stop you mixing up the values between the fields - there is only one kind
> of __bitwise.

That's wrong. Every __bitwise type is treated as a different type by
sparse. Otherwise e.g. __le32 and __be32 would be treated as the same
type by sparse.

$ git grep 'typedef.*__bitwise.*__[lb]e.*;' include
include/uapi/linux/types.h:typedef __u16 __bitwise __le16;
include/uapi/linux/types.h:typedef __u16 __bitwise __be16;
include/uapi/linux/types.h:typedef __u32 __bitwise __le32;
include/uapi/linux/types.h:typedef __u32 __bitwise __be32;
include/uapi/linux/types.h:typedef __u64 __bitwise __le64;
include/uapi/linux/types.h:typedef __u64 __bitwise __be64;

Bart.

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Wed, 2 Sept 2026 at 13:50, David Laight <david.laight.linux@gmail.com> wrote:
>
> Actually it wouldn't really to any harm to nuke the __bitwise on those fields.
> It seems to be an attempt to generate strongly typed integers, but it doesn't
> stop you mixing up the values between the fields - there is only one kind
> of __bitwise.

Nope - there are multipel __bitwise.

Each typedef creates a new type. Try this:

        typedef int __attribute__((bitwise)) a_t;
        typedef int __attribute__((bitwise)) b_t;

        static a_t a;
        static b_t b;

        void test(void)
        {
                a = b;
        }

and notice how it warns:

    t.c:9:19: warning: incorrect type in assignment (different base types)
    t.c:9:19:    expected restricted a_t static [signed] [toplevel] [usertype] a
    t.c:9:19:    got restricted b_t static [signed] [toplevel] [usertype] b

because the types of 'a' and 'b' are not the same.

               Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Linus Torvalds]

On Wed, 2 Sept 2026 at 09:38, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Perhaps these should be converted to normal types and assigned with
> __force. There's no reason to have the value in the ring buffer be of a
> __bitwise type.

Why?

Guys, the underlying type is __bitwise. The problem is _sparse_.

Why are you trying to fix the symptoms and make kernel code worse, for
a tool that has a bug and a fix for it?

Stop it.

             Linus

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Vincent Mailhol]

On 02/09/2026 at 01:25, Steven Rostedt wrote:
> On Tue, 1 Sep 2026 14:56:01 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>>
>> In contrast, the existing macro is *not* garbage. It just says "does
>> casting -1 end up being larger than casting 1". Admittedly it *should*
>> cast 0, but then compilers are unhappy about comparing unsigned values
> 
> It originally did but was changed to 1 for exactly that reason [1].

I removed gcc's -Wtype-limits in commit 660e899103e2 ("kbuild: remove
gcc's -Wtype-limits"). d2802d0739dcc can probably be reverted.

>> against zero, so it's not great, but it's *simple*. It still gives
>> random results for 'bool', I guess, but is bool signed? I don't know,
>> I don't care.
> 
> Yeah, it was originally used for the tracing format files so that
> tooling can know how to display the raw values it parses. Also it is
> used for the filtering logic to know how to compare to the raw values.
> 
> I see is_signed_type() has picked up some use cases outside of tracing,
> so I'm not sure how much those other areas care about things like
> "bool".
> 
> -- Steve
> 
> 
> [1] d2802d0739dcc ("tracing: Compare to 1 instead of zero for is_signed_type()")


Yours sincerely,
Vincent Mailhol

Re: [PATCH v2] tracing: Make is_signed_type() compatible with sparse

[Steven Rostedt]

On Thu, 3 Sep 2026 23:50:19 +0200
Vincent Mailhol <mailhol@kernel.org> wrote:

> I removed gcc's -Wtype-limits in commit 660e899103e2 ("kbuild: remove
> gcc's -Wtype-limits"). d2802d0739dcc can probably be reverted.

Commit d2802d0739dcc is 13 years old. I think we can keep it as is. I
hate to revert it and then something else complains about it (clang?),
and we have to add it back again.

-- Steve