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 PHC | |
Open Source and information security mailing list archives
| ||
|
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