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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 18 Dec 2020 10:31:52 +0000 From: Catalin Marinas <catalin.marinas@....com> To: Stephen Rothwell <sfr@...b.auug.org.au> Cc: Paolo Bonzini <pbonzini@...hat.com>, KVM <kvm@...r.kernel.org>, Will Deacon <will@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux Next Mailing List <linux-next@...r.kernel.org>, Marc Zyngier <maz@...nel.org> Subject: Re: linux-next: manual merge of the kvm tree with the arm64-fixes tree On Fri, Dec 18, 2020 at 01:47:39PM +1100, Stephen Rothwell wrote: > Today's linux-next merge of the kvm tree got a conflict in: > > arch/arm64/include/asm/kvm_asm.h > > between commit: > > 9fd339a45be5 ("arm64: Work around broken GCC 4.9 handling of "S" constraint") > > from the arm64-fixes tree and commit: > > b881cdce77b4 ("KVM: arm64: Allocate hyp vectors statically") > > from the kvm 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. > > -- > Cheers, > Stephen Rothwell > > diff --cc arch/arm64/include/asm/kvm_asm.h > index 8e5fa28b78c2,7ccf770c53d9..000000000000 > --- a/arch/arm64/include/asm/kvm_asm.h > +++ b/arch/arm64/include/asm/kvm_asm.h > @@@ -198,14 -199,6 +199,12 @@@ extern void __vgic_v3_init_lrs(void) > > extern u32 __kvm_get_mdcr_el2(void); > > - extern char __smccc_workaround_1_smc[__SMCCC_WORKAROUND_1_SMC_SZ]; > - > +#if defined(GCC_VERSION) && GCC_VERSION < 50000 > +#define SYM_CONSTRAINT "i" > +#else > +#define SYM_CONSTRAINT "S" > +#endif > + > /* > * Obtain the PC-relative address of a kernel symbol > * s: symbol Thanks Stephen, it looks fine. I'll send a pull request later today with this commit but it's simple enough for Linus to fix it. -- Catalin
Powered by blists - more mailing lists