From: Neil Horman
Date: Thu, 18 Feb 2016 16:10:57 -0500
> Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
> its size computation, observing that the current method never guaranteed
> that the hashsize (measured in number of entries) would be a power of two,
> which the i
On Fri, Feb 19, 2016 at 03:41:09PM +0100, Eric Dumazet wrote:
> On ven., 2016-02-19 at 09:07 -0500, Neil Horman wrote:
>
> > I had actually thought about that, but to be frank I felt like the logic to
> > compute the hashsize was complex the way it was presented currently, and
> > that my
> > rew
On ven., 2016-02-19 at 09:07 -0500, Neil Horman wrote:
> I had actually thought about that, but to be frank I felt like the logic to
> compute the hashsize was complex the way it was presented currently, and that
> my
> rewite made it more clear, breaking it down into a few easy steps:
>
> 1) co
On Fri, Feb 19, 2016 at 11:28:50AM +0100, Eric Dumazet wrote:
> On jeu., 2016-02-18 at 16:10 -0500, Neil Horman wrote:
> > Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
> > its size computation, observing that the current method never guaranteed
> > that the hashsize (me
On jeu., 2016-02-18 at 16:10 -0500, Neil Horman wrote:
> Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
> its size computation, observing that the current method never guaranteed
> that the hashsize (measured in number of entries) would be a power of two,
> which the inpu
Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
its size computation, observing that the current method never guaranteed
that the hashsize (measured in number of entries) would be a power of two,
which the input hash function for that table requires. The root cause of
the
