linux-kernel - Re: [GIT PULL (sort of)] KVM: x86: fixes and selftests fixes/cleanups

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: <CABgObfbQqVOsH0imHWc938n48TdkD8xFPO4CnwS0EM4oQZAxog@mail.gmail.com>
Date: Wed, 14 Feb 2024 18:35:12 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL (sort of)] KVM: x86: fixes and selftests fixes/cleanups

On Tue, Feb 13, 2024 at 1:57 AM Sean Christopherson <seanjc@...gle.com> wrote:
>
> I have two pull requests for 6.8, but I goofed (or maybe raced with you
> pushing to kvm/master), and based everything on 6.8-rc2 instead of 6.8-rc1 as
> you did.  And so of course the pull requests would bring in waaaaay more than
> just the intended KVM changes.
>
> Can I bribe you to do a back merge of 6.8-rc2, so that my pull requests don't
> make me look like a complete idiot?

Ignoring the fact that kvm/master is currently a subset of Linus's
tree (so I can just fast forward to -rc4 before merging your stuff),
that's absolutely not a problem and it happens all the time during the
merge window. The way to handle that is to forge the diffstat in the
pull request, replacing it with the diffstat of the test merge commit
that I do anyway. It's a known issue with git-request-pull and pretty
much all maintainers do it.

But for -rc pull requests what I do is just base the PR on the latest
-rc, and in fact I've started doing something similar recently since I
have very few commits of my own in kvm/next. I always start with a
very late -rc and merge in all the topic branches one by one. Instead
of starting from kvm/next, I checkout -rc6 or so, then merge in the
contents of kvm/next with a "Merge branch 'kvm-6.9-paolo" commit
message (important: git sees this as a fast forward!!), and then apply
submaintainer trees on top. This results in no back merges, and it's
only cheating a little bit.

> It's not the end of the world for me to rebase, but I'd prefer not to throw
> away the hashes and the time the commits have spent in -next.
>
> FWIW, the two tags are:
>
>  https://github.com/kvm-x86/linux.git tags/kvm-x86-fixes-6.8-rcN
>  https://github.com/kvm-x86/linux.git tags/kvm-x86-selftests-6.8-rcN

Pulled (but not pushed), thanks.

Paolo