linux-kernel - RE: First kernel patch (optimization)

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: <063D6719AE5E284EB5DD2968C1650D6D1CB97D13@AcuExch.aculab.com>
Date:	Wed, 16 Sep 2015 12:56:19 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Austin S Hemmelgarn' <ahferroin7@...il.com>,
	Steve Calfee <stevecalfee@...il.com>,
	Eric Curtin <ericcurtin17@...il.com>
CC:	Valentina Manea <valentina.manea.m@...il.com>,
	"shuah.kh@...sung.com" <shuah.kh@...sung.com>,
	USB list <linux-usb@...r.kernel.org>,
	"Kernel development list" <linux-kernel@...r.kernel.org>
Subject: RE: First kernel patch (optimization)

From: Austin S Hemmelgarn
> Sent: 16 September 2015 12:46
> On 2015-09-15 20:09, Steve Calfee wrote:
> > On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin <ericcurtin17@...il.com> wrote:
> >> Signed-off-by: Eric Curtin <ericcurtin17@...il.com>
> >>
> >> diff --git a/tools/usb/usbip/src/usbip_detach.c b/tools/usb/usbip/src/usbip_detach.c
> >> index 05c6d15..9db9d21 100644
> >> --- a/tools/usb/usbip/src/usbip_detach.c
> >> +++ b/tools/usb/usbip/src/usbip_detach.c
> >> @@ -47,7 +47,9 @@ static int detach_port(char *port)
> >>          uint8_t portnum;
> >>          char path[PATH_MAX+1];
> >>
> >> -       
> >> +       unsigned int port_len = strlen(port);
> >> +
> >> +       for (unsigned int i = 0; i < port_len; i++)
> >>                  if (!isdigit(port[i])) {
> >>                          err("invalid port %s", port);
> >>                          return -1;
> >>
> >> --
> >
> > Hi Eric,
> >
> > This is fine, but what kind of wimpy compiler optimizer will not move
> > the constant initializer out of the loop? I bet if you compare binary
> > sizes/code it will be exactly the same, and you added some characters
> > of code. Reorganizing code for readability is fine, but for compiler
> > (in)efficiency seems like a bad idea.
> While I agree with your argument, I would like to point out that it is a
> well established fact that GCC's optimizers are kind of brain-dead at
> times and need their hands held.
> 
> I'd be willing to bet that the code will be marginally larger (because
> of adding another variable), but might run slightly faster too (because
> in my experience, GCC doesn't always catch things like this), and should
> compile a little faster (because the optimizers don't have to do as much
> work).

The compiler probably can't optimise the strlen().
If isdigit() is a real function (the locale specific one probably is)
then the compile cannot assume that port[n] isn't changed by the call
to isdigit.

A simpler change would be:
	for (unsigned int i = 0; port[i] != 0; i++)

Much better would be to use strtoul() instead of atoi().

	David