Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp276236pxt; Fri, 6 Aug 2021 01:33:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxw/fqCNIlMi3yQcGnybMX9nELQFnn7loweuVmAmJfCj6sYeI9Qql1lTRXREccK9Uo8DQt9 X-Received: by 2002:aa7:c952:: with SMTP id h18mr11790779edt.18.1628238791086; Fri, 06 Aug 2021 01:33:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628238791; cv=none; d=google.com; s=arc-20160816; b=bL0ByKQLGzOZPPmdlrX2aWCrb3df0WXcuPftF0mOPuTdvDWcglcxzqPn89Syno0DwJ 04JVa57XEWAB0SIGEE8vEShVFzm0zmXEuXaJqtNF/5arG/x/e4kK2jUZ9ICjX8uPqz7h 54AVT2N9hjDbah1iA9d0TmW1bGrjkoFHNnqlkxp0Dp0fBA5Mlfq2DmbRQQa8zZgnJB/3 i16sX+50Xb/3dVa6VQVVmrNllhhTW6FRSO8xxDN7k8AiO3oCkDEp1EFyfeYRcKhHmNla 3KwQSLg1FV8/puqc3taYKJ3wJYLsUU23HGCZtCwXIly8vgGTtstRd8gRY4VqpaUu8dVp RxRQ== 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-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=rs4Ky/r5gE8PgYW2+qq8c+1RCuOTqncEhwvcgP3B69Q=; b=pzVeONYT0xQdJ4+ZzmIDSjTAKu2pK5wY7Nnblb4zAJLooc1qse8WwDAbaYnq5ngh8y eGu/j6/i07SYjTdGw+nF5w20Av+4OI5s8l5EbUKcCl+tdYyNUyCQ2KV3MQMsztx8tcZT d81cbi/gEybQRNdbsapejIT+RGTn3GIoqJxc7MeZZuX5ZXHKkbQqOLp9ABIemEj1X9bY qfOF909KqManG0dXZZqxtxeeKPfMmLNNeuGYxPvrim4V4CReoTOZq9Bmro/bE3FNVNaY Ia4OqA9EGEwygz4OZkPwP3fOEtCbu8fA5aTW4X279eAdLHYfGhMXmCEcnVvFBqeynExS TDYw== ARC-Authentication-Results: i=1; mx.google.com; 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 z11si7775948ejo.318.2021.08.06.01.32.47; Fri, 06 Aug 2021 01:33:11 -0700 (PDT) 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; 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 S230127AbhHFIbt (ORCPT + 99 others); Fri, 6 Aug 2021 04:31:49 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:51744 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230119AbhHFIbt (ORCPT ); Fri, 6 Aug 2021 04:31:49 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtp (Exim 4.92 #5 (Debian)) id 1mBvGO-0007NM-Sh; Fri, 06 Aug 2021 16:31:32 +0800 Received: from herbert by gondobar with local (Exim 4.92) (envelope-from ) id 1mBvGM-0003QS-Dv; Fri, 06 Aug 2021 16:31:30 +0800 Date: Fri, 6 Aug 2021 16:31:30 +0800 From: Herbert Xu To: Kai Ye Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, wangzhou1@hisilicon.com Subject: Re: [PATCH 2/5] crypto: hisilicon/sec - delete the print of fallback tfm application failure Message-ID: <20210806083130.GA13132@gondor.apana.org.au> References: <1627701996-4589-1-git-send-email-yekai13@huawei.com> <1627701996-4589-3-git-send-email-yekai13@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1627701996-4589-3-git-send-email-yekai13@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Sat, Jul 31, 2021 at 11:26:33AM +0800, Kai Ye wrote: > Modify the print of information that might lead to user misunderstanding. > Currently only XTS mode need the fallback tfm when using 192bit key. > Others algs not need soft fallback tfm. So others algs can return > directly. > > Signed-off-by: Kai Ye > --- > drivers/crypto/hisilicon/sec2/sec_crypto.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) I don't think this is a good change. > @@ -2032,13 +2032,12 @@ static int sec_skcipher_soft_crypto(struct sec_ctx *ctx, > struct skcipher_request *sreq, bool encrypt) > { > struct sec_cipher_ctx *c_ctx = &ctx->c_ctx; > + SYNC_SKCIPHER_REQUEST_ON_STACK(subreq, c_ctx->fbtfm); > struct device *dev = ctx->dev; > int ret; > > - SYNC_SKCIPHER_REQUEST_ON_STACK(subreq, c_ctx->fbtfm); > - > if (!c_ctx->fbtfm) { > - dev_err(dev, "failed to check fallback tfm\n"); > + dev_err(dev, "the soft tfm isn't supported in the current system.\n"); If we end up in this code path you'll be spamming the printk buffer on every single request. This is not acceptable. At least rate limit these messages. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt