An error occurred fetching the project authors.
  1. 04 Sep, 2024 3 commits
  2. 02 Sep, 2024 1 commit
  3. 12 Jul, 2024 1 commit
  4. 04 Jul, 2024 6 commits
  5. 06 May, 2024 1 commit
  6. 26 Apr, 2024 1 commit
  7. 22 Feb, 2024 2 commits
    • Vishal Verma's avatar
      mm/memory_hotplug: export mhp_supports_memmap_on_memory() · 42d93582
      Vishal Verma authored
      In preparation for adding sysfs ABI to toggle memmap_on_memory semantics
      for drivers adding memory, export the mhp_supports_memmap_on_memory()
      helper. This allows drivers to check if memmap_on_memory support is
      available before trying to request it, and display an appropriate
      message if it isn't available. As part of this, remove the size argument
      to this - with recent updates to allow memmap_on_memory for larger
      ranges, and the internal splitting of altmaps into respective memory
      blocks, the size argument is meaningless.
      
      [akpm@linux-foundation.org: fix build]
      Link: https://lkml.kernel.org/r/20240124-vv-dax_abi-v7-4-20d16cb8d23d@intel.comSigned-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Suggested-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: Li Zhijian <lizhijian@fujitsu.com>
      Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      42d93582
    • Sumanth Korikkar's avatar
      mm/memory_hotplug: introduce MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE notifiers · c5f1e2d1
      Sumanth Korikkar authored
      Patch series "implement "memmap on memory" feature on s390".
      
      This series provides "memmap on memory" support on s390 platform.  "memmap
      on memory" allows struct pages array to be allocated from the hotplugged
      memory range instead of allocating it from main system memory.
      
      s390 currently preallocates struct pages array for all potentially
      possible memory, which ensures memory onlining always succeeds, but with
      the cost of significant memory consumption from the available system
      memory during boottime.  In certain extreme configuration, this could lead
      to ipl failure.
      
      "memmap on memory" ensures struct pages array are populated from self
      contained hotplugged memory range instead of depleting the available
      system memory and this could eliminate ipl failure on s390 platform.
      
      On other platforms, system might go OOM when the physically hotplugged
      memory depletes the available memory before it is onlined.  Hence, "memmap
      on memory" feature was introduced as described in commit a08a2ae3
      ("mm,memory_hotplug: allocate memmap from the added memory range").
      
      Unlike other architectures, s390 memory blocks are not physically
      accessible until it is online.  To make it physically accessible two new
      memory notifiers MEM_PREPARE_ONLINE / MEM_FINISH_OFFLINE are added and
      this notifier lets the hypervisor inform that the memory should be made
      physically accessible.  This allows for "memmap on memory" initialization
      during memory hotplug onlining phase, which is performed before calling
      MEM_GOING_ONLINE notifier.
      
      Patch 1 introduces MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE memory notifiers
      to prepare the transition of memory to and from a physically accessible
      state.  New mhp_flag MHP_OFFLINE_INACCESSIBLE is introduced to ensure
      altmap cannot be written when adding memory - before it is set online. 
      This enhancement is crucial for implementing the "memmap on memory"
      feature for s390 in a subsequent patch.
      
      Patches 2 allocates vmemmap pages from self-contained memory range for
      s390.  It allocates memory map (struct pages array) from the hotplugged
      memory range, rather than using system memory by passing altmap to vmemmap
      functions.
      
      Patch 3 removes unhandled memory notifier types on s390.
      
      Patch 4 implements MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE memory notifiers
      on s390.  MEM_PREPARE_ONLINE memory notifier makes memory block physical
      accessible via sclp assign command.  The notifier ensures self-contained
      memory maps are accessible and hence enabling the "memmap on memory" on
      s390.  MEM_FINISH_OFFLINE memory notifier shifts the memory block to an
      inaccessible state via sclp unassign command.
      
      Patch 5 finally enables MHP_MEMMAP_ON_MEMORY on s390.
      
      
      This patch (of 5):
      
      Introduce MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE memory notifiers to
      prepare the transition of memory to and from a physically accessible
      state.  This enhancement is crucial for implementing the "memmap on
      memory" feature for s390 in a subsequent patch.
      
      Platforms such as x86 can support physical memory hotplug via ACPI.  When
      there is physical memory hotplug, ACPI event leads to the memory addition
      with the following callchain:
      
      acpi_memory_device_add()
        -> acpi_memory_enable_device()
           -> __add_memory()
      
      After this, the hotplugged memory is physically accessible, and altmap
      support prepared, before the "memmap on memory" initialization in
      memory_block_online() is called.
      
      On s390, memory hotplug works in a different way.  The available hotplug
      memory has to be defined upfront in the hypervisor, but it is made
      physically accessible only when the user sets it online via sysfs,
      currently in the MEM_GOING_ONLINE notifier.  This is too late and "memmap
      on memory" initialization is performed before calling MEM_GOING_ONLINE
      notifier.
      
      During the memory hotplug addition phase, altmap support is prepared and
      during the memory onlining phase s390 requires memory to be physically
      accessible and then subsequently initiate the "memmap on memory"
      initialization process.
      
      The memory provider will handle new MEM_PREPARE_ONLINE /
      MEM_FINISH_OFFLINE notifications and make the memory accessible.
      
      The mhp_flag MHP_OFFLINE_INACCESSIBLE is introduced and is relevant when
      used along with MHP_MEMMAP_ON_MEMORY, because the altmap cannot be written
      (e.g., poisoned) when adding memory -- before it is set online.  This
      allows for adding memory with an altmap that is not currently made
      available by a hypervisor.  When onlining that memory, the hypervisor can
      be instructed to make that memory accessible via the new notifiers and the
      onlining phase will not require any memory allocations, which is helpful
      in low-memory situations.
      
      All architectures ignore unknown memory notifiers.  Therefore, the
      introduction of these new notifiers does not result in any functional
      modifications across architectures.
      
      Link: https://lkml.kernel.org/r/20240108132747.3238763-1-sumanthk@linux.ibm.com
      Link: https://lkml.kernel.org/r/20240108132747.3238763-2-sumanthk@linux.ibm.comSigned-off-by: default avatarSumanth Korikkar <sumanthk@linux.ibm.com>
      Suggested-by: default avatarGerald Schaefer <gerald.schaefer@linux.ibm.com>
      Suggested-by: default avatarDavid Hildenbrand <david@redhat.com>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Alexander Gordeev <agordeev@linux.ibm.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      c5f1e2d1
  8. 12 Jan, 2024 1 commit
  9. 08 Jan, 2024 1 commit
  10. 11 Dec, 2023 2 commits
  11. 07 Dec, 2023 2 commits
    • Sumanth Korikkar's avatar
      mm/memory_hotplug: fix error handling in add_memory_resource() · f42ce5f0
      Sumanth Korikkar authored
      In add_memory_resource(), creation of memory block devices occurs after
      successful call to arch_add_memory().  However, creation of memory block
      devices could fail.  In that case, arch_remove_memory() is called to
      perform necessary cleanup.
      
      Currently with or without altmap support, arch_remove_memory() is always
      passed with altmap set to NULL during error handling.  This leads to
      freeing of struct pages using free_pages(), eventhough the allocation
      might have been performed with altmap support via
      altmap_alloc_block_buf().
      
      Fix the error handling by passing altmap in arch_remove_memory(). This
      ensures the following:
      * When altmap is disabled, deallocation of the struct pages array occurs
        via free_pages().
      * When altmap is enabled, deallocation occurs via vmem_altmap_free().
      
      Link: https://lkml.kernel.org/r/20231120145354.308999-3-sumanthk@linux.ibm.com
      Fixes: a08a2ae3 ("mm,memory_hotplug: allocate memmap from the added memory range")
      Signed-off-by: default avatarSumanth Korikkar <sumanthk@linux.ibm.com>
      Reviewed-by: default avatarGerald Schaefer <gerald.schaefer@linux.ibm.com>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Alexander Gordeev <agordeev@linux.ibm.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: kernel test robot <lkp@intel.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: <stable@vger.kernel.org>	[5.15+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      f42ce5f0
    • Sumanth Korikkar's avatar
      mm/memory_hotplug: add missing mem_hotplug_lock · 001002e7
      Sumanth Korikkar authored
      From Documentation/core-api/memory-hotplug.rst:
      When adding/removing/onlining/offlining memory or adding/removing
      heterogeneous/device memory, we should always hold the mem_hotplug_lock
      in write mode to serialise memory hotplug (e.g. access to global/zone
      variables).
      
      mhp_(de)init_memmap_on_memory() functions can change zone stats and
      struct page content, but they are currently called w/o the
      mem_hotplug_lock.
      
      When memory block is being offlined and when kmemleak goes through each
      populated zone, the following theoretical race conditions could occur:
      CPU 0:					     | CPU 1:
      memory_offline()			     |
      -> offline_pages()			     |
      	-> mem_hotplug_begin()		     |
      	   ...				     |
      	-> mem_hotplug_done()		     |
      					     | kmemleak_scan()
      					     | -> get_online_mems()
      					     |    ...
      -> mhp_deinit_memmap_on_memory()	     |
        [not protected by mem_hotplug_begin/done()]|
        Marks memory section as offline,	     |   Retrieves zone_start_pfn
        poisons vmemmap struct pages and updates   |   and struct page members.
        the zone related data			     |
         					     |    ...
         					     | -> put_online_mems()
      
      Fix this by ensuring mem_hotplug_lock is taken before performing
      mhp_init_memmap_on_memory().  Also ensure that
      mhp_deinit_memmap_on_memory() holds the lock.
      
      online/offline_pages() are currently only called from
      memory_block_online/offline(), so it is safe to move the locking there.
      
      Link: https://lkml.kernel.org/r/20231120145354.308999-2-sumanthk@linux.ibm.com
      Fixes: a08a2ae3 ("mm,memory_hotplug: allocate memmap from the added memory range")
      Signed-off-by: default avatarSumanth Korikkar <sumanthk@linux.ibm.com>
      Reviewed-by: default avatarGerald Schaefer <gerald.schaefer@linux.ibm.com>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: Alexander Gordeev <agordeev@linux.ibm.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Heiko Carstens <hca@linux.ibm.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: kernel test robot <lkp@intel.com>
      Cc: <stable@vger.kernel.org>	[5.15+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      001002e7
  12. 25 Oct, 2023 1 commit
  13. 04 Oct, 2023 1 commit
  14. 21 Aug, 2023 4 commits
  15. 18 Aug, 2023 1 commit
  16. 23 Jun, 2023 1 commit
  17. 19 Jun, 2023 3 commits
  18. 09 Jun, 2023 1 commit
  19. 18 Apr, 2023 1 commit
  20. 06 Apr, 2023 1 commit
  21. 20 Feb, 2023 3 commits
  22. 13 Feb, 2023 1 commit
  23. 03 Oct, 2022 1 commit