[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdnyFGWLpyBWX1nAY4veQucmzL509XqfqHj896hS+YJfYw@mail.gmail.com>
Date: Thu, 15 Oct 2020 13:59:00 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: Maninder Singh <maninder1.s@...sung.com>,
Jian Cai <caij2003@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Marc Zyngier <maz@...nel.org>,
Valentin Schneider <valentin.schneider@....com>,
Vincent Whitchurch <vincent.whitchurch@...s.com>,
Nathan Huckleberry <nhuck@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Dmitry Safonov <0x7f454c46@...il.com>,
Will Deacon <will@...nel.org>, a.sahrawat@...sung.com,
v.narang@...sung.com,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] IRQ stack support for ARM
On Thu, Oct 8, 2020 at 1:30 AM Russell King - ARM Linux admin
<linux@...linux.org.uk> wrote:
>
> On Thu, Oct 08, 2020 at 12:45:30PM +0530, Maninder Singh wrote:
> > Observed Stack Overflow on 8KB kernel stack on ARM specially
> > incase on network interrupts, which results in undeterministic behaviour.
> > So there is need for per cpu dedicated IRQ stack for ARM.
> >
> > As ARm does not have extra co-processor register
> > to save thread info pointer, IRQ stack will be at some
> > performance cost, so code is under CONFIG_IRQ_STACK.
> >
> > and we don't have much knowledge and set up for CLANG
> > and ARM_UNWIND, so dependency added for both cases.
> >
> > Tested patch set with QEMU for latest kernel
> > and 4.1 kernel for ARM target with same patch set.
>
> You need to investigate and show where and why this is happening. My
> guess is you have a network driver that uses a lot of kernel stack
> space, which itself would be a bug.
>
> Note that there are compiler versions out there that mis-optimise and
> eat stack space - the kernel build should be warning if a function
> uses a large amount of stack.
For tracking down those not-super-helpful compiler warnings, I wrote a
tool where if you rebuild with debug info, and give it the object file
and string of the function the compiler warned about it will parse the
DWARF to tell you the size of each local variable, and if it came from
an inline frame. Generally, it's possible to stack allocate something
that's way too big; instead those should be allocated on the heap.
https://github.com/ClangBuiltLinux/frame-larger-than
(I haven't had time to sit down and use it to resolve all outstanding
issues, but it has worked well for me in the past)
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists