linux-kernel - Re: [GIT PULL] KVM changes for 3.17-rc4

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: <alpine.DEB.2.10.1409052314330.5472@nanos>
Date:	Fri, 5 Sep 2014 23:24:25 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Paolo Bonzini <pbonzini@...hat.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...nel.org>, KVM list <kvm@...r.kernel.org>
Subject: Re: [GIT PULL] KVM changes for 3.17-rc4

On Fri, 5 Sep 2014, Paolo Bonzini wrote:

> Il 05/09/2014 22:58, Thomas Gleixner ha scritto:
> > Nothing new there. Forgot to push out, or perhaps to use "-f" to
> > overwrite the previous tag of the same name?
> 
> It's there now.  Probably a --dry-run too much (I have
> push=+refs/tags/for-linus:refs/tags/for-linus in the remote configuration).
> 
> > And even if there would be something, please do not pull the top most
> > commit b11ba8c62be3eb (KVM: x86: fix kvmclock breakage from timers
> > branch merge).
> > 
> > That one is blantanly wrong and just hacks badly around a brown
> > paperbag bug in the core timekeeping code, which I introduced in the
> > last overhaul.
> 
> It's not wrong, it's just different.  The commit message says clearly

Right, it's different. Because you paper at the receiving end over a
core bug and that's wrong to begin with.

> that besides acting as a workaround, I find the patched code easier to
> understand, and I clearly stated the same in the tag message.

Well, we might have different opinions about easier to understand. I
did go a great length to distangle the monotonic boot time on which
you are interested from xtime, because the latter does not make any
sense outside of the core timekeeping code. Aside of that I optimized
the whole thing to avoid conversions, loops and hoops. So you just add
another multiply and add to make it more understandable. Sigh.

Thanks,

	tglx






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