linux-kernel - Re: [PATCH] smp: generic ipi

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: <20200520135156.GO317569@hirez.programming.kicks-ass.net>
Date:   Wed, 20 May 2020 15:51:56 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Wojciech Kudla <wk.kernel@...il.com>
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Nadav Amit <namit@...are.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] smp: generic ipi_raise tracepoint

On Wed, May 20, 2020 at 02:42:10PM +0100, Wojciech Kudla wrote:
> On 20/05/2020 14:33, Peter Zijlstra wrote:
> > We have bright shiny links like: https://lkml.kernel.org/r/$MSG-ID for
> > that. they allow me to go find the email in my local archive without
> > having to use a browser.
> 
> Apologies, beginner's mistake.
> 
> >> +static const char *ipi_reason_missing __tracepoint_string = "";
> > 
> > That is a pretty crap reason ;-)
> > 
> 
> I knew this was a long shot. There is no obvious way to 
> get/infer ipi reason in generic smp code at the moment.
> Any suggestions what we can put here in the meantime?
> Would "none" be more appropriate?

Depends a bit on what you actually want to achieve here.

For actual proper debugging this stuff I think I'd find it more useful
to have tracepoints one level up. So instead of tracing the IPIs, trace
the actual remote function call requests.

And in that case, trace the mask and the symbol name from csd->func.

And if you have that, who cares about the actual IPIs.