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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux