linux-kernel - Re: static_branch/jump

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: <YIG3I+ojW+bc+o4l@hirez.programming.kicks-ass.net>
Date:   Thu, 22 Apr 2021 19:49:23 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     David Malcolm <dmalcolm@...hat.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        linux-toolchains@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jason Baron <jbaron@...mai.com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        yuanzhaoxiong@...du.com
Subject: Re: static_branch/jump_label vs branch merging

On Thu, Apr 22, 2021 at 12:08:20PM -0500, Segher Boessenkool wrote:
> On Thu, Apr 22, 2021 at 01:48:39PM +0200, Peter Zijlstra wrote:
> > Can we please have a __pure__ attribute that is prescriptive and not a
> > hint the compiler is free to ignore for $raisins ?
> 
> What does that mean?  What actual semantics do you want it to have?

I want a function marked as pure to be treated as such, unconditionally.

> The "pure" attribute means the compiler can assume this function does
> not have side effects.  But in general (and in practice in many cases)
> there is no way the compiler can actually check that, if that is what
> you were asking for.

Right, so currently the pure attribute gets ignored by the compiler
because of various reasons, one of them being an asm volatile ("") being
present somewhere inside it (AFAIU).

This means the compiler will emit multiple calls to the function, which
casuses loss in optimization possibilities; we've had
branch-eleminiation and hoisting as practical examples now.

That is; AFAICT the compiler sees the pure attribute and decides it was
wrongly applied because it cannot tell what the asm is doing; I want
that reversed such that it will assume the asm abides by the pure.

Does this mean we can have invalid code generation when we faultily
mark things pure? Yes, but then it's our own damn fault for sticking on
pure in the first place.

In short; I want pure (or really_pure if you want a second attribute) to
be a do-what-I-tell-you-already and not a
only-if-you-think-you-can-prove-I-didn't-make-a-mistake kinda knob. A
little bit like inline vs always_inline.

> And any such checking will depend on optimisation level and related
> flags, making that a no-go anyway.

Realistically I'm only bothered about -O2 and up since that's what we
build the kernel with. Obviously one doesn't care about optimizations
being lost when build with -O0.