From: Alexey Dobriyan <adobriyan@gmail.com>
To: "Jörn Engel" <joern@purestorage.com>
Cc: linux-kernel@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
Spencer Baugh <spencer.baugh@purestorage.com>
Subject: Re: round_up integer underflow
Date: Fri, 24 Jul 2015 01:20:09 +0300 [thread overview]
Message-ID: <20150723222008.GA1743@p183.telecom.by> (raw)
In-Reply-To: <20150723181030.GC24876@Sligo.logfs.org>
On Thu, Jul 23, 2015 at 11:10:30AM -0700, Jörn Engel wrote:
> On Thu, Jul 23, 2015 at 11:02:55AM -0700, Jörn Engel wrote:
> > Spencer spotted something nasty in the round_up macro. We were
> > wondering why round_up() worked differently from ALIGN. The only real
> > difference between the two patterns is overflow behaviour. And both
> > version are buggy when used for signed integer types, round_up will
> > underflow on INT_MIN, ALIGN will overflow on INT_MAX. Since signed
> > integer under/overflows are undefined, we might have subtle bugs lurking
> > in the kernel.
> >
> > This example program produces a warning when compiling with gcc -O2 or
> > higher. Clang doesn't warn. Compiled code behaves correctly with both
> > compilers, but that is largely luck and the same compilers may create
> > wrong behaviour if the surrounding code changes.
> >
> > #include <limits.h>
> > #include <stdio.h>
> >
> > #define __round_mask(x, y) ((__typeof__(x))((y)-1))
> > #define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
> > #define round_down(x, y) ((x) & ~__round_mask(x, y))
> >
> > int main(void)
> > {
> > int i, r = 8;
> >
> > for (i = INT_MIN; i; i++) {
> > printf("%2x: %2x %2x\n", i, round_down(i, r), round_up(i, r));
> > }
> > return 0;
> > }
> >
> > I don't have a good answer yet. We could make round_up check for
> > negative numbers, but I would prefer unconditional code that optimizes
> > down to nothing. We could rewrite it in assembly, once for each
> > architecture.
> >
> > Does anyone have better ideas?
You can fix overflow issues but the ALIGN(INT_MAX, a) creating much
smaller value is probably a bug anyway. It should BUG_ON or something
(yes, I'm aware of recent memo).
> #define round_up(x, y) (__typeof__(x)(__round_up((unsigned __typeof__(x)(x)), (y))))
^^^^^^^^^^^^^^^^^^^
If only... :-(
> I.e. cast x to the matching unsigned type where overflows are
> well-defined, do the rounding, then cast the result back to the original
> type.
prev parent reply other threads:[~2015-07-23 22:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 18:02 round_up integer underflow Jörn Engel
2015-07-23 18:10 ` Jörn Engel
2015-07-23 22:20 ` Alexey Dobriyan [this message]
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=20150723222008.GA1743@p183.telecom.by \
--to=adobriyan@gmail.com \
--cc=joern@purestorage.com \
--cc=linux-kernel@vger.kernel.org \
--cc=spencer.baugh@purestorage.com \
--cc=yinghai@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 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.