linux-kernel - Re: [GIT PULL] First batch of KVM changes for 4.1

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] [day] [month] [year] [list]

Message-ID: <20150423170617.GC7482@amt.cnet>
Date:	Thu, 23 Apr 2015 14:06:17 -0300
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...nel.org>, kvm list <kvm@...r.kernel.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Andrew Lutomirski <luto@...nel.org>
Subject: Re: [GIT PULL] First batch of KVM changes for 4.1

On Thu, Apr 23, 2015 at 02:02:29PM +0200, Paolo Bonzini wrote:
> 
> 
> On 23/04/2015 13:51, Marcelo Tosatti wrote:
> >>> > > https://bugzilla.redhat.com/show_bug.cgi?id=1174664
> >> > 
> >> > That was the missing volatile in an asm.  Older compilers didn't catch
> >> > it. :(
> > How do you know that? It looks like memory corruption (look at the
> > pattern at the end).
> 
> I suspect some kind of operator error there, it makes no sense.


        if (unlikely(s->flags & SLAB_POISON))
                memset(start, POISON_INUSE, PAGE_SIZE << order);

 *      Padding is done using 0x5a (POISON_INUSE)

> On the other hand, bug 1178975 is much clearer and the symptoms are the
> same.  In that bug, you can see that the same kernel source works on f20
> (package version 3.17.7-200.fc20.x86_64) and fails on f21 (package
> version 3.17.7-300.fc21.x86_64).  Of course the compiler is different.
> The newer one hoists the lsl out of the loop; if you get a CPU migration
> at the wrong time, the cpu != cpu1 condition will always be true the
> loop will never exit.
> 
> Paolo
--
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/