linux-kernel - Re: MD-RAID: Use seq_putc() in three status functions?

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: <f0cdb05a-a1b7-8962-fb9c-cc4739178e8b@suse.de>
Date:   Mon, 17 Oct 2016 16:00:14 +0200
From:   Hannes Reinecke <hare@...e.de>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>,
        linux-raid@...r.kernel.org
Cc:     Christoph Hellwig <hch@....de>, Guoqing Jiang <gqjiang@...e.com>,
        Jens Axboe <axboe@...com>, Joe Perches <coupons@...ches.com>,
        Mike Christie <mchristi@...hat.com>,
        Neil Brown <neilb@...e.com>, Shaohua Li <shli@...nel.org>,
        Tomasz Majchrzak <tomasz.majchrzak@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org, kbuild-all@...org,
        ltp@...ts.linux.it
Subject: Re: MD-RAID: Use seq_putc() in three status functions?

On 10/17/2016 01:10 PM, SF Markus Elfring wrote:
>>> * Is a string pointer often longer than a byte?
>>>
>> Always.
> 
> I have got doubts for this specific information.
> 
> 
>> (Which up to now I thought was basic programming knowledge...)
> 
> By the way:
> Run time environments still exist where the size of a pointer can be also
> just one byte, don't they?
> 
Really? Name one.
You can only fit a point in one byte if you are on an 8-bit system.
Which I don't think linux is running on.

>>> How many results would we like to clarify from various hardware
>>> and software combinations?
>>>
>> See above. At the moment _any_ test result from your side would do.
> 
> I imagine that another single result might not be representative.
> How many lessons from test statistics will usually be also relevant here?
> 
> 
As said above, _any_ statistic will do at this point.

>>> How important are the mentioned functions for you within the Linux
>>> programming interface so far?
>>>
>> Not very. The interface is only used in a slow path, and the execution
>> time doesn't affect I/O performance in any way.
> 
> Thanks for another interesting information.
> 
> 
>>>> Case in point: with your patch the x86_64 compiler generates nearly
>>>> identical code for driver/md/raid1.c, but with one instruction _more_
>>>> after your patch has been applied.
>>>
>>> Which software versions and command parameters did you try out
>>> for this information (from an unspecified run time environment)?
>>>
>> # gcc --version
>> gcc (SUSE Linux) 4.8.5
> 
> Thanks for this detail.
> 
> * Did you choose any special optimisation settings for your quick check?
> 
> * Will any compilation results matter if "optimisation" would be
>   switched off there?
> 
> 
These were the results when calling 'make' in the kernel source tree.
With all applicable options.

>> I'm still waiting from results from your side.
> 
> Would any other software developers or testers dare to add related information?
> 
No. It's your patch, _you_ have to do it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@...e.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)