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