All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [for-linus][PATCH 01/10] tracing: Suppress sparse warnings triggered by is_signed_type()
Date: Thu, 25 Aug 2022 11:17:49 -0700	[thread overview]
Message-ID: <202208251117.F93103A00@keescook> (raw)
In-Reply-To: <7bc72b9d-79b0-5b8c-18c4-4a5c914efdc5@acm.org>

On Thu, Aug 25, 2022 at 10:39:02AM -0700, Bart Van Assche wrote:
> On 8/24/22 17:40, Linus Torvalds wrote:
> > Actually, thinking about it, that was simple enough.
> > 
> >    -#define is_signed_type(type)   (((type)(-1)) < (type)1)
> >    +#define is_signed_type(type)   (((type)(-1)) < (__force type)1)
> > 
> > should work.
> > 
> > It looks a bit odd, because we only force one side.
> > 
> > But we only need to force one side, because the '-1' doesn't have any
> > issues with bitwise types, the same way 0 doesn't.
> > 
> > So only '1' needs to be force-cast to avoid a warning about casting an
> > integer to a bitwise type.
> > 
> > And since that -1 counts as an unrestricted value after a cast, now
> > the ordered comparison doesn't warn either.
> > 
> > Now, admittedly I think sparse should also allow a forced cast of an
> > unrestricted value to be unrestricted, so I think I should do this
> > 
> >   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;
> > 
> > in sparse, but even without that the above "is_signed_type()" macro
> > should make sparse happy (with that current tree of mine).
> > 
> > And since we don't now need to cast 0, gcc won't complain about that
> > NULL pointer comparison.
> > 
> > Does that solve things for you?
> 
> Yes, thank you! No sparse warnings are triggered by the is_signed_type()
> macro and the gcc warning about ordered comparison of a pointer with the
> null pointer is gone.
> 
> The patch I came up with is available below. If nobody picks it up from
> this email I will try to find an appropriate kernel maintainer to send
> this kernel patch to.
> 
> Thanks,
> 
> Bart.
> 
> 
> From: Bart Van Assche <bvanassche@acm.org>
> Date: Tue, 23 Aug 2022 12:59:25 -0700
> Subject: [PATCH] tracing: Define the is_signed_type() macro once
> 
> There are two definitions of the is_signed_type() macro: one in
> <linux/overflow.h> and a second definition in <linux/trace_events.h>.
> 
> As suggested by Linus Torvalds, move the definition of the
> is_signed_type() macro into the <linux/compiler.h> header file. Change
> the definition of the is_signed_type() macro to make sure that it does
> not trigger any sparse warnings with future versions of sparse for
> bitwise types. See also:
> https://lore.kernel.org/all/CAHk-=whjH6p+qzwUdx5SOVVHjS3WvzJQr6mDUwhEyTf6pJWzaQ@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wjQGnVfb4jehFR0XyZikdQvCZouE96xR_nnf5kqaM5qqQ@mail.gmail.com/
> 
> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>

Looks good to me; thanks!

Acked-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

  reply	other threads:[~2022-08-25 18:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-21  0:07 [for-linus][PATCH 00/10] tracing: Fixes for 6.0 Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 01/10] tracing: Suppress sparse warnings triggered by is_signed_type() Steven Rostedt
2022-08-21 18:35   ` Linus Torvalds
2022-08-21 19:55     ` Steven Rostedt
2022-08-22 18:20     ` Bart Van Assche
2022-08-22 18:45       ` Linus Torvalds
2022-08-22 20:19         ` Bart Van Assche
2022-08-23  7:06         ` Rasmus Villemoes
2022-08-23 22:05           ` Bart Van Assche
2022-08-23 23:18             ` Linus Torvalds
2022-08-23 23:57               ` Linus Torvalds
2022-08-24  2:09                 ` Al Viro
2022-08-24  2:16                   ` Linus Torvalds
2022-08-24  3:10                   ` Al Viro
2022-08-24  3:20                     ` Al Viro
2022-08-24  5:56                     ` Linus Torvalds
2022-08-24  0:09               ` Bart Van Assche
2022-08-24  1:49                 ` Linus Torvalds
2022-08-24  2:11                   ` Linus Torvalds
2022-08-24  3:47                     ` Bart Van Assche
2022-08-24  3:46                   ` Bart Van Assche
2022-08-24 23:28                   ` Bart Van Assche
2022-08-25  0:30                     ` Linus Torvalds
2022-08-25  0:40                       ` Linus Torvalds
2022-08-25  7:57                         ` Rasmus Villemoes
2022-08-25  8:07                           ` Linus Torvalds
2022-08-25 17:39                         ` Bart Van Assche
2022-08-25 18:17                           ` Kees Cook [this message]
2022-08-21  0:07 ` [for-linus][PATCH 02/10] tracing: React to error return from traceprobe_parse_event_name() Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 03/10] tracing/perf: Fix double put of trace event when init fails Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 04/10] ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 05/10] tracing/eprobes: Do not allow eprobes to use $stack, or % for regs Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 06/10] tracing/eprobes: Do not hardcode $comm as a string Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 07/10] tracing/eprobes: Fix reading of string fields Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 08/10] tracing/eprobes: Have event probes be consistent with kprobes and uprobes Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 09/10] tracing/probes: Have kprobes and uprobes use $COMM too Steven Rostedt
2022-08-21  0:07 ` [for-linus][PATCH 10/10] tracing: Have filter accept "common_cpu" to be consistent Steven Rostedt

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=202208251117.F93103A00@keescook \
    --to=keescook@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.