Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2535844pxb; Sun, 16 Jan 2022 23:59:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJwzKRyE/U17xGPitLGqropk2/s2svOAcwH3JFLdOwsOv/vhk4tGhQTAjRyLSfy30lvU9aT7 X-Received: by 2002:a63:ab08:: with SMTP id p8mr17849771pgf.617.1642406384566; Sun, 16 Jan 2022 23:59:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642406384; cv=none; d=google.com; s=arc-20160816; b=s5r+sIxJhuZGB5IWE2SASJOUY/v/tAzoJyk+JMQgeMw+bChdWpAkSZ2DedBsYV7V02 OKEDjQ7jyq/GEX9+v9ql1peSacN51F1q7A+71SFXuYsMZtAmyZ4WGbmqYv6dYDNWjsdI p5Ak7ayombEQg+NEBjysvZ2Kete8/xuB+rhn2Hz+z0EZ0jWM4A2nN72fUcrDoZ+AFB+A EhZs/hVsIlIrqCqGLzr0j74HzJZ8Ad5bDaFVTBMS50KjoUUiO576OqVet4w7DZRsBFWx d3Ehpz4YeghBNAPb+Un2IMtA8NWHxECjKmVQAF9E3Ys6UHFPJ4xdZ456MYsCqhY0Kk1k hRGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=haj6Esi+4t9n/PSSXbSW62xDirwF63qZkQ4SVY6VaCo=; b=gnEgOn05Jw1EsUGokxFo9I1OrF3MPlty/MnJ6LhmPfoMJbAadaZs0DAyK2Yqy/bidd zJGjnuIQGSl4/GiEp/b+kzKTV9sxKmDXa0e3cjt4w3JecETbp7/6r6MeN/qTbWSqGena a9r9AuRhlKz4FDjEb5o/vWGk0AXqUpn8BTSoHhCOuKC2u9/RT6rzYBfGfvIIUcyPVgD5 QgqMxwDQIJ/V5F/fDed817VZ9MCtLcJtTHAuNlO9XuXTAgJaqn7pLFNlKUEtxh+LV6sQ Ild1n2BQGFyDsnkWMVtF3Hotj/ZBuF2kVQXg0k1Iunj7qzF4yrEmOBi2H3J2ipv2yTwH MRCA== ARC-Authentication-Results: i=1; mx.google.com; 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 f4si13687629pgv.692.2022.01.16.23.59.33; Sun, 16 Jan 2022 23:59:44 -0800 (PST) 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; 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 S235371AbiAPNpS (ORCPT + 99 others); Sun, 16 Jan 2022 08:45:18 -0500 Received: from isilmar-4.linta.de ([136.243.71.142]:53490 "EHLO isilmar-4.linta.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233345AbiAPNpJ (ORCPT ); Sun, 16 Jan 2022 08:45:09 -0500 X-isilmar-external: YES X-isilmar-external: YES X-isilmar-external: YES Received: from owl.dominikbrodowski.net (owl.brodo.linta [10.2.0.111]) by isilmar-4.linta.de (Postfix) with ESMTPSA id 5A81C200278; Sun, 16 Jan 2022 13:45:07 +0000 (UTC) Received: by owl.dominikbrodowski.net (Postfix, from userid 1000) id DD94A80354; Sun, 16 Jan 2022 14:24:55 +0100 (CET) Date: Sun, 16 Jan 2022 14:24:55 +0100 From: Dominik Brodowski To: "Jason A. Donenfeld" Cc: linux-kernel@vger.kernel.org, tytso@mit.edu Subject: Re: [PATCH 4/7] random: remove unused reserved argument Message-ID: References: <20220113154413.29513-1-Jason@zx2c4.com> <20220113154413.29513-5-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220113154413.29513-5-Jason@zx2c4.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Thu, Jan 13, 2022 at 04:44:10PM +0100 schrieb Jason A. Donenfeld: > This argument is always set to zero, as a result of us not caring about > keeping a certain amount reserved in the pool these days. So just remove > it and cleanup the function signatures. > > Signed-off-by: Jason A. Donenfeld I'd suggest noting in the patch title and commit message that this relates to the extract_entropy() function. > @@ -1342,7 +1341,7 @@ static size_t account(struct entropy_store *r, size_t nbytes, int min, > /* never pull more than available */ > have_bytes = entropy_count >> (ENTROPY_SHIFT + 3); > > - if ((have_bytes -= reserved) < 0) > + if (have_bytes < 0) > have_bytes = 0; > ibytes = min_t(size_t, ibytes, have_bytes); Hmm. We already WARN_ON(entropy_count < 0) a few lines below. Maybe move that assertion before the assignement of have_bytes? Then, have_bytes can never be lower than zero, and the code becomes even simpler. What do you think? Reviewed-by: Dominik Brodowski Thanks, Dominik