KVM fix for 3.1-rc5

Linus, please pull from

git://github.com/avikivity/kvm.git kvm-updates/3.1

to receive a fix for a build failure due to a missing instruction size suffix in inline assembly.

Duncan Sands (1):
KVM: Fix instruction size issue in pvclock scaling

 arch/x86/include/asm/pvclock.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

error compiling committee.c: too many arguments to function

Again, please give me a warm and fuzzy feeling that this is really Avi, and the right thing to do, rather than just a "please pull from this random tree".

It's not that I don't think you are you, but I want people to actually *think* about what they are doing and sending me. When you give me a kernel.org address, I know you have access to kernel.org, and that makes me believe you are you. When you give me a github address, that doesn't really mean anything.

Linus

To your point, I would think you want that regardless. I certainly don't mean to pile on the kernel.org guys, but it was compromised and likely through a user account. I'm confident that this is a very rare occurrence, but it can happen again. There was another somewhat high profile hack earlier in the year against vendor-sec as well.

Maybe asking for some extra warm fuzzies from now on wouldn't be a horrible idea as general practice.

I will now await a reply full of the cold pricklies.

josh

I think that realistically we should definitely look at our practices, but at the same time, I personally do put a lot of trust in "human relationships".

Often way more than "technical models".

So there is a lot of safety in just a purely human "this looks like the kind of pull request I expect". A lot of kernel developers write nice messages explaining the pull, and there may not be a cryptographic signature in text like that, but there is definitely a "human signature" that you start to expect.

So one of the reasons I react to the github pulls is that even though I'm actually pretty damn certain they are all the people they purport to be, the "expected signature" is kind of missing. That's especially true with a pull request that has just the minimal technically required information - that is 99% script-generated to begin with.

Put another way: I'm not necessarily looking for cryptography. A reply to a personal email of mine (that didn't go out to any mailing list) is already a *much* stronger sign of identity: the person having access to their email account. And once I know that yes, that github repository was really set up by Xyz, then getting a pull request from that is already much more sane and safe.

Linus

Yup, it's the genuine thing here, and the s/mul/mulq/ is not an incredibly clever backdoor.

Well, these days access to kernel.org proves a lot less than it used to, unfortunately.

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Hi,

How comes that companies who directly participate in the kernel development[0] cannot setup servers that would host trees of their employee ? In which case, kernel.org would just be a mirror for those tree.

Thanks,
- Arnaud

[0]: from the top of my mind, RedHat, SuSe/Novell, Canonical, IBM, Intel, ...