linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
	Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	linux-block <linux-block@vger.kernel.org>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Naohiro Aota <naohiro.aota@wdc.com>,
	Johannes Thumshirn <jth@kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sparse Mailing-list <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH 51/51] fs/zonefs: Fix sparse warnings in tracing code
Date: Sun, 26 Jun 2022 09:33:57 -0700	[thread overview]
Message-ID: <CAHk-=wj8gM8q04v2jS5JGjEdoE2d+B4_nm74xrFjZ77f9YRsbA@mail.gmail.com> (raw)
In-Reply-To: <20220626095814.7wtma47w4sph7dha@mail>

On Sun, Jun 26, 2022 at 2:58 AM Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> What about I would add to sparse something to strip away the bitwise/
> recover the underlying type? Something like __unbitwiseof() or
> __underlying_typeof() (some better name is needed)?

Please no, we don't want to make random macros have to have sparse
logic in them when it's not actually sparse-related.

I think it would be better if sparse just recognized some of these
kinds of situation. In particular:

 (a) for the casting part, I actually suspect we should drop the
warning about castign integers to restricted types.

Note that this is actually one of the main causes of "__force" use in
the kernel, with code like

        VM_FAULT_OOM            = (__force vm_fault_t)0x000001,
        VM_FAULT_SIGBUS         = (__force vm_fault_t)0x000002,
        VM_FAULT_MAJOR          = (__force vm_fault_t)0x000004,
        VM_FAULT_WRITE          = (__force vm_fault_t)0x000008,

and I think that we could/should just say that "explicit casts of
constants are ok".

That would remove two of the four warnings right there, and probably
make bitwise types more convenient in general.

We already treat "0" as special (because for bitwise things, zero is
kind of the universal constant), and we should continue to warn about
_implicit_ casts of restricted types, but I think the use of "__force"
in the kernel does show that the explicit casts are probably a bad
idea.

 (b) I think we could also recognize "comparison of constants" to be
something that doesn't necessarily require a warning.

And here in particular the "compare with zero" and "compare with all
bits set" - which is exactly that "-1" case.

In fact, there's a very good argument that "-1" is as special as zero
is ("all bits set" vs "all bits clear"), so for that (a) case, I think
at a _minimum_ we shouldn't warn about that particular constant.

So I think we could silence this sparse warning entirely, without
really introducing any new syntax, and actually improving on how
bitwise works.

                 Linus

  parent reply	other threads:[~2022-06-26 16:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220623180528.3595304-1-bvanassche@acm.org>
     [not found] ` <20220623180528.3595304-52-bvanassche@acm.org>
     [not found]   ` <20220624045613.GA4505@lst.de>
     [not found]     ` <aa044f61-46f0-5f21-9b17-a1bb1ff9c471@acm.org>
     [not found]       ` <20220625092349.GA23530@lst.de>
     [not found]         ` <3eed7994-8de2-324d-c373-b6f4289a2734@acm.org>
2022-06-26  9:58           ` [PATCH 51/51] fs/zonefs: Fix sparse warnings in tracing code Luc Van Oostenryck
2022-06-26 15:42             ` Bart Van Assche
2022-06-26 16:24               ` Luc Van Oostenryck
2022-06-26 16:33             ` Linus Torvalds [this message]
2022-06-26 16:50               ` Linus Torvalds
2022-06-26 20:10                 ` Luc Van Oostenryck
2022-06-26 19:44               ` Luc Van Oostenryck
2022-06-27 19:05               ` [PATCH 0/5] allow -1 and compares in bitwise types Luc Van Oostenryck
2022-06-27 19:05                 ` [PATCH 1/5] bitwise: add testcases Luc Van Oostenryck
2022-06-27 19:05                 ` [PATCH 2/5] bitwise: accept all ones as non-restricted value Luc Van Oostenryck
2022-06-27 23:32                   ` Ramsay Jones
2022-06-27 19:05                 ` [PATCH 3/5] bitwise: allow compares for bitwise types Luc Van Oostenryck
2022-06-27 19:20                   ` Linus Torvalds
2022-06-27 23:34                   ` Ramsay Jones
2022-06-27 19:05                 ` [PATCH 4/5] bitwise: do not remove the signedness of " Luc Van Oostenryck
2022-06-27 19:05                 ` [PATCH 5/5] bitwise: early expansion of simple constants Luc Van Oostenryck
2022-06-27 19:14                 ` [PATCH 0/5] allow -1 and compares in bitwise types Linus Torvalds
2022-06-27 19:15                 ` Bart Van Assche

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='CAHk-=wj8gM8q04v2jS5JGjEdoE2d+B4_nm74xrFjZ77f9YRsbA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=hch@lst.de \
    --cc=jth@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=naohiro.aota@wdc.com \
    --cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).