linux-kernel - Re: linux-next: manual merge of the kvms390 tree with the kvm-mips 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: <20170329092112.GV31606@jhogan-linux.le.imgtec.org>
Date:   Wed, 29 Mar 2017 10:21:12 +0100
From:   James Hogan <james.hogan@...tec.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
CC:     Christian Borntraeger <borntraeger@...ibm.com>,
        Cornelia Huck <cornelia.huck@...ibm.com>,
        <linux-next@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Fan Zhang <zhangfan@...ux.vnet.ibm.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: linux-next: manual merge of the kvms390 tree with the kvm-mips
 tree

On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   include/uapi/linux/kvm.h
> 
> between commits:
> 
>   a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
>   578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
> 
> from the kvm-mips tree and commit:
> 
>   4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
> 
> from the kvms390 tree.
> 
> It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc include/uapi/linux/kvm.h
> index 1e1a6c728a18,c9d522765f8f..000000000000
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt 
>   #define KVM_CAP_PPC_MMU_RADIX 134
>   #define KVM_CAP_PPC_MMU_HASH_V3 135
>   #define KVM_CAP_IMMEDIATE_EXIT 136
>  -#define KVM_CAP_S390_GS 137
>  +#define KVM_CAP_MIPS_VZ 137
>  +#define KVM_CAP_MIPS_TE 138
>  +#define KVM_CAP_MIPS_64BIT 139
> ++#define KVM_CAP_S390_GS 140
>   
>   #ifdef KVM_CAP_IRQ_ROUTING

Thanks Stephen,

Cc'ing Paulo and Radim.

This does seem a bit of a conflict magnet, and they're part of the user
ABI so when the values change upon merge, the intermediate versions
before and after require different userland builds.

Should the numbering be decided in advance somehow (i.e. in response to
conflicts in linux-next)? I don't particularly want to change the
numbering again as others would need rebuilds again, but I only just
pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
can we expect other branches to continue at 141 so I don't need to
change them again?

Alternatively does it make sense to have different ranges reserved for
different architectures (like the get one reg numbers)?

Cheers
James

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)