From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83FF3EB64DD for ; Tue, 18 Jul 2023 22:33:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231317AbjGRWdD (ORCPT ); Tue, 18 Jul 2023 18:33:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230046AbjGRWdC (ORCPT ); Tue, 18 Jul 2023 18:33:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E34BB19A1; Tue, 18 Jul 2023 15:32:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 77B5E61298; Tue, 18 Jul 2023 22:32:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41861C433C7; Tue, 18 Jul 2023 22:32:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689719561; bh=7Gbf5E8xcaK5OEKWGb4CHdLczRMlJnuQEgylfRoJijU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ufuwLPWCK8dWV8FkCqtCEz1epizX5iOUu9r0pzjEB8rAo3vv70aUHG7DaVTyC0KRg 9GffXUB6RPQfiH4Pwwly5QDNxRzp24n52b7+3LD9ARpF8rJiXrkrBeyyZXIPCRwCL3 YnFduPkPfkN/Xgp87N8DLRjyb4cFcZH/W6xsrlYbCUBOsPO7LPaSINVyNCf7nN7z43 VbtnrwxtgFI9aorRlk+A+3KII5/Vn0DPycSXnFotjqn6aFg9SWYv2fXiVGJgnhvXsX jEkhDeNqSzOymSxwFCvBFlJkeTEmz1CT/UJjdF6RKWm+b8SD1lfeb02J5lyYQ8cZJU KTXuktmKYxzVQ== Date: Tue, 18 Jul 2023 15:32:39 -0700 From: Eric Biggers To: Ard Biesheuvel Cc: linux-crypto@vger.kernel.org, Herbert Xu , Kees Cook , Haren Myneni , Nick Terrell , Minchan Kim , Sergey Senozhatsky , Jens Axboe , Giovanni Cabiddu , Richard Weinberger , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Steffen Klassert , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, qat-linux@intel.com, linuxppc-dev@lists.ozlabs.org, linux-mtd@lists.infradead.org, netdev@vger.kernel.org Subject: Re: [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)" Message-ID: <20230718223239.GB1005@sol.localdomain> References: <20230718125847.3869700-1-ardb@kernel.org> <20230718125847.3869700-2-ardb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230718125847.3869700-2-ardb@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Tue, Jul 18, 2023 at 02:58:27PM +0200, Ard Biesheuvel wrote: > This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5. > > "zlib-deflate" was introduced 6 years ago, but it does not have any > users. So let's remove the generic implementation and the test vectors, > but retain the "zlib-deflate" entry in the testmgr code to avoid > introducing warning messages on systems that implement zlib-deflate in > hardware. > > Note that RFC 1950 which forms the basis of this algorithm dates back to > 1996, and predates RFC 1951, on which the existing IPcomp is based and > which we have supported in the kernel since 2003. So it seems rather > unlikely that we will ever grow the need to support zlib-deflate. > > Signed-off-by: Ard Biesheuvel > --- > crypto/deflate.c | 61 +++++----------- > crypto/testmgr.c | 8 +-- > crypto/testmgr.h | 75 -------------------- > 3 files changed, 18 insertions(+), 126 deletions(-) So if this is really unused, it's probably fair to remove it on that basis. However, it's not correct to claim that DEFLATE is obsoleted by zlib (the data format). zlib is just DEFLATE plus a checksum, as is gzip. Many users of zlib or gzip use an external checksum and therefore would be better served by DEFLATE, avoiding a redundant builtin checksum. Typically, people have chosen zlib or gzip simply because their compression library defaulted to it, they didn't understand the difference, and they overlooked that they're paying the price for a redundant builtin checksum. An example of someone doing it right is EROFS, which is working on adding DEFLATE support (not zlib or gzip!): https://lore.kernel.org/r/20230713001441.30462-1-hsiangkao@linux.alibaba.com Of course, they are using the library API instead of the clumsy crypto API. - Eric