Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp175089ybg; Tue, 28 Jul 2020 03:06:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsFsI1mVTB7eT9ax/vuE7eK0Fzxbx7+TPANzDEy9f3CeGt0W6mC0HYNHgwbGC5nM6meEaj X-Received: by 2002:a50:fc84:: with SMTP id f4mr18918923edq.220.1595930789293; Tue, 28 Jul 2020 03:06:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595930789; cv=none; d=google.com; s=arc-20160816; b=OcBYaaO+HjR08NFcWh5hIRn7OB/+OaGuoMkGOjMTvAWknYzCfSgB6IrwBzvLNW0zRQ YRnIgqgfLHnwCODbSbY+sYYYrb+y3uLw5KlXtKHUJmmTqQzUB5nP+LKbH6k+xtnQ4GOZ lbO4ltJ71wQN95h+AqCahjXRH9sWjdRk708QCaQUk5zJGxFGvk+M5/8gTrWZFRDNw+lJ GxYcnyoKze8hx5J2n47BhsYcB7SEHQrFo7E1Z9ZFzNRtII/iqLoUyRXA8J4tSaJPhBYf VGlZ8AOyKtepWIMkvy1Ta4r9tvEiS+/Yg/c+ZJF6e9PnkLnRyMwHydCFh2cdSrMJhNdY 7aPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date:from:dkim-signature; bh=acftKy5haTTez29DldMveP4DByaH/OvKD4GTibGUU4c=; b=eRCEflVwON9SRZO1L51fq/29lNSsUlkx5xeswSeEektbWi7k2G8kkirc/6yAZFCZIa qf8PaoZadCXg6m/+L30PUnVemc8g2rH0ZvKbxjt+JKsQVWxfpZsJkGBFvt7+DIQJgqqs X9hp9aMOrbsEQr1uEmpLm5fx9JLBh/gw1UoaH55MsQ8Df2GuD4zUPKh2HWMMhR5fGuvG U3RaCgm+dIwur27xIDlCd8HwiJgFJma0g7OISCB4LTaHqJ38Cm/v4OLQDgtMMPyyE7fJ DVNAt9IxG7OL+PPTpIsaZnCfS1xkzAB/KIdKlCaX7Fh4Mnw1wOMgoZlKPwZUGjG7pVM+ nfkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foundries-io.20150623.gappssmtp.com header.s=20150623 header.b=Rgc3hv+0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 mm22si2793343ejb.735.2020.07.28.03.06.06; Tue, 28 Jul 2020 03:06:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@foundries-io.20150623.gappssmtp.com header.s=20150623 header.b=Rgc3hv+0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728542AbgG1KF7 (ORCPT + 99 others); Tue, 28 Jul 2020 06:05:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728496AbgG1KF7 (ORCPT ); Tue, 28 Jul 2020 06:05:59 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DA27C0619D2 for ; Tue, 28 Jul 2020 03:05:59 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id c80so16739683wme.0 for ; Tue, 28 Jul 2020 03:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foundries-io.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=acftKy5haTTez29DldMveP4DByaH/OvKD4GTibGUU4c=; b=Rgc3hv+0TiPIPSmJyeuNzphIlAXlhB57Ndn3MyQQjhGIRo7fBOZm0ddElDeMWTuygZ dRjmlW9ouLZrHpVmLNTsw5F8YzqPnchsPuj2Cp2NtvtEiUwEwfBSoH4odVJmHnJnGvNj ZU7+Jlag9E0ffsFq77QUbAE/vznnG4tQCQ1ivZhMFZdROTfoFMcmOO+b7ZaZB5HMpSv3 L5dahpKCwrcOQcp5Rq8BJFAWUEBFhMdwLUSSPyF8G+AbkXhzSUhy0ZUZBukxzZr9VFhi a9ZertakXO+gT9GioNeRWN6ytFTIETHAcEJBIvBse019ratABWkASFXNxtE3aSY/GN1/ EZ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=acftKy5haTTez29DldMveP4DByaH/OvKD4GTibGUU4c=; b=BsUWydoww/snyHsc7SwswyG1RkaBFbCqRT4g5IBQb6+dvVadoATF0XBQiVhJhSttlR 6N4LmuC/7WisbJP/wGgcXqeiOHt/meZTBaimPbqvgZYS72Lm0ncKuVYCdKe72nbJ8RyZ mRQmv+EiVzGVtsgdSvZmrWw2SrJkuTAZV0cb1HXLjDhOnpie6sShZGUb3SWQjKZUN9JW W12HyPhaKYcyoTayDMl7Z6uXde9rEcr+YkbJUppcPGMnNF/1o+ZIXTZxQHamVuvKJwSP JmPzq2TAqdBTgCdaS7Zgm+YwegaoWXgKP5+qpV96vrMFe3pjUUHqeItqYTdPo5QU3l2h sKSA== X-Gm-Message-State: AOAM531CJzomtLonFHa8brvm6kZDAoUOJtDX3DhItLIWKThP9kOWq4Kf zPaS8or2QOZPl3VUBv4ypylpCg== X-Received: by 2002:a1c:1b93:: with SMTP id b141mr3393238wmb.150.1595930757237; Tue, 28 Jul 2020 03:05:57 -0700 (PDT) Received: from trex (239.red-83-34-184.dynamicip.rima-tde.net. [83.34.184.239]) by smtp.gmail.com with ESMTPSA id x4sm17668932wru.81.2020.07.28.03.05.55 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 28 Jul 2020 03:05:56 -0700 (PDT) From: "Jorge Ramirez-Ortiz, Foundries" X-Google-Original-From: "Jorge Ramirez-Ortiz, Foundries" Date: Tue, 28 Jul 2020 12:05:55 +0200 To: "Jorge Ramirez-Ortiz, Foundries" Cc: Sumit Garg , Matt Mackall , Herbert Xu , Jens Wiklander , Arnd Bergmann , ricardo@foundries.io, Michael Scott , Greg Kroah-Hartman , op-tee@lists.trustedfirmware.org, "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Linux Kernel Mailing List Subject: Re: [PATCHv2 2/2] hwrng: optee: fix wait use case Message-ID: <20200728100555.GA2074@trex> References: <20200723084622.31134-1-jorge@foundries.io> <20200723084622.31134-2-jorge@foundries.io> <20200724142305.GA24164@trex> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200724142305.GA24164@trex> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/07/20, Jorge Ramirez-Ortiz, Foundries wrote: > On 24/07/20, Sumit Garg wrote: > > On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz wrote: > > > > > > The current code waits for data to be available before attempting a > > > second read. However the second read would not be executed as the > > > while loop exits. > > > > > > This fix does not wait if all data has been read and reads a second > > > time if only partial data was retrieved on the first read. > > > > > > This fix also does not attempt to read if not data is requested. > > > > I am not sure how this is possible, can you elaborate? > > currently, if the user sets max 0, get_optee_rng_data will regardless > issuese a call to the secure world requesting 0 bytes from the RNG > > with this patch, this request is avoided. > > > > > > > > > Signed-off-by: Jorge Ramirez-Ortiz > > > --- > > > v2: tidy up the while loop to avoid reading when no data is requested > > > > > > drivers/char/hw_random/optee-rng.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/char/hw_random/optee-rng.c b/drivers/char/hw_random/optee-rng.c > > > index 5bc4700c4dae..a99d82949981 100644 > > > --- a/drivers/char/hw_random/optee-rng.c > > > +++ b/drivers/char/hw_random/optee-rng.c > > > @@ -122,14 +122,14 @@ static int optee_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait) > > > if (max > MAX_ENTROPY_REQ_SZ) > > > max = MAX_ENTROPY_REQ_SZ; > > > > > > - while (read == 0) { > > > + while (read < max) { > > > rng_size = get_optee_rng_data(pvt_data, data, (max - read)); > > > > > > data += rng_size; > > > read += rng_size; > > > > > > if (wait && pvt_data->data_rate) { > > > - if (timeout-- == 0) > > > + if ((timeout-- == 0) || (read == max)) > > > > If read == max, would there be any sleep? > > no but I see no reason why there should be a wait since we already have > all the data that we need; the msleep is only required when we need to > wait for the RNG to generate entropy for the number of bytes we are > requesting. if we are requesting 0 bytes, the entropy is already > available. at leat this is what makes sense to me. > > any further comments? > > > > -Sumit > > > > > return read; > > > msleep((1000 * (max - read)) / pvt_data->data_rate); > > > } else { > > > -- > > > 2.17.1 > > >