linux-kernel - Re: [GIT PULL] KVM, AMD PSP and ARM CoreSight changes for 5.13 merge window

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]

Date:   Mon, 3 May 2021 11:16:51 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     torvalds@...ux-foundation.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kvm@...r.kernel.org, Marc Zyngier <maz@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [GIT PULL] KVM, AMD PSP and ARM CoreSight changes for 5.13 merge window

On Mon, 3 May 2021 at 10:09, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> On 03/05/21 17:25, Mathieu Poirier wrote:
> >> Mathieu, can you confirm that your coresight branch will*not*  be sent by
> >> the ARM maintainers as well?
> > Confirmed.  Marc's tree is the only place where the ETE-TRBE functionality has
> > been added.  It was specifically done that way to avoid having the same code in
> > multiple branches and prevent merge conflicts.
>
> Thanks for confirming!
>
> Generally, what we do for x86 is exactly the opposite: the basic
> functionality is committed to the x86 tree, and then merged in _also_ by
> myself.  For example, this pull request includes a topic branch provided
> by the cgroup maintainer and one provided by the x86 maintainers, but in
> both cases they _also_ sent exactly the same commits to Linus.

The above works if all subsystems are pulled-in directly by Linus.
But for CoreSight patches flow through Greg's char-misc tree, which
would not have worked for the ETR-TRBE patchset due to dependencies
with the KVM/ARM tree.  As such I don't think we could have done
things differently.

>
> It works well because git is pretty good at avoiding conflicts when the
> same branch is present in multiple branches.  Instead, cherry-picking
> introduces lots of merge conflicts.
>
> There are other advantages in doing that.  For example, in this case I
> didn't (and don't) quite know what ETE and TRBE are, beyond what a quick
> Internet search tells me.  Sending this functionality to an ARM
> maintainer that is more acquainted with the feature would ensure that
> the new functionality is documented properly in the tags and therefore
> in the commit messages.
>
> This is what Linux was mentioning when he said "Pull requests need to
> have explanations of what they pull - not just because it needs to go
> into the merge message, but because the maintainer needs to keep track
> of what's happening".  In this case, the maintainer was me; based on my
> own workflow and due to the lack of commit message I assumed that the
> branch was also going to go through the ARM tree (and doubted my
> assumption only when sending the pull request to Linus, i.e. way too late).
>
> I am also guilty as charged of the "Merge branch 'kvm-sev-cgroup' into
> HEAD" commit message, where I should have pointed out that Tejun had a
> later branchpoint from 5.12-rc than I did, resulting in conflicts.
>
> So Marc, let's heed Linus's advice and document all topic branches that
> we merge into the KVM/ARM and KVM/x86 trees, including whether they also
> go into other trees---which they should do almost all the time.
>
> Thanks,
>
> Paolo
>
> > Let me know if you need more information.
>