linux-kernel - Re: [GIT PULL] compiler/gcc4: Add quirk for 'asm goto' miscompilation bug

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFys_VK+q3LMRzEM-AKU-=fM_tgiDdLm2AO=jVfH7OvrHQ@mail.gmail.com>
Date:	Wed, 12 Feb 2014 20:11:49 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Noonan <steven@...inklabs.net>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jakub Jelinek <jakub@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Richard Henderson <rth@...ddle.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] compiler/gcc4: Add quirk for 'asm goto' miscompilation bug

On Wed, Feb 12, 2014 at 7:09 PM, Steven Noonan <steven@...inklabs.net> wrote:
>
> If I change the GCC_VERSION check for the asm_volatile_goto quirk to
> include 4.8.2, then KVM guests are properly cleaned up.

Ok, I guess that means we should just make the quirk unconditional.

Ingo, do you want to do that or should I?

> So is there some other 'asm goto' bug we haven't yet fully uncovered
> and reported to GCC upstream?

Not to my knowledge. But I'm sure Jakub&co would love to have a test-case.

Sadly, gcc has that really annoying habit of making small changes
create *huge* changes in label numbers etc, and that's definitely the
case with the extra empty asm - it's basically impossible to compare
the generated asm with and without the workaround, because all the
label numbers change.

I have no idea how gcc people debug things like this, when the output
is so unstable.

Jakub, any suggestions to how Steven might be able to pinpoint where
the code generation problem lies?

                Linus
--
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/