public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	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>,
	linux-sparse@vger.kernel.org
Subject: Re: [PATCH 51/51] fs/zonefs: Fix sparse warnings in tracing code
Date: Sun, 26 Jun 2022 11:58:14 +0200	[thread overview]
Message-ID: <20220626095814.7wtma47w4sph7dha@mail> (raw)
In-Reply-To: <3eed7994-8de2-324d-c373-b6f4289a2734@acm.org>

On Sat, Jun 25, 2022 at 05:44:54PM -0700, Bart Van Assche wrote:
> On 6/25/22 02:23, Christoph Hellwig wrote:
> > On Fri, Jun 24, 2022 at 12:57:56PM -0700, Bart Van Assche wrote:
> > > BTW, I discovered the code in the tracing infrastructure
> > > that makes sparse unhappy:
> > > 
> > > #define is_signed_type(type) (((type)(-1)) < (type)1)
> > > 
> > > Sparse reports four warnings for that expression if 'type' is a bitwise
> > > type. Two of these warnings can be suppressed by changing 'type' into
> > > '__force type'. I have not yet found a way to suppress all the sparse
> > > warnings triggered by the is_signed_type() macro for bitwise types.

Yes, __bitwise is quite strict and only support the bitwise operations
(&, |, ^ and).
 
> > Yeah, that is a bit of a mess.  Rasmus, Steven - any good idea how
> > we can make the trace even macros fit for sparse?  Maybe just drop the
> > is_signed_type check for __CHECKER__ ?

I would strongly advise against this:
-) the macro is sued elsewhere too (for overflow checking)
-) sparse wouldn't check anymore the same code as the one seen by the
   compiler 

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)?

Implementing directly what's needed here, something like __is_signed_type()
would be possible too but is a bit too specialized and so much less useful.

-- Luc Van Oostenryck

  reply	other threads:[~2022-06-26  9:58 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23 18:04 [PATCH 00/51] Improve static type checking for request flags Bart Van Assche
2022-06-23 18:04 ` [PATCH 01/51] treewide: Rename enum req_opf into enum req_op Bart Van Assche
2022-06-23 18:04 ` [PATCH 02/51] block: Use enum req_op where appropriate Bart Van Assche
2022-06-23 18:04 ` [PATCH 03/51] block: Change the type of the last .rw_page() argument Bart Van Assche
2022-06-23 18:04 ` [PATCH 04/51] block: Change the type of req_op() and bio_op() into enum req_op Bart Van Assche
2022-06-23 18:04 ` [PATCH 05/51] block: Introduce the type blk_opf_t Bart Van Assche
2022-06-23 18:04 ` [PATCH 06/51] block: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:04 ` [PATCH 07/51] blktrace: " Bart Van Assche
2022-06-23 18:04 ` [PATCH 08/51] blktrace: Trace remap operations correctly Bart Van Assche
2022-06-23 18:04 ` [PATCH 09/51] block/brd: Use the enum req_op type Bart Van Assche
2022-06-23 18:04 ` [PATCH 10/51] block/drbd: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-24  5:00   ` Christoph Böhmwalder
2022-06-23 18:04 ` [PATCH 11/51] block/floppy: Fix a sparse warning Bart Van Assche
2022-06-23 18:04 ` [PATCH 12/51] block/null_blk: Fix sparse warnings in tracing code Bart Van Assche
2022-06-23 18:04 ` [PATCH 13/51] um: Use enum req_op where appropriate Bart Van Assche
2022-06-23 18:04 ` [PATCH 14/51] dm/core: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-23 18:04 ` [PATCH 15/51] dm/bufio: Change 'int rw' into 'enum req_op op' Bart Van Assche
2022-06-23 18:04 ` [PATCH 16/51] dm/kcopyd: Rename kcopyd_job.rw into kcopyd_job.op Bart Van Assche
2022-06-23 18:04 ` [PATCH 17/51] dm/ebs: Change 'int rw' into 'enum req_op op' Bart Van Assche
2022-06-23 18:04 ` [PATCH 18/51] dm/dm-flakey: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:04 ` [PATCH 19/51] dm/dm-integrity: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-23 18:04 ` [PATCH 20/51] dm/dm-snap: " Bart Van Assche
2022-06-23 18:04 ` [PATCH 21/51] dm/dm-zoned: Use the enum req_op type Bart Van Assche
2022-06-23 22:46   ` Damien Le Moal
2022-06-23 18:04 ` [PATCH 22/51] md/core: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-23 18:05 ` [PATCH 23/51] md/bcache: " Bart Van Assche
2022-06-23 18:05 ` [PATCH 24/51] md/raid1: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:05 ` [PATCH 25/51] md/raid10: " Bart Van Assche
2022-06-23 18:05 ` [PATCH 26/51] md/raid5: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-23 18:05 ` [PATCH 27/51] nvme/host: " Bart Van Assche
2022-06-26  9:25   ` Sagi Grimberg
2022-06-23 18:05 ` [PATCH 28/51] nvme/target: Use the new blk_opf_t type Bart Van Assche
2022-06-26  9:25   ` Sagi Grimberg
2022-06-23 18:05 ` [PATCH 29/51] scsi/core: Improve static type checking Bart Van Assche
2022-06-23 18:05 ` [PATCH 30/51] scsi/core: Change the return type of scsi_noretry_cmd() into bool Bart Van Assche
2022-06-23 18:05 ` [PATCH 31/51] scsi/core: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:05 ` [PATCH 32/51] scsi/device_handlers: " Bart Van Assche
2022-06-23 18:05 ` [PATCH 33/51] scsi/ufs: Rename a 'dir' argument into 'op' Bart Van Assche
2022-06-23 19:09   ` Avri Altman
2022-06-23 18:05 ` [PATCH 34/51] scsi/target: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:05 ` [PATCH 35/51] mm: " Bart Van Assche
2022-06-23 18:05 ` [PATCH 36/51] fs/buffer: " Bart Van Assche
2022-06-23 18:05 ` [PATCH 37/51] fs/direct-io: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-23 18:05 ` [PATCH 38/51] fs/mpage: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:05 ` [PATCH 39/51] fs/btrfs: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-23 18:05 ` [PATCH 40/51] fs/ext4: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:05 ` [PATCH 41/51] fs/f2fs: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-23 18:05 ` [PATCH 42/51] fs/gfs2: " Bart Van Assche
2022-06-23 18:05 ` [PATCH 43/51] fs/hfsplus: " Bart Van Assche
2022-06-23 18:05 ` [PATCH 44/51] fs/iomap: Use the new blk_opf_t type Bart Van Assche
2022-06-23 18:05 ` [PATCH 45/51] fs/jbd2: Fix the documentation of the jbd2_write_superblock() callers Bart Van Assche
2022-06-23 18:05 ` [PATCH 46/51] fs/nilfs: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-24  3:43   ` Ryusuke Konishi
2022-06-25  0:02     ` Bart Van Assche
2022-06-25  0:55       ` Ryusuke Konishi
2022-06-23 18:05 ` [PATCH 47/51] fs/ntfs3: Use enum req_op where appropriate Bart Van Assche
2022-06-23 18:05 ` [PATCH 48/51] fs/ocfs2: Use the enum req_op and blk_opf_t types Bart Van Assche
2022-06-24  2:04   ` Joseph Qi
2022-06-23 18:05 ` [PATCH 49/51] PM: " Bart Van Assche
2022-06-27 13:04   ` Rafael J. Wysocki
2022-06-23 18:05 ` [PATCH 50/51] fs/xfs: " Bart Van Assche
2022-06-25  3:23   ` Darrick J. Wong
2022-06-23 18:05 ` [PATCH 51/51] fs/zonefs: Fix sparse warnings in tracing code Bart Van Assche
2022-06-23 22:48   ` Damien Le Moal
2022-06-23 23:19     ` Bart Van Assche
2022-06-24  0:03       ` Damien Le Moal
2022-06-24  4:56   ` Christoph Hellwig
2022-06-24 19:57     ` Bart Van Assche
2022-06-25  9:23       ` Christoph Hellwig
2022-06-26  0:44         ` Bart Van Assche
2022-06-26  9:58           ` Luc Van Oostenryck [this message]
2022-06-26 15:42             ` Bart Van Assche
2022-06-26 16:24               ` Luc Van Oostenryck
2022-06-26 16:33             ` Linus Torvalds
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-26 19:41         ` Steven Rostedt
2022-06-24  5:05 ` [PATCH 00/51] Improve static type checking for request flags Christoph Hellwig
2022-06-24  5:07   ` Christoph Hellwig
2022-06-28 23:10     ` Bart Van Assche
2022-06-28 22:44   ` 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=20220626095814.7wtma47w4sph7dha@mail \
    --to=luc.vanoostenryck@gmail.com \
    --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=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