linux-kernel - Re: linux-next: manual merge of the kvm tree with the powerpc tree

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: <4a43b8ed-bd08-f8e8-e749-178bb3bac815@redhat.com>
Date:   Tue, 14 Feb 2017 14:34:01 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Gleb Natapov <gleb@...nel.org>, KVM <kvm@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        PowerPC <linuxppc-dev@...ts.ozlabs.org>
Cc:     linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paul Mackerras <paulus@...abs.org>,
        Nicholas Piggin <npiggin@...il.com>
Subject: Re: linux-next: manual merge of the kvm tree with the powerpc tree



On 14/02/2017 09:45, Michael Ellerman wrote:
>> If possible, please pull only up to "powerpc/64: Allow for relocation-on
>> interrupts from guest to host" and cherry-pick the top two patches
>> ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
>> "powerpc/powernv: Remove separate entry for OPAL real mode calls") into
>> your next branch, but leave the rest for my tree only.
>
> I don't see how that helps anything.
> 
> In fact it guarantees a mess because those two commits would now go to
> Linus via my tree (cherry picked) and via Paul's as part of his second
> merge of the topic branch.
>
> So unless you can give me a good reason I'll merge the tip of the topic
> branch into my next, as planned.

Yes, Paul's second merge did guarantee a mess, so go ahead.

However, the reason was that this is simply not how topic branches
should work: topic branches should be the base for other work, they
shouldn't contain _all_ the work.  So the right workflow would have been:

- Paul submits topic branch A to you

- you merge A

- Paul merges topic branch A into his "next" branch

- Paul applies KVM-specific patches B1 on top of his "next" branch.

- Paul sends pull request to me (with A + kvmppc work).

As far as I understand, there was no reason for you to get B1.

The last two patches (let's call them B2) also didn't need to go through
the kvm-ppc branch at all.  You could have applied them directly on top
of A.  Linus then would get A and B2 from you, and A and B1 from me:

                  base -→ A -----→ B1
                          ↓        ↓
                   ppc -→ ▪        ▪ ←- kvm
                          ↓        |
                          B2       |
                          ↓        ↓
                      torvalds/linux.git


If necessary, things could have been arranged so that Linus got A and B2
from you, and all three of A/B1/B2 from me:

- Paul submits topic branch B2 to you, based on topic branch A

- you merge B2

- Paul merges B2 and I get it from him

The result would have been:

                  base -→ A -----→ B1
                          ↓ ↘      ↓
                   ppc -→ ▪   B2 → ▪
                          ↓ ↙      ↓
                          ▪        ▪ ←- kvm
                          ↓        ↓
                      torvalds/linux.git

Paolo