Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp133824pxu; Wed, 2 Dec 2020 17:18:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJweTv3yDkzVrLRyRTjQKkAlfD/b5gvSfs4+a5tJp1ye8maRYc3mleNhlkJEazuSme4goUYi X-Received: by 2002:a17:906:451:: with SMTP id e17mr475189eja.228.1606958309431; Wed, 02 Dec 2020 17:18:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606958309; cv=none; d=google.com; s=arc-20160816; b=lyQcF0aoGZdni1WLHb/kDWuq0xICK6d77AdBBX7LIW8XJ0LU0MyaQVLmPbHSyopnU0 o93Qeqxyml3uE9eGiM8y0Gzaft9q7eTR5lWq2g3LlyLW0V5JEcWoQx+CHnRDknh53gOq VF+Xk2M2bSK7jVezSoO0t7Mqo1/6j8gj1coHJq4IQ6EOAGYABvtKS72QF/qxdNMXzECy 9HZ57z0klq16ooGj8bx6x1bIXiEKUhS4DmM8xfZzRBMoxMS2VK3kALWZQy4ilm1tKmnF FVTUu4fO1zD0tW128sMzESOD/l759Zu1V5kgzCccB1REhriimm3phKkTsxTm/cp7hOUh L7nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=cuOn5bVJZy5iKEwlXrn7Tf414lHOqQ82Eu9bbUWOvp0=; b=WnVvuh98lHZAposqhvBgmY64qemNy9Ktg0FTo9Jh9+CzCP0iBQRV3W/QkwqBa//RL7 ZT+OXp4GbP+DZwgewdFQ8hTHYyT0PpJP+8dvqXFmX3gAk+EFuRY7CYTRv5lLtozIq3ve lqaIQ9ICji1fDjjYnwoM+hXYQObadQk+tWJstk2MQNwh7iTO2BIPOD+0+p2UGMQmKAlu CezZvy0QlgQSqOToC4T2ijb9Fj+GH11HHD2jhbT5vtnopsyKSdWubTngBrNTzghtxJd+ YAPWE7kS47vP3I9vJ73rRW5fn+8nJKOY5hY9BzeJgMkWhnJpE+N8CU+UQMTHay4cf8k/ S4IA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rere.qmqm.pl header.s=1 header.b=SB1xzSox; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p10si171381eji.254.2020.12.02.17.17.32; Wed, 02 Dec 2020 17:18:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@rere.qmqm.pl header.s=1 header.b=SB1xzSox; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727624AbgLCBQv (ORCPT + 99 others); Wed, 2 Dec 2020 20:16:51 -0500 Received: from rere.qmqm.pl ([91.227.64.183]:14765 "EHLO rere.qmqm.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726479AbgLCBQv (ORCPT ); Wed, 2 Dec 2020 20:16:51 -0500 Received: from remote.user (localhost [127.0.0.1]) by rere.qmqm.pl (Postfix) with ESMTPSA id 4CmdFh0f48zDf; Thu, 3 Dec 2020 02:16:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rere.qmqm.pl; s=1; t=1606958169; bh=6oH15t1Df77ZzG2EVYajQgZvMvBqFmQvQbWlZwQ2QEs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SB1xzSoxRoViOvvVeCEfofLQUmg5XpUMvkEJnMhZgf4r5+49NISCcc68BpcHlcelp vNYiHf3Y6pH9y2kgG7CWVFcbafVXxYka/WdyrF0KPL5Hvh5EhPE4vDVnBYWQ3gRoX8 ztYX1Suc2WQy4SYjMo6rZCiD2t1qqX3t4HkyXGYXL9AipWeYZm9B4FPZDuskD4j7MS ayG7+2YnPhqL8qlmrUe2wpRqI5pMaDMoU5rWiO90pfbg+wyvzGLDAFf7lfU7Rn2Ml5 BU67UaFjNVJGrLp02M/bcgw7yq7F2AcsD/5mZfdpWtcSPr9z531bqis+g9Of2npGuf 2JgTSxT7Emreg== X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.4 at mail Date: Thu, 3 Dec 2020 02:16:06 +0100 From: =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= To: Nick Terrell Cc: Herbert Xu , linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org, squashfs-devel@lists.sourceforge.net, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Kernel Team , Nick Terrell , Chris Mason , Petr Malat , Johannes Weiner , Niket Agarwal , Yann Collet , Christoph Hellwig Subject: Re: [PATCH v6 1/3] lib: zstd: Add kernel-specific API Message-ID: <20201203011606.GA20621@qmqm.qmqm.pl> References: <20201202203242.1187898-1-nickrterrell@gmail.com> <20201202203242.1187898-2-nickrterrell@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201202203242.1187898-2-nickrterrell@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, Dec 02, 2020 at 12:32:40PM -0800, Nick Terrell wrote: > From: Nick Terrell > > This patch: > - Moves `include/linux/zstd.h` -> `lib/zstd/zstd.h` > - Adds a new API in `include/linux/zstd.h` that is functionally > equivalent to the in-use subset of the current API. Functions are > renamed to avoid symbol collisions with zstd, to make it clear it is > not the upstream zstd API, and to follow the kernel style guide. > - Updates all callers to use the new API. > > There are no functional changes in this patch. Since there are no > functional change, I felt it was okay to update all the callers in a > single patch, since once the API is approved, the callers are > mechanically changed. [...] > --- a/lib/decompress_unzstd.c > +++ b/lib/decompress_unzstd.c [...] > static int INIT handle_zstd_error(size_t ret, void (*error)(char *x)) > { > - const int err = ZSTD_getErrorCode(ret); > - > - if (!ZSTD_isError(ret)) > + if (!zstd_is_error(ret)) > return 0; > > - switch (err) { > - case ZSTD_error_memory_allocation: > - error("ZSTD decompressor ran out of memory"); > - break; > - case ZSTD_error_prefix_unknown: > - error("Input is not in the ZSTD format (wrong magic bytes)"); > - break; > - case ZSTD_error_dstSize_tooSmall: > - case ZSTD_error_corruption_detected: > - case ZSTD_error_checksum_wrong: > - error("ZSTD-compressed data is corrupt"); > - break; > - default: > - error("ZSTD-compressed data is probably corrupt"); > - break; > - } > + error("ZSTD decompression failed"); > return -1; > } This looses diagnostics specificity - is this intended? At least the out-of-memory condition seems useful to distinguish. > +size_t zstd_compress_stream(zstd_cstream *cstream, > + struct zstd_out_buffer *output, struct zstd_in_buffer *input) > +{ > + ZSTD_outBuffer o; > + ZSTD_inBuffer i; > + size_t ret; > + > + memcpy(&o, output, sizeof(o)); > + memcpy(&i, input, sizeof(i)); > + ret = ZSTD_compressStream(cstream, &o, &i); > + memcpy(output, &o, sizeof(o)); > + memcpy(input, &i, sizeof(i)); > + return ret; > +} Is all this copying necessary? How is it different from type-punning by direct pointer cast? Best Regards Micha? Miros?aw