Re: [PATCH] mm: hugetlb: fix HVO crash on s390
From: Luiz Capitulino
Date: Tue Oct 28 2025 - 13:16:12 EST
On 2025-10-28 13:02, Heiko Carstens wrote:
On Tue, Oct 28, 2025 at 04:48:57PM +0000, Joao Martins wrote:
On 28/10/2025 16:14, Heiko Carstens wrote:
On Tue, Oct 28, 2025 at 04:05:45PM +0000, Joao Martins wrote:The latter i.e. everything
+static inline void vmemmap_flush_tlb_all(void)
+{
+#ifdef CONFIG_S390
+ __tlb_flush_kernel();
+#else
+ flush_tlb_all();
+#endif
+}
+
Wouldn't a better fix be to implement flush_tlb_all() in
s390/include/asm/tlbflush.h since that aliases to __tlb_flush_kernel()?
The question is rather what is flush_tlb_all() supposed to flush? Is
it supposed to flush only tlb entries corresponding to the kernel
address space, or should it flush just everything?
At least as far as I understand
Within this context it looks like only tlb flushing for the kernel
address space is required(?)
That's correct. We are changing the vmemmap which is in the kernel address
space, so that's the intent.
flush_tlb_all() however is the *closest* equivalent to this that's behind an
arch generic API i.e. flushing kernel address space on all CPUs TLBs. IIUC, x86
when doing flush_tlb_kernel_range with enough pages it switches to flush_tlb_all
(these days on modern AMDs it's even one instruction solely in the calling CPU).
Considering that flush_tlb_all() should be mapped to __tlb_flush_global()
and not __tlb_flush_kernel() on s390.
You're right.
However if there is only a need to flush tlb entries for the complete(?)
kernel address space, then I'd rather propose a new tlb_flush_kernel()
instead of a big hammer. If I'm not mistaken flush_tlb_kernel_range()
exists for just avoiding that. And if architectures can avoid a global
flush of _all_ tlb entries then that should be made possible.
Should we take a v2 doing your suggestion above for now and work on
the tlb_flush_kernel() idea as a follow up improvement? At least we
go from crashing to flushing more than we should...