linux-kernel - Re: How to print stack uses of IRQ in ARM64

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] [day] [month] [year] [list]

Date:   Tue, 5 Jun 2018 18:40:43 +0100
From:   James Morse <james.morse@....com>
To:     Vishnu Motghare <vishnumotghare@...il.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: How to print stack uses of IRQ in ARM64

Hi Vishun,

(CC: +linux-arm-kernel list)

On 05/06/18 14:12, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 1:01 PM, Vishnu Motghare
> <vishnumotghare@...il.com> wrote:
>> My understanding is each CPU  getting its own IRQ stack. So is it
>> possible to print the stack uses of each IRQ handler?

The stacks are per-cpu not per-handler, so you would get a jumble of different
interrupt-handlers, mixed up with softirq that runs on the same stack.

>> like, How much stack is used & how much left free ?

What would you do with the information?

>> like in process context we have API like stack_not_used(struct
>> task_struct *p) to get the unused stack  of processes.

Isn't this only printed when the process exits?
When would you print it for an irqstack?

To get this information you would need to mask interrupts, then search backwards
on the irq-stack to find the 'last' value. I think it would always be more
useful to take interrupts in that time...

>> So, is it possible to get the similar result for IRQ?

Probably, but I don't think its useful.
If you're debugging a stack-overflow, its much better to use vmap stacks, which
will give you the function and stack trace that triggered the overflow.

Thanks,

James