linux-kernel - Re: [RFC][PATCH] tracing/x86: Save CR2 before tracing irqsoff on error

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: <20190321200316.GC2490@worktop.programming.kicks-ass.net>
Date:   Thu, 21 Mar 2019 21:03:16 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Juergen Gross <jgross@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Joel Fernandes <joel@...lfernandes.org>,
        He Zhe <zhe.he@...driver.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Clark Williams <williams@...hat.com>
Subject: Re: [RFC][PATCH] tracing/x86: Save CR2 before tracing irqsoff on
 error_entry

On Thu, Mar 21, 2019 at 03:50:06PM -0400, Steven Rostedt wrote:
> On Thu, 21 Mar 2019 20:31:52 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > > 
> > > No I didn't. Some users only care about performance, but find memory
> > > cheap.  
> > 
> > Because cache-misses are free?
> 
> If I ever did implement this, I would try to get all the data out of
> line as much as possible, where only a nop would be inserted:

Doesn't make sense; you say data, but then talk code and i$.

Not the point, spinlock_t is 4 bytes, but growns into a monster with
lockdep on. There are plenty locations where the spinlock and the data
it protects fit together into a single cacheline, no longer so with
lockdep on.

Another example is split pte locks, without lockdep they are in struct
page, with lockdep, they're a separate allocation, adding pointer
chases.

Also; I do not, and have never done so, understood the desire to have
this unified kernel. Building another kernel just isn't a problem, esp.
not if you're doing kernel development to begin with.

Making debug code complicated, such that you need to spend more time
debugging the debug code, just doens't make sense to me either.