linux-kernel - Re: [PATCH] x86: Optimize variable_test

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: <20150501161654.GI5029@twins.programming.kicks-ass.net>
Date:	Fri, 1 May 2015 18:16:54 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	Jakub Jelinek <jakub@...hat.com>
Subject: Re: [PATCH] x86: Optimize variable_test_bit()

On Fri, May 01, 2015 at 09:03:32AM -0700, Linus Torvalds wrote:
> On Fri, May 1, 2015 at 8:16 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > Since test_bit() doesn't actually have any output variables, we can use
> > asm goto without having to add a memory clobber. This reduces the code
> > to something sensible:
> 
> Yes, looks good, except if we have anything that actually wants to use
> the value rather than branch on it. But a quick grep seems to show
> that the vast majority of them are all about just directly testing the
> result.
> 
> It worries me a bit that gcc now cannot pick the likely branch any
> more. It will always branch out for the bit being set. So code like
> this:
> 
>     net/core/dev.c:         if
> (likely(!test_bit(__QDISC_STATE_DEACTIVATED, &q->state)))
> 
> wouldn't work, but almost all of those seem to be the constant case
> that doesn't get to this anyway.

Ah yes, that's another thing we've previously discussed with the GCC
people (IIRC). The GCC manual states you can use hot and cold attributes
on the labels (although when we tested that it didn't actually work, it
might now). But that's no good if the hint is one (or more) layer up
from the asm goto.

If would indeed be very good if the likely/unlikely thing would work as
expected.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/