kernel.git/drivers/s390/char/sclp_mem.c, branch master

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

s390: Unmap early KASAN shadow on memory offlining

2025-12-07T15:15:19Z

Teach the memory hotplug path to tear down KASAN shadow that was mapped during early boot when a memory block is offlined. Track for each sclp_mem whether its range was covered by the early KASAN shadow via an early_shadow_mapped flag. When such a block is deconfigured and removed via sclp_config_mem_store(), compute the corresponding shadow range and call vmemmap_free() to unmap the boot mapped shadow, then clear the flag. Using vmemmap_free() for the early shadow is safe despite the use of large mappings in the boot-time KASAN setup. The initial shadow is mapped with 1M and 2G pages, where possible. The minimum hotplug memory block size is 128M and always aligned (the identity mapping is at least 2G aligned), which corresponds to a 16M chunk of at least 1M aligned shadow. PMD-mapped 1M shadow pages therefore never need splitting, and PUD-mapped 2G shadow pages can now be split following the preceding changes. Relax the modify_pagetable() sanity check in vmem so that, with KASAN enabled, it may also operate on the KASAN shadow region in addition to the 1:1 mapping and vmemmap area. This allows the KASAN shadow unmapping to reuse the common vmem helpers. Signed-off-by: Vasily Gorbik Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens

s390: Remove KMSG_COMPONENT macro

2025-11-24T10:45:21Z

The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" which never made it upstream. Remove the macro in order to get rid of a pointless indirection. Replace all users with the string it defines. In almost all cases this leads to a simple replacement like this: - #define KMSG_COMPONENT "appldata" - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt + #define pr_fmt(fmt) "appldata: " fmt Except for some special cases this is just mechanical/scripted work. Acked-by: Thomas Richter Signed-off-by: Heiko Carstens

s390/sclp_mem: Consider global memory_hotplug.memmap_on_memory setting

2025-11-06T13:18:23Z

When the global kernel command line parameter memory_hotplug.memmap_on_memory is set to false, per-memory-block memmap_on_memory setting can still be set to true. However, when configuring memory block, add_memory_resource() would configure it without memmap_on_memory. i.e. Even if the MHP_MEMMAP_ON_MEMORY flag is set, mhp_supports_memmap_on_memory() returns false unless the kernel command line parameter "memory_hotplug.memmap_on_memory" is enabled. When both the flag and the cmdline parameter are set, the memory block can be configured with or without memmap_on_memory support. To ensure consistent behavior, permit configuring per-memory-block memmap_on_memory only when the memory_hotplug.memmap_on_memory kernel command line parameter is enabled. This is similar to commit 73954d379efd ("dax: add a sysfs knob to control memmap_on_memory behavior") Fixes: ff18dcb19aab ("s390/sclp: Add support for dynamic (de)configuration of memory") Signed-off-by: Sumanth Korikkar Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens

s390/sclp: Remove MHP_OFFLINE_INACCESSIBLE

2025-10-14T12:24:53Z

mhp_flag MHP_OFFLINE_INACCESSIBLE was used to mark memory as not accessible until memory hotplug online phase begins. Earlier, standby memory blocks were added upfront during boottime and MHP_OFFLINE_INACCESSIBLE flag avoided page_init_poison() on memmap during mhp addition phase. However with dynamic runtime configuration of memory, standby memory can be brought to accessible state before performing add_memory(). Hence, remove MHP_OFFLINE_INACCESSIBLE. Acked-by: Heiko Carstens Reviewed-by: David Hildenbrand Signed-off-by: Sumanth Korikkar Signed-off-by: Heiko Carstens

s390/sclp: Add support for dynamic (de)configuration of memory

2025-10-14T12:24:53Z

Provide a new interface for dynamic configuration and deconfiguration of hotplug memory, allowing with/without memmap_on_memory support. It is a follow up on the discussion with David when introducing memmap_on_memory support for s390 and support dynamic (de)configuration of memory: https://lore.kernel.org/all/ee492da8-74b4-4a97-8b24-73e07257f01d@redhat.com/ https://lore.kernel.org/all/20241202082732.3959803-1-sumanthk@linux.ibm.com/ The original motivation for introducing memmap_on_memory on s390 was to avoid using online memory to store struct pages metadata, particularly for standby memory blocks. This became critical in cases where there was an imbalance between standby and online memory, potentially leading to boot failures due to insufficient memory for metadata allocation. To address this, memmap_on_memory was utilized on s390. However, in its current form, it adds struct pages metadata at the start of each memory block at the time of addition and this configuration is static. It cannot be changed at runtime. (When the user needs continuous physical memory). Inorder to provide more flexibility to the user and overcome the above limitation, add option to dynamically configure and deconfigure hotpluggable memory block with/without memmap_on_memory. With the new interface, s390 will not add all possible hotplug memory in advance, like before, to make it visible in sysfs for online/offline actions. Instead, before memory block can be set online, it has to be configured via a new interface in /sys/firmware/memory/memoryX/config, which makes s390 similar to others. i.e. Adding of hotpluggable memory is controlled by the user instead of adding it at boottime. The s390 kernel sysfs interface to configure and deconfigure memory is as follows (considering the upcoming lsmem changes): * Initial memory layout: lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes * Configure memory sys="/sys" echo 1 > $sys/firmware/memory/memory16/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0x87ffffff 128M offline 16 yes yes 0x88000000-0xffffffff 1.9G offline 17-31 no yes * Deconfigure memory echo 0 > $sys/firmware/memory/memory16/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes 3. Enable memmap_on_memory and online it. echo 0 > $sys/devices/system/memory/memory5/online echo 0 > $sys/firmware/memory/memory5/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x27ffffff 640M online 0-4 yes no 0x28000000-0x2fffffff 128M offline 5 no no 0x30000000-0x7fffffff 1.3G online 6-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes echo 1 > $sys/firmware/memory/memory5/memmap_on_memory echo 1 > $sys/firmware/memory/memory5/config echo 1 > $sys/devices/system/memory/memory5/online lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x27ffffff 640M online 0-4 yes no 0x28000000-0x2fffffff 128M online 5 yes yes 0x30000000-0x7fffffff 1.3G online 6-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes 4. Disable memmap_on_memory and online it. echo 0 > $sys/devices/system/memory/memory5/online echo 0 > $sys/firmware/memory/memory5/config lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x27ffffff 640M online 0-4 yes no 0x28000000-0x2fffffff 128M offline 5 no yes 0x30000000-0x7fffffff 1.3G online 6-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes echo 0 > $sys/firmware/memory/memory5/memmap_on_memory echo 1 > $sys/firmware/memory/memory5/config echo 1 > $sys/devices/system/memory/memory5/online lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP_ON_MEMORY RANGE SIZE STATE BLOCK CONFIGURED MEMMAP_ON_MEMORY 0x00000000-0x7fffffff 2G online 0-15 yes no 0x80000000-0xffffffff 2G offline 16-31 no yes Acked-by: Heiko Carstens Acked-by: David Hildenbrand Signed-off-by: Sumanth Korikkar Signed-off-by: Heiko Carstens

s390/sclp: Move memory hotplug code for better modularity

2025-08-20T14:38:23Z

To improve readability and prepare for future extensions, move the memory hotplug code to a separate file. In addtion to it, add required headers in sclp_mem.c and remove unnecessary headers in sclp_cmd.c Acked-by: Heiko Carstens Signed-off-by: Sumanth Korikkar Signed-off-by: Alexander Gordeev