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: <20190321161151.0d10b6d7@gandalf.local.home>
Date:   Thu, 21 Mar 2019 16:11:51 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.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, 21 Mar 2019 21:03:16 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

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

Ah, you meant d$

> 
> 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.

It's not for the typical kernel developer like you and me. It's about
shipping to the customers. Shipping multiple kernels is a pain. Lockdep
has some features that can be used in production environments, like
seeing lock contention and irq latency. Most of that code is dependent
on lockdep. Having just tracing of locks and such would be useful. But
that also relies heavily on the lockdep infrastructure.

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

Perhaps this can also help clean it up, and organize it. Sometimes
adding features makes the code cleaner (see what RT has done to the
kernel).

-- Steve