[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Oct 2017 00:59:08 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: "Tobin C. Harding" <me@...in.cc>
Cc: kernel-hardening@...ts.openwall.com, "Theodore Ts'o" <tytso@....edu>,
Linus Torvalds <torvalds@...ux-foundation.org>, Kees Cook <keescook@...omium.org>,
Paolo Bonzini <pbonzini@...hat.com>, Tycho Andersen <tycho@...ker.com>,
"Roberts, William C" <william.c.roberts@...el.com>, Tejun Heo <tj@...nel.org>,
Jordan Glover <Golden_Miller83@...tonmail.ch>, Greg KH <gregkh@...uxfoundation.org>,
Petr Mladek <pmladek@...e.com>, Joe Perches <joe@...ches.com>, Ian Campbell <ijc@...lion.org.uk>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Catalin Marinas <catalin.marinas@....com>,
Will Deacon <wilal.deacon@....com>, Steven Rostedt <rostedt@...dmis.org>,
Chris Fries <cfries@...gle.com>, Dave Weinstein <olorin@...gle.com>,
Daniel Micay <danielmicay@...il.com>, Djalal Harouni <tixxdz@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7] printk: hash addresses printed with %p
On Thu, Oct 26, 2017 at 12:27 AM, Tobin C. Harding <me@...in.cc> wrote:
> How good is unlikely()?
It places that branch way at the bottom of the function so that it's
less likely to pollute the icache.
> It doesn't _feel_ right adding a check on every call to printk just to
> check for a condition that was only true for the briefest time when the
> kernel booted. But if unlikely() is good then I guess it doesn't hurt.
>
> I'm leaning towards the option 1, but then all those text books I read
> are telling me to implement the simplest solution first then if we need
> to go faster implement the more complex solution.
>
> This is a pretty airy fairy discussion now, but if you have an opinion
> I'd love to hear it.
I don't think adding a single branch there really matters that much,
considering how many random other branches there are all over the
printk code. However, if you really want to optimize on the little
bits, and sensibly don't want to go with the overcomplex
workqueue-to-statickey thing, you could consider using a plain vanilla
`bool has_gotten_random_ptr_secret` instead of using the atomic_t. The
reason is that there's only ever one single writer, changing from a 0
to a 1. Basically the only thing doing the atomic_t got you was a
cache flush surrounding the read (and the write) so that assigning
has_gotten_random_ptr_secret=true would take effect _immediately_.
However, since you might not necessarily about that, going with a bool
instead will save you an expensive cache flush, while potentially
being a microsecond out of date the first time it's used. Seems like
an okay trade off to me. (That kind of cache latency, also, is a few
orders of magnitude better than using a work queue for the statickey
stuff.)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
