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
| ||
|
Date: Mon, 13 Nov 2017 16:37:06 +1100 From: Stephen Rothwell <sfr@...b.auug.org.au> To: Michael Ellerman <mpe@...erman.id.au>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, PowerPC <linuxppc-dev@...ts.ozlabs.org> Cc: Mark Brown <broonie@...nel.org>, David Gibson <david@...son.dropbear.id.au>, Greg Kurz <groug@...d.org>, Thomas Huth <thuth@...hat.com>, Paul Mackerras <paulus@...abs.org>, Linux-Next Mailing List <linux-next@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: linux-next: manual merge of the powerpc tree with Linus' tree Hi all, On Mon, 30 Oct 2017 12:51:33 +0000 Mark Brown <broonie@...nel.org> wrote: > > Hi all, > > Today's linux-next merge of the powerpc tree got a conflict in: > > arch/powerpc/kvm/powerpc.c > > between commit: > > ac64115a66c1 ("KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM") > > from Linus' tree and commit: > > 2a3d6553cbd7 ("KVM: PPC: Tie KVM_CAP_PPC_HTM to the user-visible TM feature") > > from the powerpc tree. > > 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. > > diff --cc arch/powerpc/kvm/powerpc.c > index ee279c7f4802,a3746b98ec11..000000000000 > --- a/arch/powerpc/kvm/powerpc.c > +++ b/arch/powerpc/kvm/powerpc.c > @@@ -644,7 -644,8 +644,8 @@@ int kvm_vm_ioctl_check_extension(struc > break; > #endif > case KVM_CAP_PPC_HTM: > - r = cpu_has_feature(CPU_FTR_TM_COMP) && hv_enabled; > - r = is_kvmppc_hv_enabled(kvm) && > ++ r = hv_enabled && > + (cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_HTM_COMP); > break; > default: > r = 0; Just a reminder that this conflict still exists. -- Cheers, Stephen Rothwell
Powered by blists - more mailing lists