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]
Message-ID: <6C449BCE-E7DB-4EE6-B4F5-FED3977BD8F0@fb.com>
Date:   Wed, 16 Dec 2020 22:07:38 +0000
From:   Nick Terrell <terrelln@...com>
To:     David Sterba <dsterba@...e.cz>
CC:     Herbert Xu <herbert@...dor.apana.org.au>,
        Eric Biggers <ebiggers@...nel.org>,
        Nick Terrell <nickrterrell@...il.com>,
        "squashfs-devel@...ts.sourceforge.net" 
        <squashfs-devel@...ts.sourceforge.net>,
        Christoph Hellwig <hch@...radead.org>,
        Yann Collet <cyan@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-f2fs-devel@...ts.sourceforge.net" 
        <linux-f2fs-devel@...ts.sourceforge.net>,
        Petr Malat <oss@...at.biz>, "Chris Mason" <clm@...com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        Niket Agarwal <niketa@...com>,
        Btrfs BTRFS <linux-btrfs@...r.kernel.org>,
        Johannes Weiner <jweiner@...com>
Subject: Re: [f2fs-dev] [PATCH v7 0/3] Update to zstd-1.4.6



> On Dec 16, 2020, at 10:50 AM, David Sterba <dsterba@...e.cz> wrote:
> 
> On Wed, Dec 16, 2020 at 11:58:07AM +1100, Herbert Xu wrote:
>> On Wed, Dec 16, 2020 at 12:48:51AM +0000, Nick Terrell wrote:
>>> 
>>> Thanks for the advice! The first zstd patches went through Herbert’s tree, which is
>>> why I’ve sent them this way.
>> 
>> Sorry, but I'm not touch these patches as Christoph's objections
>> don't seem to have been addressed.
> 
> I have objections to the current patchset as well, the build bot has
> found that some of the function frames are overly large (up to 3800
> bytes) [1],

Sorry I missed your reply David, it didn’t make it to my inbox.

Compiled with x86-64, arm, and aarch64 that function does not trigger any
-Wframe-larger-than= warnings during the kernel build. It seems like the
compiler backend for the parisc architecture (the architecture that the build
bot used) is doing a particularly bad job at optimizing this function, because
there is nothing in there that should be using that much stack space.

I have a test in upstream zstd that measures the stack high water mark for
all usage of zstd compression currently in-use the kernel. It says that zstd
uses 2KB of stack space in total on x86-64. I used this test to remove 1KB of
stack usage from upstream zstd. But, this is still 400 bytes more than the
current version of zstd in the kernel. I will look into squeezing out those last
400 bytes of stack usage.

> besides the original complaint that the patch 3/3 is 1.5MiB.
> 
> [1] https://lore.kernel.org/lkml/20201204140314.GS6430@twin.jikos.cz/

It is very large. If it helps, in the commit message I’ve provided this link [0],
which provides the diff between upstream zstd as-is and the imported zstd,
which has been modified by the automated tooling to work in the kernel.

[0] https://github.com/terrelln/linux/commit/ac2ee65dcb7318afe426ad08f6a844faf3aebb41

Best,
Nick

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ