linux-kernel - Re: [ARM64] Printing IRQ stack usage information

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: <28496.1542300549@turing-police.cc.vt.edu>
Date:   Thu, 15 Nov 2018 11:49:09 -0500
From:   valdis.kletnieks@...edu
To:     Pintu Agarwal <pintu.ping@...il.com>
Cc:     open list <linux-kernel@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        kernelnewbies@...nelnewbies.org, jungseoklee85@...il.com,
        catalin.marinas@....com, will.deacon@....com,
        takahiro.akashi@...aro.org, mark.rutland@....com,
        barami97@...il.com
Subject: Re: [ARM64] Printing IRQ stack usage information

On Thu, 15 Nov 2018 18:52:39 +0530, Pintu Agarwal said:

> Currently, when I tested this (as a proc interface), I got the below output:
> CPU    UNUSED-STACK    ACTUAL-STACK
>  0         16368                     16384

> 3) How should I test it to get the different usage values for unused stack ?
>     Can I get these values by implementing a sample interrupt handler,
> and printing information from there?

Hint 1:  If you're in a state where seq_printf() is legal, how many IRQ's are
on this processor's IRQ stack?

Hint 2:  What are the chances that some other CPU is currently in an IRQ?
(run 'top' and look for what percent of time that's happening)

Hint 3: what are the chances that the value of irq_stack_ptr is already stale
by the time seq_printf() finishes running?

Hint 4: what happens to the validity of your output if you get rescheduled
in the middle of that for_each loop?

(In other words, this code is terribly racy and is probably not going to answer
whatever debugging question you were working on..  If your question is "Did one
of the CPUs blow out its IRQ stack (or come close to doing so)?" there's better
approaches.

Content of type "application/pgp-signature" skipped