Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp130264ybg; Sun, 31 May 2020 19:19:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxOaggs7n4/3WYQAY8tZw11TjcyKhuKXsONTROYhfxdr30hyyXqRmMQmJZjzn625QPaezd X-Received: by 2002:a17:906:d8d7:: with SMTP id re23mr16805880ejb.22.1590977983463; Sun, 31 May 2020 19:19:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590977983; cv=none; d=google.com; s=arc-20160816; b=TmEbeUeY+bBuhQllrxdzeJnwd7ar34j6vll5kFDZ3OKrwlUS8RN8qgMgPdf6Qw91YA 5JzsTtpRAZGFgeEl4p1JTw9EAahznHLVX7faFhqKflyhKssOMjpFZClQnVhAlDNU+Itd Iv+YzhJsGyWX1J5dDHaHaFF5oq/6KQovRZKNKT0tl93j0MOFvmYwm6RIKsp5jS3emtyC g+gjsqQ3HasrF3+eXqfiYRimELPcMWpAAyWEztklMiIdhlXp91ClFKr4SdmiEwrwj1uQ QNhEKKYxeTGqkB6p1H56jE4Tado7BRKu180jtMtdFdJpqmMI/A8Wc7s1Px3ggSy7AC1+ +PoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=QAyr6BJcqrRGQQM447WERC1AB6fteNlNCb8lALgA1kA=; b=mVIFOM2v1uUiXmjfzMS+chyFcGbI/SreIuNp2HfK0ZYN+Hf7DCNDbE5X/R/0jUFFm/ HDtrEgTz5htZjsuhbpSLFAoUzPvnywwoq2TijRj606B2Y6kL+DWJnnSV9LSUt7js/s9m fcpzoZbtgDg541pCOLvESv0V2/cGPzBJEfpiLpIURCy86tpmcu7tOMkEZj0IFz2m/fwP EIVV1AXldgbkwY2jfcx/nFSmy+gi2OQ57CeQ9Rm0MkGtcxL3mbBgTaxkqPij43z6H8Sg BB17EZt6IoUNLmCj3yWlhhh3Azw7fEn2WHmi0SDt5G2Gmy9EfTiwswSCgkutQxZ3+eWe ftww== 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 o5si9732117edz.312.2020.05.31.19.19.06; Sun, 31 May 2020 19:19:43 -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 S1726943AbgFACTE (ORCPT + 99 others); Sun, 31 May 2020 22:19:04 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:2513 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726860AbgFACTE (ORCPT ); Sun, 31 May 2020 22:19:04 -0400 Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.57]) by Forcepoint Email with ESMTP id 9893F90A4FBC51007D1C; Mon, 1 Jun 2020 10:19:01 +0800 (CST) Received: from dggeme762-chm.china.huawei.com (10.3.19.108) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 1 Jun 2020 10:19:01 +0800 Received: from [10.65.91.233] (10.65.91.233) by dggeme762-chm.china.huawei.com (10.3.19.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 1 Jun 2020 10:19:01 +0800 Subject: Re: [PATCH] crypto: hisilicon/qm - allow smaller reads in debugfs To: Dan Carpenter , Zhou Wang CC: Herbert Xu , "David S. Miller" , , , References: <20200528123703.GA1219412@mwanda> From: Shukun Tan Message-ID: Date: Mon, 1 Jun 2020 10:19:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20200528123703.GA1219412@mwanda> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.65.91.233] X-ClientProxiedBy: dggeme719-chm.china.huawei.com (10.1.199.115) To dggeme762-chm.china.huawei.com (10.3.19.108) X-CFilter-Loop: Reflected Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi Dan & Zhou, On 2020/5/28 20:37, Dan Carpenter wrote: > Originally this code rejected any read less than 256 bytes. There > is no need for this artificial limit. > > Also I have changed the snprintf() functions to scnprintf(). The > difference is that snprintf() returns the number of bytes which would > have been copied if there were enough space and scnprintf() returns the > number of bytes which were actually copied. It doesn't matter here > because the strings are very short so they can't go over 256 bytes. > > Signed-off-by: Dan Carpenter > --- > drivers/crypto/hisilicon/qm.c | 18 ++++++++---------- > 1 file changed, 8 insertions(+), 10 deletions(-) > > diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c > index a781c02251980..9c0c9f500d91d 100644 > --- a/drivers/crypto/hisilicon/qm.c > +++ b/drivers/crypto/hisilicon/qm.c > @@ -1076,16 +1076,15 @@ static ssize_t qm_cmd_read(struct file *filp, char __user *buffer, > if (*pos) > return 0; > > - if (count < QM_DBG_READ_LEN) > - return -ENOSPC; > - I think we should keep it, maybe you are right when using 'cat', but if you use 'read' system call this may make the user read only part of the prompt. This may break our original design. :) Thanks, Shukun > - len = snprintf(buf, QM_DBG_READ_LEN, "%s\n", > + len = scnprintf(buf, QM_DBG_READ_LEN, "%s\n", > "Please echo help to cmd to get help information"); > > + len = min_t(size_t, len, count); > if (copy_to_user(buffer, buf, len)) > return -EFAULT; > > - return (*pos = len); > + *pos = len; > + return len; > } > > static void *qm_ctx_alloc(struct hisi_qm *qm, size_t ctx_size, > @@ -2710,19 +2709,18 @@ static ssize_t qm_status_read(struct file *filp, char __user *buffer, > if (*pos) > return 0; > > - if (count < QM_DBG_READ_LEN) > - return -ENOSPC; > - > val = atomic_read(&qm->status.flags); > - len = snprintf(buf, QM_DBG_READ_LEN, "%s\n", qm_s[val]); > + len = scnprintf(buf, QM_DBG_READ_LEN, "%s\n", qm_s[val]); > if (!len) > return -EFAULT; > > + len = min_t(size_t, len, count); > cp_len = copy_to_user(buffer, buf, len); > if (cp_len) > return -EFAULT; > > - return (*pos = len); > + *pos = len; > + return len; > } > > static const struct file_operations qm_status_fops = { >