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@xxxxxxxxxxxxxxxxxxxx'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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx
Signed-off-by: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx>
Reviewed-by: Janosch Frank <frankja@xxxxxxxxxxxxx>
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?
