Avi Kivity <[EMAIL PROTECTED]> writes:
> I don't understand why interrupt latency suffers. Sure, the interrupt that's
> being masked is delayed, but on the other hand the interrupt that's doing the
> masking is not. We're moving the latency from the first interrupt to the
> second, probably with
Bill Irwin wrote:
On Tue, 2007-03-06 at 22:44 -0800, Bill Irwin wrote:
What do you see as the obstacle to eliminating nested IRQ's?
On Wed, Mar 07, 2007 at 04:34:52AM -0800, Arjan van de Ven wrote:
political will, or maybe just the lack of convincing people so far
Politica
> > just removing the if() and the explicit IRQ enabling already makes irqs no
> > longer nest...
>
> I can see why that would raise eyebrows. I can see getting bashed
> mercilessly with interrupt latency concerns as a result here. Can you
> suggest any defenses?
hardirq handlers are supposed
On Tue, 2007-03-06 at 22:44 -0800, Bill Irwin wrote:
>> What do you see as the obstacle to eliminating nested IRQ's?
On Wed, Mar 07, 2007 at 04:34:52AM -0800, Arjan van de Ven wrote:
> political will, or maybe just the lack of convincing people so far
Political issues are significantly more diffi
On Tue, 2007-03-06 at 22:44 -0800, Bill Irwin wrote:
> At some point in the past, I wrote:
> >> I'm certainly in favor of the move; IRQ stacks could be made
> >> rather deep and cheaply at that. I may get around to writing it this
> >> week if no one else does it first.
>
> On Tue, Mar 06, 2007 at
At some point in the past, I wrote:
>> I'm certainly in favor of the move; IRQ stacks could be made
>> rather deep and cheaply at that. I may get around to writing it this
>> week if no one else does it first.
On Tue, Mar 06, 2007 at 08:28:35PM -0800, Arjan van de Ven wrote:
> the irq stacks aren'
> I'm certainly in favor of the move; IRQ stacks could be made
> rather deep and cheaply at that. I may get around to writing it this
> week if no one else does it first.
the irq stacks aren't the problem; RH at some point accidentally shipped
a kernel with 4k *shared* irq/user context stack and e
On Tue, 6 Mar 2007, Chuck Ebbert wrote:
>> In the 4k/4k stack i386 kernel, is there any fundamental reason it
>> can't be 4k/8k? We seem to be mostly hitting problems in overflowing
>> the IRQ stack... I think. Overhead would only be 4k per CPU for that.
On Tue, Mar 06, 2007 at 07:43:41PM +, H
Bill Irwin wrote:
>> Chuck, is any of this of any use to you?
On Tue, Mar 06, 2007 at 01:59:39PM -0500, Chuck Ebbert wrote:
> I said "simple." :)
> In the 4k/4k stack i386 kernel, is there any fundamental reason it
> can't be 4k/8k? We seem to be mostly hitting problems in overflowing
> the IRQ st
On Tue, 6 Mar 2007, Chuck Ebbert wrote:
>
> In the 4k/4k stack i386 kernel, is there any fundamental reason it
> can't be 4k/8k? We seem to be mostly hitting problems in overflowing
> the IRQ stack... I think. Overhead would only be 4k per CPU for that.
For all of history prior to 2.6.20, there's
Bill Irwin wrote:
> On Wed, Feb 28, 2007 at 09:41:44PM +0100, Andi Kleen wrote:
>> I suppose one could have a CONFIG_DEBUG_STACK_OVERFLOW that gets
>> the stacks from vmalloc which would catch any overflow with its
>> guard pages. This is you would need to change __pa() to handle
>> that too becaus
On Mon, Mar 05, 2007 at 02:18:24AM +0100, Arnd Bergmann wrote:
> On Wednesday 28 February 2007, Chuck Ebbert wrote:
> > Can we just put a canary in the threadinfo and check it on every
> > task switch? What are the drawbacks?
>
> It's not completely reliable, in case of functions that allocate
> f
On Wednesday 28 February 2007, Chuck Ebbert wrote:
> Can we just put a canary in the threadinfo and check it on every
> task switch? What are the drawbacks?
It's not completely reliable, in case of functions that allocate
far too much stack space. You might want to take a look at the
gcc support t
On Wed, Feb 28, 2007 at 09:41:44PM +0100, Andi Kleen wrote:
> I suppose one could have a CONFIG_DEBUG_STACK_OVERFLOW that gets
> the stacks from vmalloc which would catch any overflow with its
> guard pages. This is you would need to change __pa() to handle
> that too because there might be still s
On Feb 28 2007 15:20, Bill Irwin wrote:
>> I don't know about the rest of the world, but halting the system in the
>> case of memory corruption sounds like an extremely good idea to me.
On Thu, Mar 01, 2007 at 12:36:47AM +0100, Jan Engelhardt wrote:
> Just because a rather "unimportant" driver (e.
On Feb 28 2007 15:20, Bill Irwin wrote:
>
>I don't know about the rest of the world, but halting the system in the
>case of memory corruption sounds like an extremely good idea to me.
Just because a rather "unimportant" driver (e.g. parport) might oops
thanks to a now-invalid address after memory
On Wed, Feb 28, 2007 at 09:41:44PM +0100, Andi Kleen wrote:
> Likely already too late then -- if critical state is overwritten
> you crashed before. Also a lot of stack intensive codes
> relatively large unused holes so it might miss the canary completely
> Anyways if you want a crash on context sw
On Wed, Feb 28, 2007 at 09:27:09AM -0500, Chuck Ebbert wrote:
> Can we just put a canary in the threadinfo and check it on every
> task switch? What are the drawbacks?
Likely already too late then -- if critical state is overwritten
you crashed before. Also a lot of stack intensive codes
relativel
I guess most stack corruptions touch only a small part of the stack.
These kinds of corruptions can only be detected from inside the
program.
Anyway, going beyond the program's stack boundaries would fault the program.
Checking the threadinfo constantly it'll be (IMHO) mostly useless...
On 2/2
19 matches
Mail list logo
