Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1025097ybb; Wed, 1 Apr 2020 14:13:04 -0700 (PDT) X-Google-Smtp-Source: APiQypKF73Fzj508Kcml+Gp9zVA1iD9dEHs6RxW4goJYmpo1nRFxed40+SPhVdYOtHPVn/AT4AHp X-Received: by 2002:aca:6184:: with SMTP id v126mr249073oib.168.1585775584330; Wed, 01 Apr 2020 14:13:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585775584; cv=none; d=google.com; s=arc-20160816; b=YznzJwPteOSZ4+l1h+0Jv27ZRpqk69Hj97IaHFSo03awfmOtLCJPZfUpaJphVrejBJ xcAZrn5DLVQo0zN1SrMgPiSp5xTjCPhf47WOWDj7xSvCDt/R8/t/ysjQjQuNeHLN8hnV 7bcB3Tjg5q88K8aH5gl1um81cENtQPJyJHSrd4h2b+JrvHiTBOLmK+XrNy8bCoFBGrGH F/fqH97UmZVRNBrhO+vuyj27xJU1FPKoQl8Za6658k0rFurb/n6vWNOADuGnuIaHxcuN znwqpaU4UAmLoEH6Hrh/YtKl2MSM6DDp//hz8obGoh2VBBrbcXo0AvccGdWrQ13/ecoy +yyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=XP9hLsYiaeWGYxXwhwwXcOkTgYbWpTAaoA3TJDPgAUs=; b=EZ+Rg5k/Q0+zDO0+9GtyA/wkXARQkuWS2rNve4/ZCVwh3oWyI+sxNjMFBOOl3JjNA3 kIaHU1BOin0drGu7k1JBKYIoUQJV2tPMGD3gBvLhUCelYcyEsElCkZiqM7pg5/LnJK33 cxQJjjRgdRQYVnR5ligsQ24pTxfGteHvt5RZLOe+yioNZ8QjQGa7EjpIkUEKBexAk4mV aoW2Xfh/9x52grDBzm0eHUM/Vf1mdVD3GwRRmyNAWrd+IALQq716noKE6xTXXuHl4Gm+ L3OQik9w6sVP+mW0Q3hvmB48ykR1mzenZxkoaJjOP4ZMm4/ymerJqO0xuyS2Q0N5pzSW +Wig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m67si1293865oib.215.2020.04.01.14.12.50; Wed, 01 Apr 2020 14:13:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732560AbgDAVLS (ORCPT + 99 others); Wed, 1 Apr 2020 17:11:18 -0400 Received: from mx.sdf.org ([205.166.94.20]:49842 "EHLO mx.sdf.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732337AbgDAVLR (ORCPT ); Wed, 1 Apr 2020 17:11:17 -0400 Received: from sdf.org (IDENT:lkml@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 031LB4uG010365 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 1 Apr 2020 21:11:04 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 031LB4aa013811; Wed, 1 Apr 2020 21:11:04 GMT Date: Wed, 1 Apr 2020 21:11:04 +0000 From: George Spelvin To: linux-kernel@vger.kernel.org, tytso@mit.edu Cc: Sebastian Andrzej Siewior , lkml@sdf.org Subject: Re: [RFC PATCH v1 36/50] random: Merge batched entropy buffers Message-ID: <20200401211104.GA2013@SDF.ORG> References: <202003281643.02SGhLiv003379@sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202003281643.02SGhLiv003379@sdf.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I just noticed a rather insidious bug in the preceding, so please revoke my S-o-b. Storing the batch position in the first byte works fine if it's updated very late in get_random_uXX(), after the random value is read from a refilled batch. The first few versions of my code did this. But then I discovered the "xor trick" to handle unaligned reads and it hugely simplfiied the code. It simplified it so much that the unaligned position wasn't needed much; only to compute the aligned position. While squashing together the various revisions to this code, I moved the write-back of the position earlier in the code.. Which violates the requirement stated in paragraph 2. :-( There are several possible fixes, but the simplest is to move the "u8 position;" down a couple of lines, out of the union. Since the following patch reduces the lock to a single byte, there's room in the structure without increasing its size. Revised patch will follow.