lkml.org 
[lkml]   [2013]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] /dev/random: Insufficient of entropy on many architectures
    On Tue, Sep 10, 2013 at 05:31:45PM -0700, John Stultz wrote:
    > Yea, that point about "every single interrupt" vs "every timer
    > interrupt". I suspect that if its every timer interrupt, this can be
    > done easily w/ clocksources as we already do that read, but every single
    > interrupt would have potential problems with various other devices with
    > high irq frequency.

    Yep. The worse case would probably a serial port running at 230400
    bps. Even with a 16550A UART with the 16-byte FIFO, we're talking
    about close to 2,000 interrupts per second. A 16450 running at 115200
    bps would give us 11,520 interrupts per second....

    > Right so get_cycles() really sounds like the right thing here.

    For those platforms which have them, yes.

    > Although I wonder if you run into issues with counters that wrap
    > quickly? Or does that not matter?

    No, it doesn't matter. It's really the low bits of the counter which
    are really important to us anyway. For example on MIPS there is a
    register which is bumped on every CPU cycle, but its kept mod the
    number of entries in the TLB (it's used for random TLB eviction).
    That's what we'll probably ending using for MIPS, since its cycle
    counter is not guaranteed to be there, and had a bug which could cause
    timer interrupts to get lost if you tried reading from it at the wrong
    time.

    > Right. In many cases jiffies is all that we have. Thus the check for
    > timekeeping_valid_for_hres() can be used to at least flag that case. Not
    > that I know what you want to do if it comes up false.

    Right now, if get_cycles() returns 0, we fall back to only mixing in
    the IP register from the interrupt plus the jiffies counter. The
    platforms where get_cycles returns 0 is:

    - MIPS (solution pending)
    - User mode Linux
    - Sparc 32 bit
    - M68K
    - M32R
    - Hexagon
    - H8/300
    - FR-V
    - CRIS
    - AVR32
    - ARC
    - METAG
    - Microblaze
    - SCORE
    - SH
    - Unicore32

    Would I be correct in assuming that most of these probably don't have a
    high-res clocksource, and so would fall back to jiffies anyway?

    Thanks,

    - Ted


    \
     
     \ /
      Last update: 2013-09-11 03:21    [W:2.500 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site