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

[David Laight <david.laight.linux@gmail.com>]

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