netdev - RE: [PATCH] soreuseport: use "unsigned int" in __reuseport

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] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6DCFFC6C06@AcuExch.aculab.com>
Date:   Wed, 5 Apr 2017 15:28:20 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Alexey Dobriyan' <adobriyan@...il.com>,
        Craig Gallek <kraigatgoog@...il.com>
CC:     David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: RE: [PATCH] soreuseport: use "unsigned int" in __reuseport_alloc()

From: Alexey Dobriyan
> Sent: 04 April 2017 12:36
> On Mon, Apr 3, 2017 at 4:56 PM, Craig Gallek <kraigatgoog@...il.com> wrote:
> > On Sun, Apr 2, 2017 at 6:18 PM, Alexey Dobriyan <adobriyan@...il.com> wrote:
> >> Number of sockets is limited by 16-bit, so 64-bit allocation will never
> >> happen.
> >>
> >> 16-bit ops are the worst code density-wise on x86_64 because of
> >> additional prefix (66).
> > So this boils down to a compiled code density vs a
> > readability/maintainability argument?  I'm not familiar with the 16
> > bit problem you're referring to, but I'd argue that using the
> > self-documenting u16 as an input parameter to define the range
> > expectations is more useful that the micro optimization that this
> > change may buy you in the assembly of one platform.  Especially given
> > that this is a rare-use function.
> 
> It's not a problem as in "create trouble".
> 16-bit operations are the worst on x86_64: they require additional prefix,
> compiler often has to extend it to 32-bit to do anything useful
> (MOVZX = 1 cycle, 3 bytes) because of cast-everything-to-int
> behaviour enabled by the language.

It is worse for almost everything except x86.
Do arithmetic on anything smaller than an 'int' and the compiler
has to generate instructions to mask the result to the smaller size.
On x86 is can often use the 'as if' rule to update only %al (etc).

You really, really don't want to use 'char' or 'short' for local
variables, function arguments or function results.
(If you care about code size or execution time.)

	David