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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 22 Sep 2015 10:38:23 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Eric Curtin <ericcurtin17@...il.com>
Cc:	valentina.manea.m@...il.com, Shuah Khan <shuah.kh@...sung.com>,
	USB list <linux-usb@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin <ericcurtin17@...il.com> wrote:
> My first kernel patch, hope I did everything correctly! Instead of calling strlen on every iteration of the for loop, just call it once instead and store in a variable.

Heh. Ok, that resulted in a rather long email thread.

Anyway, I'd actually prefer to merge this patch, for two reasons:

 - the "termination calculation is expensive" problem is a real
problem, and while in this case the compiler may be able to notice
that the "strlen()" is constant over the loop and can be hoisted up,
that is not at all necessarily the case most of the time.

    So I actually think patches like this are good things. Not because
this particular code site necessarily matters, but because people who
write code with things like "strlen()" in the terminating condition
need to learn that it's *wrong*.

 - I'd much rather see this kind of trivial patch than the usual
trivial patch that is clearly just "let's run some script on the
kernel and fix up warnings it generates mindlessly".

   In contrast to that, *this* trivial patch was about somebody who
thought about code generation and efficiency. And *that* is the kind
of trivial patches we want to encourage, not necessariyl because this
particular case was so important, but because that's the kind of
people and thinking we want to encourage.

So quite frankly, I'd just take this directly, but I'd like more of
real changelog.

But I wonder if Eric is even reading the emails any more ;)

                 Linus
--
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/