Re: [PATCH 1/3] arch: Introduce ARCH_HAS_CPUMASK_BITS

From: David Hildenbrand
Date: Tue Apr 04 2023 - 09:49:06 EST


On 04.04.23 15:42, Yair Podemsky wrote:
Some architectures set and maintain the mm_cpumask bits when loading
or removing process from cpu.
This Kconfig will mark those to allow different behavior between
kernels that maintain the mm_cpumask and those that do not.


I was wondering if we should do something along the lines of:

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 0722859c3647..1f5c15d8e8ed 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -767,11 +767,13 @@ struct mm_struct {
#endif /* CONFIG_LRU_GEN */
} __randomize_layout;

+#ifdef CONFIG_MM_CPUMASK
/*
* The mm_cpumask needs to be at the end of mm_struct, because it
* is dynamically sized based on nr_cpu_ids.
*/
unsigned long cpu_bitmap[];
+#endif
};

But that would, of course, require additional changes to make it compile. What concerns me a bit is that we have in mm/rmap.c a mm_cpumask() usage. But it's glued to CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH ... shaky.

At least if we would properly fence it, there would be no
accidental abuse anymore.


Signed-off-by: Yair Podemsky <ypodemsk@xxxxxxxxxx>
---
arch/Kconfig | 8 ++++++++
arch/arm/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 1 +

As Valentin says, there are other architectures that do the same.

--
Thanks,

David / dhildenb