netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
	netdev@vger.kernel.org, Eric Dumazet <eric.dumazet@gmail.com>,
	Dave Taht <dave.taht@gmail.com>
Subject: Re: [net-next PATCH] net: codel: Avoid undefined behavior from signed overflow
Date: Wed, 30 Oct 2013 21:55:36 -0700	[thread overview]
Message-ID: <20131031045536.GS4126@linux.vnet.ibm.com> (raw)
In-Reply-To: <1383164352.1601.38.camel@bwh-desktop.uk.level5networks.com>

On Wed, Oct 30, 2013 at 08:19:12PM +0000, Ben Hutchings wrote:
> On Wed, 2013-10-30 at 13:13 -0700, Paul E. McKenney wrote:
> > On Wed, Oct 30, 2013 at 07:35:48PM +0000, Ben Hutchings wrote:
> > > On Wed, 2013-10-30 at 18:23 +0100, Jesper Dangaard Brouer wrote:
> > > > From: Jesper Dangaard Brouer <netoptimizer@brouer.com>
> > > > 
> > > > As described in commit 5a581b367 (jiffies: Avoid undefined
> > > > behavior from signed overflow), according to the C standard
> > > > 3.4.3p3, overflow of a signed integer results in undefined
> > > > behavior.
> > > [...]
> > > 
> > > According to the real processors that Linux runs on, signed arithmetic
> > > uses 2's complement representation and overflow wraps accordingly.  And
> > > we rely on that behaviour in many places, so we use
> > > '-fno-strict-overflow' to tell gcc not to assume we avoid signed
> > > overflow.  (There is also '-fwrapv' which tells gcc to assume the
> > > processor behaves this way, but shouldn't it already know how the target
> > > machine works?)
> > 
> > We should still fix them as we come across them.  There are a few types
> > of loops where '-fno-strict-overflow' results in more instructions
> > being generated.
> 
> I realise there's an opportunity for optimisation, but if these cases
> are fixed on an ad-hoc basis, how will we know we're ready to make the
> switch?

I believe that there are some tools that check for code that relies on
signed integer overflow.  Probably not yet up to dealing with the
kernel.  In the meantime, fixing them as we come across them is not
a bad approach.

							Thanx, Paul

  reply	other threads:[~2013-10-31  4:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-30 17:23 [net-next PATCH] net: codel: Avoid undefined behavior from signed overflow Jesper Dangaard Brouer
2013-10-30 18:01 ` Eric Dumazet
2013-10-31 14:15   ` Jesper Dangaard Brouer
2013-10-31 15:10     ` Eric Dumazet
2013-10-31 20:40       ` Jesper Dangaard Brouer
2013-10-30 19:35 ` Ben Hutchings
2013-10-30 20:13   ` Paul E. McKenney
2013-10-30 20:19     ` Ben Hutchings
2013-10-31  4:55       ` Paul E. McKenney [this message]
2013-10-31 21:53   ` Jesper Dangaard Brouer

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=20131031045536.GS4126@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=bhutchings@solarflare.com \
    --cc=brouer@redhat.com \
    --cc=dave.taht@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@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 NNTP newsgroup(s).