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: <f933eae5-7c48-8a1d-c748-a99f29acee2a@redhat.com>
Date:   Wed, 29 Mar 2017 11:47:30 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Christian Borntraeger <borntraeger@...ibm.com>,
        James Hogan <james.hogan@...tec.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Cornelia Huck <cornelia.huck@...ibm.com>,
        linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
        Fan Zhang <zhangfan@...ux.vnet.ibm.com>,
        Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: linux-next: manual merge of the kvms390 tree with the kvm-mips
 tree



On 29/03/2017 11:29, Christian Borntraeger wrote:
>>>  -#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?

Yes, that can be expected.  If you don't do it, I'll bump the capability
number as soon as I get the conflict.

If it's an issue, the solution is topic branches: as soon as you need a
capability, fire a pull request so that it gets in kvm/next.  But it
doesn't happen too often, the last times were in 4.1, 4.6 and 4.8 (three
times in 2 years).

>> Alternatively does it make sense to have different ranges reserved for
>> different architectures (like the get one reg numbers)?
> 
> I can live with a changing GS capability number, so keep your number.
> In the end I think Radim/Paolo will do the assigment when merging.

Yes---and in that case it's first come first served.

Same for ioctls, though those change even more rarely.

Paolo

> And no userspace should rely on this before this is at least in kvm/next
> Yes, this will be a bit of pain for internal QA, but this worked ok
> for the last 3 or 4 years on our side