All of lore.kernel.org
 help / color / mirror / Atom feed
* + kvm-s390-fix-for-hugepage-vmalloc.patch added to -mm tree
@ 2021-06-08 21:06 akpm
  2021-06-14  0:58 ` Nicholas Piggin
  0 siblings, 1 reply; 4+ messages in thread
From: akpm @ 2021-06-08 21:06 UTC (permalink / raw)
  To: borntraeger, catalin.marinas, david, frankja, imbrenda, mingo,
	mm-commits, npiggin, rientjes, tglx, urezki


The patch titled
     Subject: KVM: s390: fix for hugepage vmalloc
has been added to the -mm tree.  Its filename is
     kvm-s390-fix-for-hugepage-vmalloc.patch

This patch should soon appear at
    https://ozlabs.org/~akpm/mmots/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch
and later at
    https://ozlabs.org/~akpm/mmotm/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: Claudio Imbrenda <imbrenda@linux.ibm.com>
Subject: KVM: s390: fix for hugepage vmalloc

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 a longer but equivalent
__vmalloc_node_range call, also setting the VM_NO_HUGE_VMAP flag, to
guarantee that this allocation will not be performed with large pages.

Link: https://lkml.kernel.org/r/20210608180618.477766-3-imbrenda@linux.ibm.com
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Fixes: 121e6f3258fe393e22c3 ("mm/vmalloc: hugepage vmalloc mappings")
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>	[s390]
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
Cc: David Hildenbrand <david@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/s390/kvm/pv.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/s390/kvm/pv.c~kvm-s390-fix-for-hugepage-vmalloc
+++ a/arch/s390/kvm/pv.c
@@ -140,7 +140,10 @@ static int kvm_s390_pv_alloc_vm(struct k
 	/* 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_node_range(vlen, PAGE_SIZE, VMALLOC_START, VMALLOC_END,
+						     GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL,
+						     VM_NO_HUGE_VMAP, NUMA_NO_NODE,
+						     __builtin_return_address(0));
 	if (!kvm->arch.pv.stor_var)
 		goto out_err;
 	return 0;
_

Patches currently in -mm which might be from imbrenda@linux.ibm.com are

mm-vmalloc-export-__vmalloc_node_range.patch
kvm-s390-fix-for-hugepage-vmalloc.patch


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: + kvm-s390-fix-for-hugepage-vmalloc.patch added to -mm tree
  2021-06-08 21:06 + kvm-s390-fix-for-hugepage-vmalloc.patch added to -mm tree akpm
@ 2021-06-14  0:58 ` Nicholas Piggin
  2021-06-14  1:13   ` Nicholas Piggin
  0 siblings, 1 reply; 4+ messages in thread
From: Nicholas Piggin @ 2021-06-14  0:58 UTC (permalink / raw)
  To: akpm, borntraeger, catalin.marinas, david, frankja, imbrenda,
	mingo, mm-commits, rientjes, tglx, urezki

Excerpts from akpm@linux-foundation.org's message of June 9, 2021 7:06 am:
> 
> The patch titled
>      Subject: KVM: s390: fix for hugepage vmalloc
> has been added to the -mm tree.  Its filename is
>      kvm-s390-fix-for-hugepage-vmalloc.patch
> 
> This patch should soon appear at
>     https://ozlabs.org/~akpm/mmots/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch
> and later at
>     https://ozlabs.org/~akpm/mmotm/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch
> 
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
> 
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
> 
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
> 
> ------------------------------------------------------
> From: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Subject: KVM: s390: fix for hugepage vmalloc
> 
> 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 a longer but equivalent
> __vmalloc_node_range call, also setting the VM_NO_HUGE_VMAP flag, to
> guarantee that this allocation will not be performed with large pages.
> 
> Link: https://lkml.kernel.org/r/20210608180618.477766-3-imbrenda@linux.ibm.com
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
> Fixes: 121e6f3258fe393e22c3 ("mm/vmalloc: hugepage vmalloc mappings")

Hmm, s390 does not select HAVE_ARCH_HUGE_VMALLOC so it was intended that 
"mm/vmalloc: hugepage vmalloc mappings" does not introduce huge vmallocs
for you.

I can't see how this would happen, any clue what I'm missing?

Thanks,
Nick

> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>	[s390]
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Janosch Frank <frankja@linux.ibm.com>
> Cc: David Hildenbrand <david@redhat.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  arch/s390/kvm/pv.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> --- a/arch/s390/kvm/pv.c~kvm-s390-fix-for-hugepage-vmalloc
> +++ a/arch/s390/kvm/pv.c
> @@ -140,7 +140,10 @@ static int kvm_s390_pv_alloc_vm(struct k
>  	/* 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_node_range(vlen, PAGE_SIZE, VMALLOC_START, VMALLOC_END,
> +						     GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL,
> +						     VM_NO_HUGE_VMAP, NUMA_NO_NODE,
> +						     __builtin_return_address(0));
>  	if (!kvm->arch.pv.stor_var)
>  		goto out_err;
>  	return 0;
> _
> 
> Patches currently in -mm which might be from imbrenda@linux.ibm.com are
> 
> mm-vmalloc-export-__vmalloc_node_range.patch
> kvm-s390-fix-for-hugepage-vmalloc.patch
> 
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: + kvm-s390-fix-for-hugepage-vmalloc.patch added to -mm tree
  2021-06-14  0:58 ` Nicholas Piggin
@ 2021-06-14  1:13   ` Nicholas Piggin
  2021-06-14 12:37     ` Christian Borntraeger
  0 siblings, 1 reply; 4+ messages in thread
From: Nicholas Piggin @ 2021-06-14  1:13 UTC (permalink / raw)
  To: akpm, borntraeger, catalin.marinas, david, frankja, imbrenda,
	mingo, mm-commits, rientjes, tglx, urezki

Excerpts from Nicholas Piggin's message of June 14, 2021 10:58 am:
> Excerpts from akpm@linux-foundation.org's message of June 9, 2021 7:06 am:
>> 
>> The patch titled
>>      Subject: KVM: s390: fix for hugepage vmalloc
>> has been added to the -mm tree.  Its filename is
>>      kvm-s390-fix-for-hugepage-vmalloc.patch
>> 
>> This patch should soon appear at
>>     https://ozlabs.org/~akpm/mmots/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch
>> and later at
>>     https://ozlabs.org/~akpm/mmotm/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch
>> 
>> Before you just go and hit "reply", please:
>>    a) Consider who else should be cc'ed
>>    b) Prefer to cc a suitable mailing list as well
>>    c) Ideally: find the original patch on the mailing list and do a
>>       reply-to-all to that, adding suitable additional cc's
>> 
>> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
>> 
>> The -mm tree is included into linux-next and is updated
>> there every 3-4 working days
>> 
>> ------------------------------------------------------
>> From: Claudio Imbrenda <imbrenda@linux.ibm.com>
>> Subject: KVM: s390: fix for hugepage vmalloc
>> 
>> 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 a longer but equivalent
>> __vmalloc_node_range call, also setting the VM_NO_HUGE_VMAP flag, to
>> guarantee that this allocation will not be performed with large pages.
>> 
>> Link: https://lkml.kernel.org/r/20210608180618.477766-3-imbrenda@linux.ibm.com
>> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
>> Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
>> Fixes: 121e6f3258fe393e22c3 ("mm/vmalloc: hugepage vmalloc mappings")
> 
> Hmm, s390 does not select HAVE_ARCH_HUGE_VMALLOC so it was intended that 
> "mm/vmalloc: hugepage vmalloc mappings" does not introduce huge vmallocs
> for you.
> 
> I can't see how this would happen, any clue what I'm missing?

Ah, read into the mailing list thread for the other patch and it seems 
it only becomes a problem if/when you do enable it, is that right?

From the changelog it appears that this fixes a bug introduced by that
patch. I think instead it should go with the series that enables the
option, and without the fixes tag.

Or if you wanted to get this core API change in first and need a caller 
in-tree, explain in the changelog that huge vmalloc enablement is coming 
later and requires it. The enable patch that comes later could reference 
this commit to help with backporting, if that's what you are concerned
about.

Thanks,
Nick

> 
> Thanks,
> Nick
> 
>> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>	[s390]
>> Cc: Nicholas Piggin <npiggin@gmail.com>
>> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: David Rientjes <rientjes@google.com>
>> Cc: Janosch Frank <frankja@linux.ibm.com>
>> Cc: David Hildenbrand <david@redhat.com>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> ---
>> 
>>  arch/s390/kvm/pv.c |    5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>> 
>> --- a/arch/s390/kvm/pv.c~kvm-s390-fix-for-hugepage-vmalloc
>> +++ a/arch/s390/kvm/pv.c
>> @@ -140,7 +140,10 @@ static int kvm_s390_pv_alloc_vm(struct k
>>  	/* 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_node_range(vlen, PAGE_SIZE, VMALLOC_START, VMALLOC_END,
>> +						     GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL,
>> +						     VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>> +						     __builtin_return_address(0));
>>  	if (!kvm->arch.pv.stor_var)
>>  		goto out_err;
>>  	return 0;
>> _
>> 
>> Patches currently in -mm which might be from imbrenda@linux.ibm.com are
>> 
>> mm-vmalloc-export-__vmalloc_node_range.patch
>> kvm-s390-fix-for-hugepage-vmalloc.patch
>> 
>> 
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: + kvm-s390-fix-for-hugepage-vmalloc.patch added to -mm tree
  2021-06-14  1:13   ` Nicholas Piggin
@ 2021-06-14 12:37     ` Christian Borntraeger
  0 siblings, 0 replies; 4+ messages in thread
From: Christian Borntraeger @ 2021-06-14 12:37 UTC (permalink / raw)
  To: Nicholas Piggin, akpm, catalin.marinas, david, frankja, imbrenda,
	mingo, mm-commits, rientjes, tglx, urezki



On 14.06.21 03:13, Nicholas Piggin wrote:
> Excerpts from Nicholas Piggin's message of June 14, 2021 10:58 am:
>> Excerpts from akpm@linux-foundation.org's message of June 9, 2021 7:06 am:
>>>
>>> The patch titled
>>>       Subject: KVM: s390: fix for hugepage vmalloc
>>> has been added to the -mm tree.  Its filename is
>>>       kvm-s390-fix-for-hugepage-vmalloc.patch
>>>
>>> This patch should soon appear at
>>>      https://ozlabs.org/~akpm/mmots/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch
>>> and later at
>>>      https://ozlabs.org/~akpm/mmotm/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch
>>>
>>> Before you just go and hit "reply", please:
>>>     a) Consider who else should be cc'ed
>>>     b) Prefer to cc a suitable mailing list as well
>>>     c) Ideally: find the original patch on the mailing list and do a
>>>        reply-to-all to that, adding suitable additional cc's
>>>
>>> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
>>>
>>> The -mm tree is included into linux-next and is updated
>>> there every 3-4 working days
>>>
>>> ------------------------------------------------------
>>> From: Claudio Imbrenda <imbrenda@linux.ibm.com>
>>> Subject: KVM: s390: fix for hugepage vmalloc
>>>
>>> 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 a longer but equivalent
>>> __vmalloc_node_range call, also setting the VM_NO_HUGE_VMAP flag, to
>>> guarantee that this allocation will not be performed with large pages.
>>>
>>> Link: https://lkml.kernel.org/r/20210608180618.477766-3-imbrenda@linux.ibm.com
>>> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
>>> Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
>>> Fixes: 121e6f3258fe393e22c3 ("mm/vmalloc: hugepage vmalloc mappings")
>>
>> Hmm, s390 does not select HAVE_ARCH_HUGE_VMALLOC so it was intended that
>> "mm/vmalloc: hugepage vmalloc mappings" does not introduce huge vmallocs
>> for you.
>>
>> I can't see how this would happen, any clue what I'm missing?
> 
> Ah, read into the mailing list thread for the other patch and it seems
> it only becomes a problem if/when you do enable it, is that right?
> 
>  From the changelog it appears that this fixes a bug introduced by that
> patch. I think instead it should go with the series that enables the
> option, and without the fixes tag.
> 
> Or if you wanted to get this core API change in first and need a caller
> in-tree, explain in the changelog that huge vmalloc enablement is coming
> later and requires it. The enable patch that comes later could reference
> this commit to help with backporting, if that's what you are concerned
> about.

Yes, its an ordering thing. Before s390 can opt in, we need to get our "odd
cases fixed". Not sure if we need a new version with a different description
or if we can simply leave it as is?

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-06-14 12:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-08 21:06 + kvm-s390-fix-for-hugepage-vmalloc.patch added to -mm tree akpm
2021-06-14  0:58 ` Nicholas Piggin
2021-06-14  1:13   ` Nicholas Piggin
2021-06-14 12:37     ` Christian Borntraeger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.