Re: Concurrent access to /dev/urandom

From: Matt Mackall (mpm_at_selenic.com)
Date: 12/10/04

  • Next message: Jörn Engel: "Re: [RFC PATCH] debugfs - yet another in-kernel file system"
    Date:	Fri, 10 Dec 2004 10:28:04 -0800
    To: "Theodore Ts'o" <tytso@mit.edu>, Bernard Normier <bernard@zeroc.com>, linux-kernel@vger.kernel.org
    
    

    On Fri, Dec 10, 2004 at 11:35:58AM -0500, Theodore Ts'o wrote:
    > On Thu, Dec 09, 2004 at 08:47:59PM -0800, Matt Mackall wrote:
    > >
    > > But it turns out that we can do this without hashing under the lock
    > > after all. What's important is that we mix and extract atomically.
    > > Something like this should be quite reasonable:
    >
    > The core idea is good, but your patch has a bug in it; it bashes
    > add_ptr before it gets saved into r->add_ptr.

    I seem to remember having a rationale for that, but I'm fine with your
    way.

    > Also, it's a more
    > complicated than it needed to be (which makes it harder to analyze
    > it).

    Fair enough. s/__add/mix/, please.

    > Finally, it won't work if the pool doesn't get initialized with
    > sufficient randomness in the init scripts, and there are too many
    > constant zero's in the pool. But this is easily fixed by using a
    > different initialization pattern.

    It won't work as in we'll still get duplicates? I don't see how that
    happens. The polynomial for the output pools is dense enough that even
    on the very next one word mix, we're getting 96 bits changed in the
    output and 32 new ones shifted in. And we're always doing at least
    three adds for each pull.

    It's still suboptimal, perhaps, but I'd rather mix more in
    init_std_data. In fact, I was hoping to abolish the pool clearing
    function in favor of just init_std_data, as there's not much utility
    in going back to a known state here. Let's address this separately.

    -- 
    Mathematics is the supreme nostalgia of our time.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Jörn Engel: "Re: [RFC PATCH] debugfs - yet another in-kernel file system"

    Relevant Pages

    • Re: Concurrent access to /dev/urandom
      ... > But it turns out that we can do this without hashing under the lock ... constant zero's in the pool. ... * the entropy is concentrated in the low-order bits. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: race on multi-processor solaris
      ... > CPU it is currently executing on. ... Give each CPU a pool of free memory ... the only possibility for contention on this lock ...
      (comp.unix.solaris)
    • RE: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B 1
      ... >OK, I have started to look at this driver, I have come across one ... >memory from the pool is in use", however, they don't have to guarantee ... >that pool is not null. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Mutex Pool
      ... - I've got a mapping from IDs to objects. ... Currently there's only the one lock over the entire mapping, ... from a pool, you assign the lock a temporary name or something to ... The latter link is an example of full-blown portable atomic reference counting using so-called mutex-pool/table and hashing algorithm. ...
      (comp.programming.threads)
    • Re: Mutex Pool
      ... - I've got a mapping from IDs to objects. ... Currently there's only the one lock over the entire mapping, ... from a pool, you assign the lock a temporary name or something to ... The latter link is an example of full-blown portable atomic reference counting using so-called mutex-pool/table and hashing algorithm. ...
      (comp.programming.threads)