From: Dan Carpenter <dan.carpenter@linaro.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-sparse@vger.kernel.org, linux-xfs@vger.kernel.org,
smatch@vger.kernel.org
Subject: Re: sparse feature request: nocast integer types
Date: Mon, 27 Nov 2023 15:51:05 +0300 [thread overview]
Message-ID: <3423b42d-fc11-4695-89cc-f1e2d625fa90@suswa.mountain> (raw)
In-Reply-To: <ZUxoJh7NlWw+uBlt@infradead.org>
On Wed, Nov 08, 2023 at 09:03:34PM -0800, Christoph Hellwig wrote:
> Hi dear spearse developers,
>
> in a lot of kernel code we have integer types that store offsets and
> length in certain units (typically 512 byte disk "sectors", file systems
> block sizes, and some weird variations of the same), and we had a fair
> amount of bugs beause people get confused about which ones to use.
>
> I wonder if it is possible to add an attribute (say nocast) that works
> similar to __attribute__((bitwise)) in that it disallows mixing this
> type with other integer types, but unlike __attribute__((bitwise))
> allows all the normal arithmetics on it? That way we could annotate
> all the normal conversion helpers with __force overrides and check
> where people are otherwise mixing these types.
I started writing something like this in Smatch for tying variables to
a specific unit.
https://github.com/error27/smatch/blob/master/smatch_units.c
But unfortunately, it doesn't actually work. The problem is that once
I said x is a byte, then if you have y = x then I would store that in
the database. If the first "x is a byte" assessment was wrong then the
misinformation gets amplified times 100 and can't be purged without
a mass delete.
The second problem is that Smatch automatically determines that a struct
foo->bar is a byte unit or whatever. Which generally works, but
sometimes fails catastrophically. For example, it's not true to
all the registers are used to store byte units. But some code does
store bytes there and now Smatch thinks the everything stored in
registers is in bytes.
My plan was to go through the false positives and manually edit out
stuff like this. The problem is that it's a lot of work and I haven't
done it. I did a similar thing for tracking user data and that works
pretty decently these days. So it's doable.
I tend to avoid manual annotations, but here it could be good. Manually
annotating things would avoid the false positives (at the expense of
missing bugs).
I'd prefer an annotation that had the type of the unit built in.
Creating an annotation like that is difficult because you have to
coordinate with GCC and Clang etc. In the mean time, I could just
create a table in smatch which has stuff like:
{ "(struct foo)->member", &byte_units },
regards,
dan carpenter
next prev parent reply other threads:[~2023-11-27 12:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 5:03 sparse feature request: nocast integer types Christoph Hellwig
[not found] ` <CAMHZB6G_TZJ_uQGm5an0-bhG8wCxpEQrUCShen7O61Q9arAf+Q@mail.gmail.com>
2023-11-09 5:30 ` Christoph Hellwig
[not found] ` <CAMHZB6H7Y0m2Y-ZD0PMKiGDeo7_sy=scDrzbBbBuUJfuzLK-Lg@mail.gmail.com>
2023-11-09 5:44 ` Christoph Hellwig
2023-11-09 17:57 ` Linus Torvalds
2023-11-27 12:51 ` Dan Carpenter [this message]
2023-11-27 16:05 ` Christoph Hellwig
2023-11-27 17:26 ` Linus Torvalds
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=3423b42d-fc11-4695-89cc-f1e2d625fa90@suswa.mountain \
--to=dan.carpenter@linaro.org \
--cc=hch@infradead.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=smatch@vger.kernel.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 read-only IMAP folder(s) and NNTP newsgroup(s).