linux-kernel - Re: [PATCH v2 3/2] lib/uuid.c: Silence an unchecked return value warning

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: <20160607164302.27585.qmail@ns.sciencehorizons.net>
Date:	7 Jun 2016 12:43:02 -0400
From:	"George Spelvin" <linux@...encehorizons.net>
To:	andriy.shevchenko@...ux.intel.com, linux@...encehorizons.net
Cc:	bjorn@...k.no, linux-kernel@...r.kernel.org,
	matt@...eblueprint.co.uk, rv@...musvillemoes.dk
Subject: Re: [PATCH v2 3/2] lib/uuid.c: Silence an unchecked return value warning

Andy Shevchenko wrote:

> ^^^^ Something wrong with mail configuration?

Oops, sorry, I forgot to delete the header.

> On Sun, 2016-06-05 at 15:25 -0400, George Spelvin wrote:
>> It's also faster, as hex_to_bin() *is* inlined within hex2bin()
>> (if you compile with -O).

> To be sure it faster we need the measurements. Sometimes it's not
> obvious.

You're right that sometimes measurements show surprising results.
But do you want to bet on it?  :-)

If speed were a primary goal, I'd want to be sure.

But as you pointed out, this is not hot-path code and speed is *not*
a primary goal.  Being off the hot path also makes benchmarking
more annoying, as it's hard to define realistic test conditions.
(Code resident in L2 but not in L1?)

So I think it's reasonable in this case to estimate rather than waste
effort striving for certainty.  Performing the same basic operations in
the same order, but with shorter code and fewer jumps, it's hard not to
be faster.

It might be measurably faster, or it might be an insignificant change
that's not measurable, but barring some bizarre alignment or cache
aliasing effect, the chance of it being *slower* is negligible.

Speaking pedantically, you're right.  But as a practical matter, it's
very unlikely, and what makes it truly insignificant is that it's not
really a problem even if I'm wrong and the code *is* slower.

As you said, size is more important than speed, and I did, at your
request, benchmark that.  I'm just trying to make the sort of changes
that improve *both*.

If you have a realistic concern that the patches degrade speed, I can
put in a few hours of work to put the different versions into a test
harness and measure it accurately.

But if this is just a pro forma observation that estimates aren't
perfectly reliable, it's not worth the effort.