From mboxrd@z Thu Jan 1 00:00:00 1970 From: valdis.kletnieks@vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 16 Nov 2018 06:33:08 -0500 Subject: [ARM64] Printing IRQ stack usage information In-Reply-To: References: <28496.1542300549@turing-police.cc.vt.edu> Message-ID: <49219.1542367988@turing-police.cc.vt.edu> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Fri, 16 Nov 2018 11:44:36 +0530, Pintu Agarwal said: > > If your question is "Did one > > of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better > > approaches. > > > Yes, exactly, this is what the main intention. > If you have any better idea about this approach, please refer me. > It will be of great help. Look at the code controlled by '#ifdef CONFIG_DEBUG_STACK_USAGE' which does the same thing for process stacks, or CONFIG_SCHED_STACK_END_CHECK or the use of guard pages for detecting stack overrun.... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omr1.cc.ipv6.vt.edu ([2607:b400:92:8300:0:c6:2117:b0e] helo=omr1.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gNcNB-0007Nz-VY for kernelnewbies@kernelnewbies.org; Fri, 16 Nov 2018 06:33:18 -0500 Received: from mr1.cc.vt.edu (junk.cc.ipv6.vt.edu [IPv6:2607:b400:92:9:0:9d:8fcb:4116]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id wAGBXGtV004067 for ; Fri, 16 Nov 2018 06:33:16 -0500 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by mr1.cc.vt.edu (8.14.7/8.14.7) with ESMTP id wAGBXBD5017908 for ; Fri, 16 Nov 2018 06:33:16 -0500 Received: by mail-qk1-f198.google.com with SMTP id s70so51429932qks.4 for ; Fri, 16 Nov 2018 03:33:16 -0800 (PST) From: valdis.kletnieks@vt.edu To: Pintu Agarwal Subject: Re: [ARM64] Printing IRQ stack usage information In-reply-to: References: <28496.1542300549@turing-police.cc.vt.edu> Mime-Version: 1.0 Date: Fri, 16 Nov 2018 06:33:08 -0500 Message-ID: <49219.1542367988@turing-police.cc.vt.edu> Cc: mark.rutland@arm.com, Jungseok Lee , kernelnewbies@kernelnewbies.org, catalin.marinas@arm.com, Sungjinn Chung , will.deacon@arm.com, open list , Russell King - ARM Linux , Takahiro Akashi , linux-arm-kernel@lists.infradead.org List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Message-ID: <20181116113308.GaadVmzd77wlogiovoZnaC1qe-PT_J699jYDUdtY-kM@z> On Fri, 16 Nov 2018 11:44:36 +0530, Pintu Agarwal said: > > If your question is "Did one > > of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better > > approaches. > > > Yes, exactly, this is what the main intention. > If you have any better idea about this approach, please refer me. > It will be of great help. Look at the code controlled by '#ifdef CONFIG_DEBUG_STACK_USAGE' which does the same thing for process stacks, or CONFIG_SCHED_STACK_END_CHECK or the use of guard pages for detecting stack overrun.... _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies