Re: [PATCH] mm: Convert memory block states (MEM_*) macros to enum

[David Hildenbrand <david@redhat.com>]

On 27.10.25 19:18, Omar Sandoval wrote:
> On Sun, Oct 26, 2025 at 04:22:05PM +0000, Israel Batista wrote:
>> The MEM_* constants indicating the state of the memory block are
>> currently defined as macros, meaning their definitions will be omitted
>> from the debuginfo on most kernel builds. This makes it harder for
>> debuggers to correctly map the block state at runtime, which can be
>> quite useful when analysing errors related to memory hot plugging and
>> unplugging with tools such as drgn and eBPF.
>>
>> Converting the constants to an enum will ensure the correct information
>> is emitted by the compiler and available for the debugger, without needing
>> to hard-code them into the debugger and track their changes.
>>
>> Signed-off-by: Israel Batista <linux@israelbatista.dev.br>
>> ---
>>   include/linux/memory.h | 16 +++++++++-------
>>   1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/memory.h b/include/linux/memory.h
>> index ba1515160894..8feba3bfcd18 100644
>> --- a/include/linux/memory.h
>> +++ b/include/linux/memory.h
>> @@ -89,13 +89,15 @@ int arch_get_memory_phys_device(unsigned long start_pfn);
>>   unsigned long memory_block_size_bytes(void);
>>   int set_memory_block_size_order(unsigned int order);
>>   
>> -/* These states are exposed to userspace as text strings in sysfs */
>> -#define	MEM_ONLINE		(1<<0) /* exposed to userspace */
>> -#define	MEM_GOING_OFFLINE	(1<<1) /* exposed to userspace */
>> -#define	MEM_OFFLINE		(1<<2) /* exposed to userspace */
>> -#define	MEM_GOING_ONLINE	(1<<3)
>> -#define	MEM_CANCEL_ONLINE	(1<<4)
>> -#define	MEM_CANCEL_OFFLINE	(1<<5)
> 
> What kernel version is this patch based on? It doesn't apply on mainline
> because it is missing a couple of definitions added in 6.9 by commit
> c5f1e2d18909 ("mm/memory_hotplug: introduce
> MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE notifiers").
> 
>> +enum mem_states {
> 
> mem_state is very vague. enum memory_block_state might be a more
> appropriate name.

Agreed. That then nicely fits "struct memory_block".

-- 
Cheers

David / dhildenb