linux-kernel - Re: linux-next: manual merge of the kvm tree with the kvm 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]

Date:   Thu, 16 Dec 2021 15:47:12 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     broonie@...nel.org, Paolo Bonzini <pbonzini@...hat.com>,
        KVM <kvm@...r.kernel.org>
Cc:     Alexey Kardashevskiy <aik@...abs.ru>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        "Maciej S . Szmigiero" <maciej.szmigiero@...cle.com>,
        Sean Christopherson <seanjc@...gle.com>
Subject: Re: linux-next: manual merge of the kvm tree with the kvm tree

broonie@...nel.org writes:
> Hi all,
>
> Today's linux-next merge of the kvm tree got a conflict in:
>
>   arch/powerpc/kvm/book3s_hv.c
>
> between commit:
>
>   511d25d6b789f ("KVM: PPC: Book3S: Suppress warnings when allocating too big memory slots")
>
> from the kvm tree and commits:

That's from the powerpc tree.

>   537a17b314930 ("KVM: Let/force architectures to deal with arch specific memslot data")
>   eaaaed137eccb ("KVM: PPC: Avoid referencing userspace memory region in memslot updates")
>
> 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.

Thanks.

Paolo, if you want to avoid the conflict going to Linus, I have that
commit (and others) in a topic branch here (based on rc2):

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/ppc-kvm


cheers


> diff --cc arch/powerpc/kvm/book3s_hv.c
> index f64e45d6c0f4c,51e1c29a6fa08..0000000000000
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@@ -4866,21 -4854,17 +4866,22 @@@ static void kvmppc_core_free_memslot_hv
>   }
>   
>   static int kvmppc_core_prepare_memory_region_hv(struct kvm *kvm,
> - 					struct kvm_memory_slot *slot,
> - 					const struct kvm_userspace_memory_region *mem,
> - 					enum kvm_mr_change change)
> + 				const struct kvm_memory_slot *old,
> + 				struct kvm_memory_slot *new,
> + 				enum kvm_mr_change change)
>   {
> - 	unsigned long npages = mem->memory_size >> PAGE_SHIFT;
> - 
>   	if (change == KVM_MR_CREATE) {
> - 		unsigned long size = array_size(npages, sizeof(*slot->arch.rmap));
>  -		new->arch.rmap = vzalloc(array_size(new->npages,
>  -					  sizeof(*new->arch.rmap)));
> ++		unsigned long size = array_size(new->npages,
> ++						sizeof(*new->arch.rmap));
>  +
>  +		if ((size >> PAGE_SHIFT) > totalram_pages())
>  +			return -ENOMEM;
>  +
> - 		slot->arch.rmap = vzalloc(size);
> - 		if (!slot->arch.rmap)
> ++		new->arch.rmap = vzalloc(size);
> + 		if (!new->arch.rmap)
>   			return -ENOMEM;
> + 	} else if (change != KVM_MR_DELETE) {
> + 		new->arch.rmap = old->arch.rmap;
>   	}
>   
>   	return 0;