From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1750922AbdAUGYp (ORCPT <rfc822;w@1wt.eu>);
        Sat, 21 Jan 2017 01:24:45 -0500
Received: from imap.thunk.org ([74.207.234.97]:39234 "EHLO imap.thunk.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750717AbdAUGYh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 21 Jan 2017 01:24:37 -0500
Date: Sat, 21 Jan 2017 01:24:32 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
        Hannes Frederic Sowa <hannes@stressinduktion.org>,
        Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH 1/2] random: use chacha20 for get_random_int/long
Message-ID: <20170121062432.kf7xnu56g7vvh4ky@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Hannes Frederic Sowa <hannes@stressinduktion.org>,
        Andy Lutomirski <luto@amacapital.net>
References: <20170106183202.5035-1-Jason@zx2c4.com>
 <20170118034907.spozwf4erlvx5s4x@thunk.org>
 <CAHmME9qRHdTQj_wmLV1tBv1SdO+xy1HhYtTJohs6V1sFZZZeyg@mail.gmail.com>
 <20170120142852.lznr25go4pbdlwdt@thunk.org>
 <CAHmME9pbSRXuuFgXzLvKS=faJ0_7TOHCZGZg49=0+Yc=cO6-6w@mail.gmail.com>
 <20170121001509.fj23eunnkaqj7yce@thunk.org>
 <CAHmME9p3xc6Q2Qu6kEP1O3PmvLKhpWcwjHfX8AQyibC0Quh65g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHmME9p3xc6Q2Qu6kEP1O3PmvLKhpWcwjHfX8AQyibC0Quh65g@mail.gmail.com>
User-Agent: NeoMutt/20161126 (1.7.1)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Jan 21, 2017 at 01:16:56AM +0100, Jason A. Donenfeld wrote:
> On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> > But there is a shared pointer, which is used both for the dedicated
> > u32 array and the dedicated u64 array.  So when you increment the
> > pointer for the get_random_u32, the corresponding entry in the u64
> > array is wasted, no?
> 
> No, it is not a shared pointer. It is a different pointer with a
> different batch. The idea is that each function gets its own batch.
> That way there's always perfect alignment. This is why I'm suggesting
> that my approach is faster.

Oh, I see.  What was confusing me was that you used the same data
structure for both, and but you were using different instances of the
structure for get_random_u32 and get_random_u64.  I thought you were
using the same batched_entropy structure for both.  My bad.

I probably would have used different structure definitions for both,
but that's probably because I really am not fund of unions at all if
they can be avoided.  I thought you were using a union because you
were deliberately trying to use one instance of the structure as a per
cpu variable for u32 and u64.

So that's not how I would do things, but it's fine.

						- Ted