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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B102C021B2 for ; Sun, 23 Feb 2025 04:02:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0F216B007B; Sat, 22 Feb 2025 23:02:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BEF36B0082; Sat, 22 Feb 2025 23:02:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 886356B0083; Sat, 22 Feb 2025 23:02:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6BF846B007B for ; Sat, 22 Feb 2025 23:02:54 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0CBA51CC33E for ; Sun, 23 Feb 2025 04:02:54 +0000 (UTC) X-FDA: 83149863468.13.FCC5A27 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf14.hostedemail.com (Postfix) with ESMTP id 1BF11100002 for ; Sun, 23 Feb 2025 04:02:51 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=OjR+S3uO; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf14.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740283372; a=rsa-sha256; cv=none; b=PpG8VmcmfVGHOUjgTlPh5tmgo7ckH99m7AXmQwSlJoPmGAU8zaxdlj7/mndJueOIeyVOpu R1gisyRQvAnYsbSaUStgQyi9RgMGjGssAh8lv8tyjH3v9qrvkCKW1koUAXX6egJelpbQA1 bvgW8SXuW25q3ghUjtIJtn0IWKYxzQo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=OjR+S3uO; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf14.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740283372; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7X/a6yKMJK840olzn4NcUlQ7572WIMjZpQOK9Wp6mVY=; b=Uagdfb8yDJ/MSqwzIar78H44/6fdiAy42sUy4QgAiJJ5UgyDPDRKre88HVB8a+gPtxDxRo /QmKVyRWfkrICRgZjBp3C/SpRROan+xcdc9EqFXAuLVkT/Vx+1FLnExhz3lawd2p3X9mTF T8nilyHjmWtLyJLi4TplgHK38BtYaro= Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-2fcff77ff9bso2187078a91.0 for ; Sat, 22 Feb 2025 20:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740283371; x=1740888171; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7X/a6yKMJK840olzn4NcUlQ7572WIMjZpQOK9Wp6mVY=; b=OjR+S3uOXhslOQ/1MNEAmcj5SyEFUKVP24SCzaYLeSxHozEzEDhL6cuDVwRC+AfE1N l0hhk9hOQ2x7VY5hlUUYiCFibbMvBKhC/3tewOoASJ25VgwahZjVr9gC99niJNsVRLCx n0mqYqEUKmW24ilFUJUcanb7io786KcUV1rxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740283371; x=1740888171; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7X/a6yKMJK840olzn4NcUlQ7572WIMjZpQOK9Wp6mVY=; b=ikc8uBRrK8hCNXGjjA444z4xy++tMsjYm0d8HHSSzknspQXAJfSqb2TJe8S95HFQoO XZJib1dKiUD4xJH5Mq9wvj3sfSblbVWlhdGmR8ttUPlTRS+Fxya0YAa7F29k0RFfmgy7 dsxz+BXQgpaNvrQyXCWyln6lf5by/lZgD4I0XYZtl4eJy71tGotolZDKBkkfq4fsMKSg BtQQRQSa12mGe0vhivw+9ZoRbPOKxJ3NT06/GglKwAs3KtAjJTSaZr5UnhC/4mZBU3mA 3m7fqAElz6/e6hnesW/qHRW8r59O726PfutTF1A6/2IIYwnnpLIcrdCCue9c+pl4XfBu g+/Q== X-Forwarded-Encrypted: i=1; AJvYcCUvqrzaueB6528M4P30WoajCU5MagwXNofTQfFiibmEGJi0KCcNNlRrzdmAcDxEOzjqzQeqC7nIgw==@kvack.org X-Gm-Message-State: AOJu0YxvUM5aDm45H28VaZttJ7PmrrzrPXQYBLagqwKLXkfkbLOCMyf3 T6B6/6lVJaxOqw8xdEhiRSI9+HuBm2wRcDjC+IX1V5C45w0BDlQhYU+sFAQZOQ== X-Gm-Gg: ASbGncuallm7pafKQ0BGXqhfTFLWflAXI2o1WV9Pw2lurnTGPn1sXcVYrIAb6LIXmEp nEAGMjjFo2xhO8ohzznMgGTQQeAQaQ/LcXqLipDX+VhWJ/CdJvZyLiyMVTC+BaiGR8g1nHXRk8H HNpjr77FExlIadqROL8ISumi5HJdOYgXm8njbmnDpdhy8w10GYzJrCePYxL/ExF+Hgo5gSpJsCc 10+x4YjPRbXMeNFZm8XXg9hQHjvmKADL7NsqcGVVAZzhpKED//OCCk1jKzhFZxgvDOuxldBuILJ J6D0hgDcPxaBEbE7IPXjADBmQTc6 X-Google-Smtp-Source: AGHT+IGGp+0kbnPW/KjNjCOzaQWqa83C+/uSTXFIzfy4XdmQFLXNo8MIxjAHIe5svT4w4lKj1mV4VA== X-Received: by 2002:a17:90b:37c7:b0:2ee:8ea0:6b9c with SMTP id 98e67ed59e1d1-2fce78a508dmr16896210a91.12.1740283370980; Sat, 22 Feb 2025 20:02:50 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:badf:54f:bbc8:4593]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-220d556fbeesm157324385ad.183.2025.02.22.20.02.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Feb 2025 20:02:50 -0800 (PST) Date: Sun, 23 Feb 2025 13:02:41 +0900 From: Sergey Senozhatsky To: Herbert Xu Cc: Sergey Senozhatsky , Barry Song <21cnbao@gmail.com>, Yosry Ahmed , Minchan Kim , "Sridhar, Kanchana P" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "akpm@linux-foundation.org" , "linux-crypto@vger.kernel.org" , "davem@davemloft.net" , "clabbe@baylibre.com" , "ardb@kernel.org" , "ebiggers@google.com" , "surenb@google.com" , "Accardi, Kristen C" , "Feghali, Wajdi K" , "Gopal, Vinodh" Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 1BF11100002 X-Rspamd-Server: rspam12 X-Stat-Signature: thn4p6y6si9nihco54q5441wezschcht X-HE-Tag: 1740283371-30783 X-HE-Meta: U2FsdGVkX18/HvYdDed5GUZVXwstwjCizCKqCsdVv+5+Y2i4fYvpA7xgWFixX3V2B64EtFXGm4IiCpWRL+qCqRHooMDOwp8MmwwCminU2YHVyUtlvIp1+wMdQBxyR8DrYKLPAPKXiISUizYmbqmBC9XWBCHAox5daq6boTj1A/SfeaII1F8eir2jM6S24uUSLIZJz+Xnx/Ei0uip63FNk5Z3EzwgV/80/5K+WjVm5mqi4roEQBv2z1+Duj7L2rtpVWu2yPD/HWN9nxU97oSDUcctXYssv7kfNetdRCXudHmVj3+RxGMfuzp7ejqZwg0+aseanNv/ft+l5xLzANx4OSTPOfNVbnPck96fD485IaJwu3idujgR+AVLB5zPgtw38Y18b8qYkCzSJl/gVQB8JJ4Vi9OQXCMDTh6O4E0MhpKPD9niimHIhC1s0sXtyfQTeWKD4U8NaBhMThEVtCXHmz7PLPVWtOfMHp6OYxORCeyLM4iriGLMtH3RjyyC1etxB5sNKzekzhNdqElXipVrdB73i+eFRwxb2P+XGrgOV9mp70c6wlHovTL3kBvqSPMi+Ckq4zFD6KmBC0RI6Js4bpDg8WxwP5RIjDhQRxQ8xZvqnSIHvwnPPmS5LLVPHTm4DYHMFKn8wvqdeR+K7/Nmt6r42E17RoHZMCyfVustucARFijj4KIHQtC4cfEOaI2vBEYXJdyD3u/QMuwBx3/LfKqjScoCHzF4/3P7AjkIyXQaJtJMZkxVRxX7C0G275EUWpmMalkaP2fPoPYAxXMUu9NOAwrqq9HMiJ/tz9nZOdMXaHxFZsnQtZ4uRDflFmbYGAcorIvYRLojECLhVBqBlJVSoC23r1gaeCr1BqEOeO61noiSJIZE4m5VjVTqDGqg4IQ+SNACWAV5aNbBcymSJbt3Ml6kBPxXwciwzjc7YbGDwpGFGgsr68GHc6kcSZUuTrKWx+tNSvpkoFQgK1B gmu+lqOY a7/cg2ntcJZJLp8LtgDp66tnw1qvWTlJJsdDMgSuEea4QTcwnVv019irw9vtx6RupksaP2iZ3/aFuTmNtgzx8nHKTzn/Xfhh34jaIKHjbM2Ez7zQSDnbszd+2jmEoec8t4dULeFO0cBR90z99E+50yj6G90lPG+FryQjrryTgaBtNqG607we0Cbc+N8kFO0ts/jiilusmqWsLRCnvgICKKQMYDp1XJ7nNC0nmMFNokeXIWGuVVMRowjuDO8PmXkimO/L3keWXu8ykrRRP1qmzTnMH3b1EqGOmljL5GrgeFd9j/PAXGo1jViigprHzHSCDh4oNitkfNJ2mBp+t/tbF5pwQN1iYGE9p4wy1UgroGCOe6Qb4n1zXLgArxGTcsTnhQOhPus6NPeKDK8AY54qoYpl7tw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000293, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On (25/02/23 11:38), Herbert Xu wrote: > On Sun, Feb 23, 2025 at 12:12:47PM +0900, Sergey Senozhatsky wrote: > > > > > > It also seems that there is no common way of reporting dst_but overflow. > > > > Some algos return -ENOSPC immediately, some don't return anything at all, > > > > and deflate does it's own thing - there are these places where they see > > > > they are out of out space but they Z_OK it > > > > > > > > if (s->pending != 0) { > > > > flush_pending(strm); > > > > if (strm->avail_out == 0) { > > > > /* Since avail_out is 0, deflate will be called again with > > > > * more output space, but possibly with both pending and > > > > * avail_in equal to zero. There won't be anything to do, > > > > * but this is not an error situation so make sure we > > > > * return OK instead of BUF_ERROR at next call of deflate: > > > > */ > > > > s->last_flush = -1; > > > > return Z_OK; > > > > } > > > > } > > > > > > Z_OK is actually an error, see crypto/deflate.c: > > > > I saw Z_STREAM_END, but deflate states "this is not an error" and > > there are more places like this. > > That would be a serious bug in deflate. Where did you see it > return Z_STREAM_END in case of an overrun or error? Oh, sorry for the confusion, I was talking about Z_OK for overruns. > > So it will ENOSPC all errors, not sure how good that is. We also > > have lz4/lz4hc that return the number of bytes "(((char *)op) - dest)" > > if successful and 0 otherwise. So any error is 0. dst_buf overrun > > is also 0, impossible to tell the difference, again not sure if we > > can just ENOSPC. > > I'm talking about the Crypto API calling convention. Individual > compression libraries obviously have vastly different calling > conventions. > > In the Crypto API, lz4 will return -EINVAL: > > int out_len = LZ4_compress_default(src, dst, > slen, *dlen, ctx); > > if (!out_len) > return -EINVAL; Right, so you said that for deflate it could be ret = zlib_deflate(stream, Z_FINISH); if (ret != Z_STREAM_END) { ret = -ENOSPC; // and not -EINVAL goto out; } if I understood it correctly. Which would make it: return 0 on success or -ENOSPC otherwise. So if crypto API wants consistency and return -ENOSPC for buffer overruns, then for lz4/lz4hc it also becomes binary: either 0 or -ENOSCP. Current -EINVAL return looks better to me, both for deflate and for lz4/lz4hc. -ENOSPC is an actionable error code, a user can double the dst_out size and retry compression etc., while in reality it could be some SW/HW issue that is misreported as -ENOSPC. So re-iterating Barry's points: > My point is: > 1. All drivers must be capable of handling dst_buf overflow. Not the case. > 2. All drivers must return a consistent and dedicated error code for > dst_buf overflow. Not the case.