linux-kernel - Re: strncpy optimalisation? (lib/string.c)

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]

Date:	Sun, 10 Dec 2006 22:35:19 +0100
From:	Folkert van Heusden <folkert@...heusden.com>
To:	Willy Tarreau <w@....eu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: strncpy optimalisation? (lib/string.c)

...
> > now I wonder isn't this ineffecient when strlen(src) < count? It would
> > then, if I'm correct, iterate count-strlen(src) times doing useless
> > increment/decrement. And since there are aprox. 580 instances in the
> > 2.6.18.2 source, maybe some efficency can be won here.
> > Wouldn't it be better to do:
> >                 if ((*tmp = *src) == 0x00)
> >                         break;
> > So that would be:
> > --- lib/string.c	2006-11-04 02:33:58.000000000 +0100
> > +++ string-new.c	2006-12-10 21:50:05.000000000 +0100
> > @@ -97,8 +97,8 @@
> >  	char *tmp = dest;
> >  
> >  	while (count) {
> > -		if ((*tmp = *src) != 0)
> > -			src++;
> > +		if ((*tmp = *src) == 0x00)
> > +			break;
> >  		tmp++;
> >  		count--;
> >  	}
> While your code is faster, it does not do exactly the same.
> Original code completely pads the destination with zeroes,
> while yours only adds the last zero. Your code does what
> strncpy() is said to do, but maybe there's a particular
> reason for it to behave differently in the kernel (helping
> during debugging, or filling specific structs).
> Just out of curiosity, have you tried to do a general
> benchmark to check if original code eats much CPU ?

My patch was incorrect; it would only repeatingly copy the first
character from the source.
This one (tested in test-code seperate from kernel) works:
diff -uNrBbd lib/string.c string-new.c
--- lib/string.c        2006-11-04 02:33:58.000000000 +0100
+++ string-new.c        2006-12-10 22:34:39.000000000 +0100
@@ -97,9 +97,10 @@
        char *tmp = dest;

        while (count) {
-               if ((*tmp = *src) != 0)
-                       src++;
+               if (unlikely((*tmp = *src) == 0x00))
+                       break;
                tmp++;
+               src++;
                count--;
        }
        return dest;

The improvement in speed depends on the size of the source and
destination. Maybe i did something wrong but it seems that in all cases
the new version is faster.

Test can be found here:
http://www.vanheusden.com/misc/kernel-strncpy-opt-test.c


Signed-off by: Folkert van Heusden <folkert@...heusden.com>

Folkert van Heusden

-- 
www.vanheusden.com/multitail - win een vlaai van multivlaai! zorg
ervoor dat multitail opgenomen wordt in Fedora Core, AIX, Solaris of
HP/UX en win een vlaai naar keuze
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
-
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/