[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxhobNMY5RLmH+tKox8voqfH-bVqKVF03JeeVrHkhLcaQ@mail.gmail.com>
Date: Thu, 5 Jul 2012 19:59:00 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Theodore Ts'o" <tytso@....edu>, Matt Mackall <mpm@...enic.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
w@....eu, ewust@...ch.edu, zakir@...ch.edu, greg@...ah.com,
nadiah@...ucsd.edu, jhalderm@...ch.edu, tglx@...utronix.de,
davem@...emloft.net, stable@...nel.org
Subject: Re: [PATCH 01/10] random: make 'add_interrupt_randomness()' do
something sane
On Thu, Jul 5, 2012 at 4:21 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Thu, Jul 05, 2012 at 05:31:22PM -0500, Matt Mackall wrote:
>>
>> It's better to mix and not credit than to not mix at all. Instead just
>> check the fast count against HZ before the credit.
>
> I'm not sure what you mean by this?
So what I think Matt meant was to check number of timer interrupts
against the fast count.
IOW, always call "add_interrupt_randomness()", but then in that
function, when you determine the amount of entropy, check if there
were non-timer interrupts in the last HZ cycle. If there were purely
timer interrupts, you can still mix in the cycle information, but it's
likely to be fairly weak.
That said, if we do have a real TSC, I suspect there's tons of entropy
in it even for a pure timer interrupt, so it's more like "if the
*only* source of randomness we have is the timer interrupt and the
jiffies value, that doesn't really add any entropy at all".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists