linux-kernel - Re: blk-throttle: Move three assignments for the variable "ret" in tg_set

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: <736ca444-0157-4dbb-ef30-e59b36596c1f@kernel.dk>
Date:   Mon, 23 Jan 2017 08:17:24 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        linux-block@...r.kernel.org
Cc:     LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: blk-throttle: Move three assignments for the variable "ret" in
 tg_set_max()

On 01/23/2017 05:06 AM, SF Markus Elfring wrote:
>>> We have got different preferences for the placement of error code settings.
>> Yes we do, so what's the point? Both are OK.
> 
> Can a function implementation be executed a bit faster in the case
> that error codes will usually only matter if they would be set after
> a concrete software failure

Don't turn this into a troll fest. Maintainability trumps performance.
Every time. See previous email for reasoning for that.

>> Please don't go down that road it opens so much potential for needless bikeshedding
>> and waste all of our (including your) time.
> 
> I would appreciate to clarify involved run time consequences a bit more.

How about you go and benchmark the before and after, and present some
compelling evidence based on those tests for why the change should be
made? The onus is on the submitter here, not the reviewer.

As I said in the previous email, don't bother sending these types of
patches for the block layer again. They are just going to be ignored.

-- 
Jens Axboe