netdev - Re: [PATCHv2] sctp: Fix port hash table size computation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160219164614.GB20372@hmsreliant.think-freely.org>
Date:	Fri, 19 Feb 2016 11:46:14 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	linux-sctp@...r.kernel.org, netdev@...r.kernel.org,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Vladislav Yasevich <vyasevich@...il.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCHv2] sctp: Fix port hash table size computation

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
> > rewite made it more clear, breaking it down into a few easy steps:
> > 
> > 1) compute a goal size order
> > 2) compute the target order for the largest table we want to support
> > 3) select the minimum of (1) and (2)
> > 4) allocated the largest table we can up to the size in (3)
> > 5) compute how many buckets the table we allocated in (4) supports
> > 
> > 
> > I'm happy to use your suggestion above if the consensus is that its more clear,
> > but it took me a bit to figure out what exactly the existing code was trying to
> > do (especially given the dual use of the order variable), so I thought some
> > additional clarity was called for.
> 
> No strong feelings. I only took a look in other places like
> net/dccp/proto.c for similar problem.
> 
Understood. Its clear that sctp lifted the code from dccp (or perhaps vice
versa).  Either way, looking at it, it appears dccp has the same problem that
sctp does in this area.

As you don't have strong feelings, if its all the same to Dave and Vlad, I'm
happy with the way this patch is laid out, and will move on to fix dccp in the
same manner.

Best
Neil

> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>