[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxAe1pRN+jvdLveHQ+nNRNC6HDZ+S4Y9P202rxgNLN8pg@mail.gmail.com>
Date: Thu, 5 Jul 2012 14:47:52 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matt Mackall <mpm@...enic.com>
Cc: "Theodore Ts'o" <tytso@....edu>,
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 2:39 PM, Matt Mackall <mpm@...enic.com> wrote:
>
> From my read, this code path gets called on timer interrupts too.
That's hopefully never true for any normal cases (timers are *very*
special - they tend to go through their own architecture-specific
stuff). On modern PC's, for example, the timers happen through the
local apic timers directly.
In fact, with SMP, it's a really bad idea to use a normal irq for
timer interrupts, since you really really want per-CPU-core timers.
But yes, we should probably make sure that *if* the architecture uses
regular interrupts for timers we don't count them. The problematic
embedded platforms are often pretty crap hardware: even when they are
SMP, they might use an external timer irq (and then we broadcast the
thing). I think we have the IRQF_TIMER flag for that, so we could add
a check for that.
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