linux-kernel - Re: stack overflow on Sparc64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0806201824190.25997@engineering.redhat.com>
Date:	Fri, 20 Jun 2008 18:33:06 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	David Miller <davem@...emloft.net>
cc:	sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
	agk@...hat.com
Subject: Re: stack overflow on Sparc64



On Fri, 20 Jun 2008, David Miller wrote:

> From: Mikulas Patocka <mpatocka@...hat.com>
> Date: Fri, 20 Jun 2008 17:25:26 -0400 (EDT)
>
>> On Fri, 20 Jun 2008, David Miller wrote:
>>
>>> From: Mikulas Patocka <mpatocka@...hat.com>
>>> Date: Fri, 20 Jun 2008 17:14:41 -0400 (EDT)
>>>
>>> It means i386 and every other platform potentially has the same exact
>>> problem.
>>>
>>> What point wrt. sparc64 are you trying to make here? :-)
>>
>> The difference is that i386 takes minimum 4 bytes per stack frame and
>> sparc64 192 bytes per stack frame. So this problem will kill sparc64
>> sooner.
>>
>> But yes, it is general problem and should be solved in arch-independent
>> code.
>
> I agree on both counts.  Although I'm curious what the average stack
> frame sizes look like on x86_64 and i386, and also how this area
> appears on powerpc.

If I look at an old oops that I have in my log on i386: it's 1104 stack 
bytes ~ 38 functions.

> One mitigating factor on sparc64 is that typically when there are lots
> of devices with interrupts there are also lots of cpus, and we evenly
> distribute the IRQ targetting amongst the available cpus on sparc64.
>
> This is probably why, in practice, these problems tend to not surface
> often.
>
> In any event, with the work you've accomplished and my implementation
> of IRQ stacks for sparc64 we should be able to get things in much
> better shape.

I created this to help with nested irqs:
--- linux-2.6.26-rc5-devel.orig/include/linux/interrupt.h       2008-06-20 
23:34:04.000000000 +0200
+++ linux-2.6.26-rc5-devel/include/linux/interrupt.h    2008-06-20 
23:36:03.000000000 +0200
@@ -95,7 +95,7 @@
  #ifdef CONFIG_LOCKDEP
  # define local_irq_enable_in_hardirq() do { } while (0)
  #else
-# define local_irq_enable_in_hardirq() local_irq_enable()
+# define local_irq_enable_in_hardirq() do { if (hardirq_count() <= (1 << 
HARDIRQ_SHIFT)) local_irq_enable(); } while (0)
  #endif

  extern void disable_irq_nosync(unsigned int irq);

Mikulas
--
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/