[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140116102618.GA7436@order.stressinduktion.org>
Date: Thu, 16 Jan 2014 11:26:18 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Daniel Borkmann <dborkman@...hat.com>, davem@...emloft.net,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Austin S Hemmelgarn <ahferroin7@...il.com>,
Jesse Gross <jesse@...ira.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Matt Mackall <mpm@...enic.com>,
Pekka Enberg <penberg@...nel.org>,
Christoph Lameter <cl@...ux-foundation.org>,
Andy Gospodarek <andy@...yhouse.net>,
Veaceslav Falico <vfalico@...hat.com>,
Jay Vosburgh <fubar@...ibm.com>,
Jakub Zawadzki <darkjames-ws@...kjames.pl>
Subject: Re: [PATCH net-next 2/2] reciprocal_divide: correction/update of the algorithm
Hi Eric!
On Wed, Jan 15, 2014 at 07:07:26PM -0800, Eric Dumazet wrote:
> On Thu, 2014-01-16 at 00:23 +0100, Daniel Borkmann wrote:
>
> > Also, reciprocal_value() and reciprocal_divide() always return 0
> > for divisions by 1. This is a bit worrisome as those functions
> > also get used in mm/slab.c and lib/flex_array.c, apparently for
> > index calculation to access array slots.
>
> Hi Daniel
>
> This off-by-one limitation is a known one,
> and mm/slab.c does not have an issue with it because :
>
> - Minimal object size is not 1 byte, but 8 (or maybe 4)
> - We always divide a multiple of the divisor,
> so there is no off-by-one effect.
>
> Little attached prog does a brute force check if needed.
>
> So far, the only relevant issue was about BPF, and a better
> documentation of reciprocal_divide() use cases.
>
> (I let Jesse comment on the flex_array case)
>
> I am unsure we want to 'fix' things, we tried hard in the past to avoid
> divides, so the ones we use are usually because the divisor is not
> constant, so the reciprocal doesn't help.
>
> (BPF is fixed in David tree)
>
> Thanks !
You are right, we rewrite that part. The text is still from the first commit
message where we did no full impact analysis. ;)
Thanks,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists