linux-kernel - RE: [PATCH] /dev/zero: also implement ->read

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]

Date:   Mon, 7 Sep 2020 08:18:13 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Christophe Leroy' <christophe.leroy@...roup.eu>,
        Pavel Machek <pavel@...x.de>
CC:     Christoph Hellwig <hch@....de>, "arnd@...db.de" <arnd@...db.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] /dev/zero: also implement ->read

From: Christophe Leroy
> Sent: 07 September 2020 05:44
...
> If you are talking about the tests around the set_fs series from
> Christoph, I identified that the degradation was linked to
> CONFIG_STACKPROTECTOR_STRONG being selected by default, which provides
> unreliable results from one patch to another, GCC doing some strange
> things linked to unrelated changes.
> 
> With CONFIG_STACKPROTECTOR set to N, I get stable performance and no
> degradation with any of the patches of the set_fs series.

Ah I didn't spot that response going through.

Sounds like that option should be disabled if it causes that
much of a performance drop.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)