From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751871AbeFERny (ORCPT ); Tue, 5 Jun 2018 13:43:54 -0400 Received: from foss.arm.com ([217.140.101.70]:59546 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788AbeFERnx (ORCPT ); Tue, 5 Jun 2018 13:43:53 -0400 Subject: Re: How to print stack uses of IRQ in ARM64 To: Vishnu Motghare Cc: Andy Shevchenko , Linux Kernel Mailing List , Marc Zyngier , "linux-arm-kernel@lists.infradead.org" References: From: James Morse Message-ID: <9686668a-2739-309d-fb02-55c8fd2b802d@arm.com> Date: Tue, 5 Jun 2018 18:40:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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