linux-kernel - Re: [PATCH v3 2/2] KVM: s390: fix for hugepage vmalloc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1623634582.4gf5ql7njz.astroid@bobo.none>
Date:   Mon, 14 Jun 2021 11:43:09 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        linux-kernel@...r.kernel.org
Cc:     Andrew Morton <akpm@...ux-foundation.org>, borntraeger@...ibm.com,
        Catalin Marinas <catalin.marinas@....com>, cohuck@...hat.com,
        david@...hat.com, frankja@...ux.ibm.com,
        Christoph Hellwig <hch@...radead.org>, kvm@...r.kernel.org,
        linux-mm@...ck.org, linux-s390@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Uladzislau Rezki <urezki@...il.com>
Subject: Re: [PATCH v3 2/2] KVM: s390: fix for hugepage vmalloc

Sorry, catching up with email, I should have replied here originally.

Excerpts from Claudio Imbrenda's message of June 11, 2021 1:42 am:
> The Create Secure Configuration Ultravisor Call does not support using
> large pages for the virtual memory area. This is a hardware limitation.
> 
> This patch replaces the vzalloc call with an almost equivalent call to
> the newly introduced vmalloc_no_huge function, which guarantees that
> only small pages will be used for the backing.
> 
> The new call will not clear the allocated memory, but that has never
> been an actual requirement.

Since it seems like you will submit another version, I think it would
make things clear to change "fix" to "prepare", which should avoid
misleading the reader and tripping up automatic backporting things.

You could also add the first paragraph as a comment in the code?

Otherwise it looks good to me.

Acked-by: Nicholas Piggin <npiggin@...il.com>

> 
> Signed-off-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>
> Reviewed-by: Janosch Frank <frankja@...ux.ibm.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Nicholas Piggin <npiggin@...il.com>
> Cc: Uladzislau Rezki (Sony) <urezki@...il.com>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: David Rientjes <rientjes@...gle.com>
> Cc: Christoph Hellwig <hch@...radead.org>
> ---
>  arch/s390/kvm/pv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kvm/pv.c b/arch/s390/kvm/pv.c
> index 813b6e93dc83..ad7c6d7cc90b 100644
> --- a/arch/s390/kvm/pv.c
> +++ b/arch/s390/kvm/pv.c
> @@ -140,7 +140,7 @@ static int kvm_s390_pv_alloc_vm(struct kvm *kvm)
>  	/* Allocate variable storage */
>  	vlen = ALIGN(virt * ((npages * PAGE_SIZE) / HPAGE_SIZE), PAGE_SIZE);
>  	vlen += uv_info.guest_virt_base_stor_len;
> -	kvm->arch.pv.stor_var = vzalloc(vlen);
> +	kvm->arch.pv.stor_var = vmalloc_no_huge(vlen);
>  	if (!kvm->arch.pv.stor_var)
>  		goto out_err;
>  	return 0;
> -- 
> 2.31.1
> 
>