linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to
@ 2025-10-29 19:56 Israel Batista
  2025-10-29 19:56 ` [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum Israel Batista
                   ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: Israel Batista @ 2025-10-29 19:56 UTC (permalink / raw)
  To: david, lorenzo.stoakes, akpm, linux-mm; +Cc: osandov, linux-debuggers

The MEM_* constants indicating the state of a 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.

Converting the constants to an enum would 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.

This patch series aims to replace the current macros with a newly
created enum named memory_block_state, while also taking advantage of
the compile time guarantees that we get when using enums.

The first patch does the conversion of the macros to an enum, while the
2nd and 3rd patches use this enum to clean up some type declarations and
make sure that only valid values are used.

---

Link: https://lore.kernel.org/linux-mm/20251026162156.12141-1-linux@israelbatista.dev.br/ [v1]

v1 -> v2
- Rename the enum to make it more descriptive.
- Let the enum auto-generate the values, as the (1<<X) pattern could be
  misleading and they're not exposed to userspace.
- Change the type signature from unsigned long to enum memory_block_state
  where suitable.

Thanks to everyone who took their time to review the first version.

This patch series applies to commit: f30d294530d9 (mm-new)

Israel Batista (3):
  mm: convert memory block states (MEM_*) macros to enum
  mm: change type of state in struct memory_block
  mm: change type of parameter for memory_notify

 drivers/base/memory.c  |  6 +++---
 include/linux/memory.h | 28 +++++++++++++++-------------
 2 files changed, 18 insertions(+), 16 deletions(-)

-- 
2.51.0



^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum
  2025-10-29 19:56 [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Israel Batista
@ 2025-10-29 19:56 ` Israel Batista
  2025-10-30 10:52   ` Lorenzo Stoakes
  2025-10-30 11:31   ` David Hildenbrand
  2025-10-29 19:56 ` [PATCH v2 2/3] mm: change type of state in struct memory_block Israel Batista
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 14+ messages in thread
From: Israel Batista @ 2025-10-29 19:56 UTC (permalink / raw)
  To: david, lorenzo.stoakes, akpm, linux-mm; +Cc: osandov, linux-debuggers

Converting the MEM_* constants from macros to an enum ensures that their
values will be correctly emitted in the debug symbols, making it easier
to trace the meaning of each value when debugging with tools such as
drgn, without the need to hard-code the values.

Since the values are mutually exclusive and they are not exposed directly to
userspace, I also dropped the misleading pattern (1<<X) that made it look like
they were combinable flags.

Signed-off-by: Israel Batista <linux@israelbatista.dev.br>
---
 include/linux/memory.h | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/linux/memory.h b/include/linux/memory.h
index 0c214256216f..f4e358477c6a 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -64,6 +64,18 @@ struct memory_group {
 	};
 };
 
+enum memory_block_state {
+	/* These states are exposed to userspace as text strings in sysfs */
+	MEM_ONLINE,		/* exposed to userspace */
+	MEM_GOING_OFFLINE,	/* exposed to userspace */
+	MEM_OFFLINE,		/* exposed to userspace */
+	MEM_GOING_ONLINE,
+	MEM_CANCEL_ONLINE,
+	MEM_CANCEL_OFFLINE,
+	MEM_PREPARE_ONLINE,
+	MEM_FINISH_OFFLINE,
+};
+
 struct memory_block {
 	unsigned long start_section_nr;
 	unsigned long state;		/* serialized by the dev->lock */
@@ -89,16 +101,6 @@ 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)
-#define	MEM_PREPARE_ONLINE	(1<<6)
-#define	MEM_FINISH_OFFLINE	(1<<7)
-
 struct memory_notify {
 	/*
 	 * The altmap_start_pfn and altmap_nr_pages fields are designated for
-- 
2.51.0



^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v2 2/3] mm: change type of state in struct memory_block
  2025-10-29 19:56 [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Israel Batista
  2025-10-29 19:56 ` [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum Israel Batista
@ 2025-10-29 19:56 ` Israel Batista
  2025-10-29 20:59   ` Randy Dunlap
                     ` (2 more replies)
  2025-10-29 19:56 ` [PATCH v2 3/3] mm: change type of parameter for memory_notify Israel Batista
  2025-10-30 14:57 ` [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Mike Rapoport
  3 siblings, 3 replies; 14+ messages in thread
From: Israel Batista @ 2025-10-29 19:56 UTC (permalink / raw)
  To: david, lorenzo.stoakes, akpm, linux-mm; +Cc: osandov, linux-debuggers

The state of a memory block should be restricted to values specified
in the documentation of the memory hotplug API. However, since the
state field in the memory_block struct was defined as an unsigned
long, this restriction was not enforced at compile time.

With the introduction of the enum memory_block_state, it is now possible
to incorporate the desired semantics in the field declaration and
enforce these restrictions at compile time.

Signed-off-by: Israel Batista <linux@israelbatista.dev.br>
---
 drivers/base/memory.c  | 2 +-
 include/linux/memory.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 6d84a02cfa5d..3d17dd774947 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -198,7 +198,7 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr,
 		break;
 	default:
 		WARN_ON(1);
-		return sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n", mem->state);
+		return sysfs_emit(buf, "ERROR-UNKNOWN-%d\n", mem->state);
 	}
 
 	return sysfs_emit(buf, "%s\n", output);
diff --git a/include/linux/memory.h b/include/linux/memory.h
index f4e358477c6a..36d733283329 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -78,7 +78,7 @@ enum memory_block_state {
 
 struct memory_block {
 	unsigned long start_section_nr;
-	unsigned long state;		/* serialized by the dev->lock */
+	enum memory_block_state state; /* serialized by the dev->lock */
 	int online_type;		/* for passing data to online routine */
 	int nid;			/* NID for this memory block */
 	/*
-- 
2.51.0



^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v2 3/3] mm: change type of parameter for memory_notify
  2025-10-29 19:56 [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Israel Batista
  2025-10-29 19:56 ` [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum Israel Batista
  2025-10-29 19:56 ` [PATCH v2 2/3] mm: change type of state in struct memory_block Israel Batista
@ 2025-10-29 19:56 ` Israel Batista
  2025-10-30 10:56   ` Lorenzo Stoakes
  2025-10-30 14:57 ` [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Mike Rapoport
  3 siblings, 1 reply; 14+ messages in thread
From: Israel Batista @ 2025-10-29 19:56 UTC (permalink / raw)
  To: david, lorenzo.stoakes, akpm, linux-mm; +Cc: osandov, linux-debuggers

The memory_notify function is responsible for sending events related to
memory hotplugging to a notification queue. Since all the events must
match one of the values from the enum memory_block_state, it is
appropriate to change the function parameter type to make this
condition explicit at compile time.

Signed-off-by: Israel Batista <linux@israelbatista.dev.br>
---
 drivers/base/memory.c  | 4 ++--
 include/linux/memory.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 3d17dd774947..c03f3b5e5e6f 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -204,9 +204,9 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr,
 	return sysfs_emit(buf, "%s\n", output);
 }
 
-int memory_notify(unsigned long val, void *v)
+int memory_notify(enum memory_block_state state, void *v)
 {
-	return blocking_notifier_call_chain(&memory_chain, val, v);
+	return blocking_notifier_call_chain(&memory_chain, state, v);
 }
 
 #if defined(CONFIG_MEMORY_FAILURE) && defined(CONFIG_MEMORY_HOTPLUG)
diff --git a/include/linux/memory.h b/include/linux/memory.h
index 36d733283329..6a2456686bf4 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -141,7 +141,7 @@ static inline int register_memory_notifier(struct notifier_block *nb)
 static inline void unregister_memory_notifier(struct notifier_block *nb)
 {
 }
-static inline int memory_notify(unsigned long val, void *v)
+static inline int memory_notify(enum memory_block_state state, void *v)
 {
 	return 0;
 }
@@ -165,7 +165,7 @@ int create_memory_block_devices(unsigned long start, unsigned long size,
 				struct memory_group *group);
 void remove_memory_block_devices(unsigned long start, unsigned long size);
 extern void memory_dev_init(void);
-extern int memory_notify(unsigned long val, void *v);
+extern int memory_notify(enum memory_block_state state, void *v);
 extern struct memory_block *find_memory_block(unsigned long section_nr);
 typedef int (*walk_memory_blocks_func_t)(struct memory_block *, void *);
 extern int walk_memory_blocks(unsigned long start, unsigned long size,
-- 
2.51.0



^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 2/3] mm: change type of state in struct memory_block
  2025-10-29 19:56 ` [PATCH v2 2/3] mm: change type of state in struct memory_block Israel Batista
@ 2025-10-29 20:59   ` Randy Dunlap
  2025-10-30 11:00   ` Lorenzo Stoakes
  2025-10-30 11:32   ` David Hildenbrand
  2 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2025-10-29 20:59 UTC (permalink / raw)
  To: Israel Batista, david, lorenzo.stoakes, akpm, linux-mm
  Cc: osandov, linux-debuggers



On 10/29/25 12:56 PM, Israel Batista wrote:
> The state of a memory block should be restricted to values specified
> in the documentation of the memory hotplug API. However, since the
> state field in the memory_block struct was defined as an unsigned
> long, this restriction was not enforced at compile time.
> 
> With the introduction of the enum memory_block_state, it is now possible
> to incorporate the desired semantics in the field declaration and
> enforce these restrictions at compile time.
> 
> Signed-off-by: Israel Batista <linux@israelbatista.dev.br>
> ---
>  drivers/base/memory.c  | 2 +-
>  include/linux/memory.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 6d84a02cfa5d..3d17dd774947 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -198,7 +198,7 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr,
>  		break;
>  	default:
>  		WARN_ON(1);
> -		return sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n", mem->state);
> +		return sysfs_emit(buf, "ERROR-UNKNOWN-%d\n", mem->state);
>  	}
>  
>  	return sysfs_emit(buf, "%s\n", output);
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index f4e358477c6a..36d733283329 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -78,7 +78,7 @@ enum memory_block_state {
>  
>  struct memory_block {
>  	unsigned long start_section_nr;
> -	unsigned long state;		/* serialized by the dev->lock */
> +	enum memory_block_state state; /* serialized by the dev->lock */

Use a tab after the ';' please, instead of a space, to align the comments.

>  	int online_type;		/* for passing data to online routine */
>  	int nid;			/* NID for this memory block */
>  	/*

-- 
~Randy



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum
  2025-10-29 19:56 ` [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum Israel Batista
@ 2025-10-30 10:52   ` Lorenzo Stoakes
  2025-10-30 11:31   ` David Hildenbrand
  1 sibling, 0 replies; 14+ messages in thread
From: Lorenzo Stoakes @ 2025-10-30 10:52 UTC (permalink / raw)
  To: Israel Batista; +Cc: david, akpm, linux-mm, osandov, linux-debuggers

On Wed, Oct 29, 2025 at 07:56:28PM +0000, Israel Batista wrote:
> Converting the MEM_* constants from macros to an enum ensures that their
> values will be correctly emitted in the debug symbols, making it easier
> to trace the meaning of each value when debugging with tools such as
> drgn, without the need to hard-code the values.
>
> Since the values are mutually exclusive and they are not exposed directly to
> userspace, I also dropped the misleading pattern (1<<X) that made it look like
> they were combinable flags.
>
> Signed-off-by: Israel Batista <linux@israelbatista.dev.br>

LGTM, so:

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> ---
>  include/linux/memory.h | 22 ++++++++++++----------
>  1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index 0c214256216f..f4e358477c6a 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -64,6 +64,18 @@ struct memory_group {
>  	};
>  };
>
> +enum memory_block_state {
> +	/* These states are exposed to userspace as text strings in sysfs */
> +	MEM_ONLINE,		/* exposed to userspace */
> +	MEM_GOING_OFFLINE,	/* exposed to userspace */
> +	MEM_OFFLINE,		/* exposed to userspace */
> +	MEM_GOING_ONLINE,
> +	MEM_CANCEL_ONLINE,
> +	MEM_CANCEL_OFFLINE,
> +	MEM_PREPARE_ONLINE,
> +	MEM_FINISH_OFFLINE,
> +};
> +
>  struct memory_block {
>  	unsigned long start_section_nr;
>  	unsigned long state;		/* serialized by the dev->lock */
> @@ -89,16 +101,6 @@ 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)
> -#define	MEM_PREPARE_ONLINE	(1<<6)
> -#define	MEM_FINISH_OFFLINE	(1<<7)
> -
>  struct memory_notify {
>  	/*
>  	 * The altmap_start_pfn and altmap_nr_pages fields are designated for
> --
> 2.51.0
>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 3/3] mm: change type of parameter for memory_notify
  2025-10-29 19:56 ` [PATCH v2 3/3] mm: change type of parameter for memory_notify Israel Batista
@ 2025-10-30 10:56   ` Lorenzo Stoakes
  2025-10-30 11:16     ` Israel Batista
  0 siblings, 1 reply; 14+ messages in thread
From: Lorenzo Stoakes @ 2025-10-30 10:56 UTC (permalink / raw)
  To: Israel Batista; +Cc: david, akpm, linux-mm, osandov, linux-debuggers

On Wed, Oct 29, 2025 at 07:56:32PM +0000, Israel Batista wrote:
> The memory_notify function is responsible for sending events related to
> memory hotplugging to a notification queue. Since all the events must
> match one of the values from the enum memory_block_state, it is
> appropriate to change the function parameter type to make this
> condition explicit at compile time.
>
> Signed-off-by: Israel Batista <linux@israelbatista.dev.br>

This seems fine, but I can see a whole bunch of others like:

kcore_callback()
mm_compute_batch_notifier()
page_ext_callback()
reserve_mem_notiifer()
etc.

So I think worth chasing all of these down?

Some of the switches which don't cover all cases will need to be adjusted to
insert a no-op default:

> ---
>  drivers/base/memory.c  | 4 ++--
>  include/linux/memory.h | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 3d17dd774947..c03f3b5e5e6f 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -204,9 +204,9 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr,
>  	return sysfs_emit(buf, "%s\n", output);
>  }
>
> -int memory_notify(unsigned long val, void *v)
> +int memory_notify(enum memory_block_state state, void *v)
>  {
> -	return blocking_notifier_call_chain(&memory_chain, val, v);
> +	return blocking_notifier_call_chain(&memory_chain, state, v);
>  }
>
>  #if defined(CONFIG_MEMORY_FAILURE) && defined(CONFIG_MEMORY_HOTPLUG)
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index 36d733283329..6a2456686bf4 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -141,7 +141,7 @@ static inline int register_memory_notifier(struct notifier_block *nb)
>  static inline void unregister_memory_notifier(struct notifier_block *nb)
>  {
>  }
> -static inline int memory_notify(unsigned long val, void *v)
> +static inline int memory_notify(enum memory_block_state state, void *v)
>  {
>  	return 0;
>  }
> @@ -165,7 +165,7 @@ int create_memory_block_devices(unsigned long start, unsigned long size,
>  				struct memory_group *group);
>  void remove_memory_block_devices(unsigned long start, unsigned long size);
>  extern void memory_dev_init(void);
> -extern int memory_notify(unsigned long val, void *v);
> +extern int memory_notify(enum memory_block_state state, void *v);

No reason you'd know, but we have a pattern of removing extraneous extern's like
this when we otherwise change a line.

>  extern struct memory_block *find_memory_block(unsigned long section_nr);
>  typedef int (*walk_memory_blocks_func_t)(struct memory_block *, void *);
>  extern int walk_memory_blocks(unsigned long start, unsigned long size,
> --
> 2.51.0
>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 2/3] mm: change type of state in struct memory_block
  2025-10-29 19:56 ` [PATCH v2 2/3] mm: change type of state in struct memory_block Israel Batista
  2025-10-29 20:59   ` Randy Dunlap
@ 2025-10-30 11:00   ` Lorenzo Stoakes
  2025-10-30 11:32   ` David Hildenbrand
  2 siblings, 0 replies; 14+ messages in thread
From: Lorenzo Stoakes @ 2025-10-30 11:00 UTC (permalink / raw)
  To: Israel Batista; +Cc: david, akpm, linux-mm, osandov, linux-debuggers

On Wed, Oct 29, 2025 at 07:56:30PM +0000, Israel Batista wrote:
> The state of a memory block should be restricted to values specified
> in the documentation of the memory hotplug API. However, since the
> state field in the memory_block struct was defined as an unsigned
> long, this restriction was not enforced at compile time.
>
> With the introduction of the enum memory_block_state, it is now possible
> to incorporate the desired semantics in the field declaration and
> enforce these restrictions at compile time.

Well I'm not sure how much is enforced at compile time, the compiler treats
the enum very loosely as if it were simply an int. BUt it does make it
clear what you expect this field to contain!

>
> Signed-off-by: Israel Batista <linux@israelbatista.dev.br>

This LGTM as a reasonable change though, so:

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

On basis that you fixup the formatting issue raised by Randy.

> ---
>  drivers/base/memory.c  | 2 +-
>  include/linux/memory.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 6d84a02cfa5d..3d17dd774947 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -198,7 +198,7 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr,
>  		break;
>  	default:
>  		WARN_ON(1);
> -		return sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n", mem->state);
> +		return sysfs_emit(buf, "ERROR-UNKNOWN-%d\n", mem->state);
>  	}
>
>  	return sysfs_emit(buf, "%s\n", output);
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index f4e358477c6a..36d733283329 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -78,7 +78,7 @@ enum memory_block_state {
>
>  struct memory_block {
>  	unsigned long start_section_nr;
> -	unsigned long state;		/* serialized by the dev->lock */
> +	enum memory_block_state state; /* serialized by the dev->lock */

I doubt it will be an isuse, but this obviously changes the layout of the
struct.

However since this will be an int and you have a bunch of ints here it should
all pad reasonably.

>  	int online_type;		/* for passing data to online routine */
>  	int nid;			/* NID for this memory block */
>  	/*
> --
> 2.51.0
>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 3/3] mm: change type of parameter for memory_notify
  2025-10-30 10:56   ` Lorenzo Stoakes
@ 2025-10-30 11:16     ` Israel Batista
  2025-10-30 11:34       ` David Hildenbrand
  0 siblings, 1 reply; 14+ messages in thread
From: Israel Batista @ 2025-10-30 11:16 UTC (permalink / raw)
  To: Lorenzo Stoakes; +Cc: david, akpm, linux-mm, osandov, linux-debuggers



On 10/30/25 07:56, Lorenzo Stoakes wrote:
> This seems fine, but I can see a whole bunch of others like:
> 
> kcore_callback()
> mm_compute_batch_notifier()
> page_ext_callback()
> reserve_mem_notiifer()
> etc.
> 
> So I think worth chasing all of these down?
> 

Yeah, I figured there were other cases and was originally planning to
include them in the patch series. The problem is they are notifier
callbacks and changing the type from unsingned long to enum
memory_block_state would break compatibility with the type notifier_fn_t
found in include/linux/notifier.h:

typedef	int (*notifier_fn_t)(struct notifier_block *nb,
			unsigned long action, void *data);

So I think it's not worth the trouble for now.

>
> Some of the switches which don't cover all cases will need to be adjusted to
> insert a no-op default:
> 

Good point.

>> -extern int memory_notify(unsigned long val, void *v);
>> +extern int memory_notify(enum memory_block_state state, void *v);
> 
> No reason you'd know, but we have a pattern of removing extraneous extern's like
> this when we otherwise change a line.
> 

Oh, that's good to know, I'll update it and keep that in mind for my
next patches.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum
  2025-10-29 19:56 ` [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum Israel Batista
  2025-10-30 10:52   ` Lorenzo Stoakes
@ 2025-10-30 11:31   ` David Hildenbrand
  1 sibling, 0 replies; 14+ messages in thread
From: David Hildenbrand @ 2025-10-30 11:31 UTC (permalink / raw)
  To: Israel Batista, lorenzo.stoakes, akpm, linux-mm; +Cc: osandov, linux-debuggers

On 29.10.25 20:56, Israel Batista wrote:
> Converting the MEM_* constants from macros to an enum ensures that their
> values will be correctly emitted in the debug symbols, making it easier
> to trace the meaning of each value when debugging with tools such as
> drgn, without the need to hard-code the values.
> 
> Since the values are mutually exclusive and they are not exposed directly to
> userspace, I also dropped the misleading pattern (1<<X) that made it look like
> they were combinable flags.
> 
> Signed-off-by: Israel Batista <linux@israelbatista.dev.br>
> ---

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers

David / dhildenb



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 2/3] mm: change type of state in struct memory_block
  2025-10-29 19:56 ` [PATCH v2 2/3] mm: change type of state in struct memory_block Israel Batista
  2025-10-29 20:59   ` Randy Dunlap
  2025-10-30 11:00   ` Lorenzo Stoakes
@ 2025-10-30 11:32   ` David Hildenbrand
  2 siblings, 0 replies; 14+ messages in thread
From: David Hildenbrand @ 2025-10-30 11:32 UTC (permalink / raw)
  To: Israel Batista, lorenzo.stoakes, akpm, linux-mm; +Cc: osandov, linux-debuggers

On 29.10.25 20:56, Israel Batista wrote:
> The state of a memory block should be restricted to values specified
> in the documentation of the memory hotplug API. However, since the
> state field in the memory_block struct was defined as an unsigned
> long, this restriction was not enforced at compile time.
> 
> With the introduction of the enum memory_block_state, it is now possible
> to incorporate the desired semantics in the field declaration and
> enforce these restrictions at compile time.
> 
> Signed-off-by: Israel Batista <linux@israelbatista.dev.br>
> ---
>   drivers/base/memory.c  | 2 +-
>   include/linux/memory.h | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 6d84a02cfa5d..3d17dd774947 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -198,7 +198,7 @@ static ssize_t state_show(struct device *dev, struct device_attribute *attr,
>   		break;
>   	default:
>   		WARN_ON(1);
> -		return sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n", mem->state);
> +		return sysfs_emit(buf, "ERROR-UNKNOWN-%d\n", mem->state);
>   	}
>   
>   	return sysfs_emit(buf, "%s\n", output);
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index f4e358477c6a..36d733283329 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -78,7 +78,7 @@ enum memory_block_state {
>   
>   struct memory_block {
>   	unsigned long start_section_nr;
> -	unsigned long state;		/* serialized by the dev->lock */
> +	enum memory_block_state state; /* serialized by the dev->lock */
>   	int online_type;		/* for passing data to online routine */
>   	int nid;			/* NID for this memory block */
>   	/*

With comment alignment fixed

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers

David / dhildenb



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 3/3] mm: change type of parameter for memory_notify
  2025-10-30 11:16     ` Israel Batista
@ 2025-10-30 11:34       ` David Hildenbrand
  2025-10-30 12:00         ` Israel Batista
  0 siblings, 1 reply; 14+ messages in thread
From: David Hildenbrand @ 2025-10-30 11:34 UTC (permalink / raw)
  To: Israel Batista, Lorenzo Stoakes; +Cc: akpm, linux-mm, osandov, linux-debuggers

On 30.10.25 12:16, Israel Batista wrote:
> 
> 
> On 10/30/25 07:56, Lorenzo Stoakes wrote:
>> This seems fine, but I can see a whole bunch of others like:
>>
>> kcore_callback()
>> mm_compute_batch_notifier()
>> page_ext_callback()
>> reserve_mem_notiifer()
>> etc.
>>
>> So I think worth chasing all of these down?
>>
> 
> Yeah, I figured there were other cases and was originally planning to
> include them in the patch series. The problem is they are notifier
> callbacks and changing the type from unsingned long to enum
> memory_block_state would break compatibility with the type notifier_fn_t
> found in include/linux/notifier.h:
> 
> typedef	int (*notifier_fn_t)(struct notifier_block *nb,
> 			unsigned long action, void *data);
> 
> So I think it's not worth the trouble for now.

We could just cat from unsigned long -> type at the beginning of all 
these notifiers to have us then work with the actual type.

-- 
Cheers

David / dhildenb



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 3/3] mm: change type of parameter for memory_notify
  2025-10-30 11:34       ` David Hildenbrand
@ 2025-10-30 12:00         ` Israel Batista
  0 siblings, 0 replies; 14+ messages in thread
From: Israel Batista @ 2025-10-30 12:00 UTC (permalink / raw)
  To: David Hildenbrand, Lorenzo Stoakes
  Cc: akpm, linux-mm, osandov, linux-debuggers



On 10/30/25 08:34, David Hildenbrand wrote:
> On 30.10.25 12:16, Israel Batista wrote:
>>
>>
>> On 10/30/25 07:56, Lorenzo Stoakes wrote:
>>> This seems fine, but I can see a whole bunch of others like:
>>>
>>> kcore_callback()
>>> mm_compute_batch_notifier()
>>> page_ext_callback()
>>> reserve_mem_notiifer()
>>> etc.
>>>
>>> So I think worth chasing all of these down?
>>>
>>
>> Yeah, I figured there were other cases and was originally planning to
>> include them in the patch series. The problem is they are notifier
>> callbacks and changing the type from unsingned long to enum
>> memory_block_state would break compatibility with the type notifier_fn_t
>> found in include/linux/notifier.h:
>>
>> typedef    int (*notifier_fn_t)(struct notifier_block *nb,
>>             unsigned long action, void *data);
>>
>> So I think it's not worth the trouble for now.
> 
> We could just cat from unsigned long -> type at the beginning of all 
> these notifiers to have us then work with the actual type.
> 

Right, that works.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to
  2025-10-29 19:56 [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Israel Batista
                   ` (2 preceding siblings ...)
  2025-10-29 19:56 ` [PATCH v2 3/3] mm: change type of parameter for memory_notify Israel Batista
@ 2025-10-30 14:57 ` Mike Rapoport
  3 siblings, 0 replies; 14+ messages in thread
From: Mike Rapoport @ 2025-10-30 14:57 UTC (permalink / raw)
  To: Israel Batista
  Cc: david, lorenzo.stoakes, akpm, linux-mm, osandov, linux-debuggers

On Wed, Oct 29, 2025 at 07:56:26PM +0000, Israel Batista wrote:
> The MEM_* constants indicating the state of a 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.
> 
> Converting the constants to an enum would 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.
> 
> This patch series aims to replace the current macros with a newly
> created enum named memory_block_state, while also taking advantage of
> the compile time guarantees that we get when using enums.
> 
> The first patch does the conversion of the macros to an enum, while the
> 2nd and 3rd patches use this enum to clean up some type declarations and
> make sure that only valid values are used.
> 
> ---
> 
> Link: https://lore.kernel.org/linux-mm/20251026162156.12141-1-linux@israelbatista.dev.br/ [v1]
> 
> v1 -> v2
> - Rename the enum to make it more descriptive.
> - Let the enum auto-generate the values, as the (1<<X) pattern could be
>   misleading and they're not exposed to userspace.
> - Change the type signature from unsigned long to enum memory_block_state
>   where suitable.
> 
> Thanks to everyone who took their time to review the first version.
> 
> This patch series applies to commit: f30d294530d9 (mm-new)
> 
> Israel Batista (3):
>   mm: convert memory block states (MEM_*) macros to enum
>   mm: change type of state in struct memory_block
>   mm: change type of parameter for memory_notify
> 
>  drivers/base/memory.c  |  6 +++---
>  include/linux/memory.h | 28 +++++++++++++++-------------
>  2 files changed, 18 insertions(+), 16 deletions(-)

I wonder if we need three patches for this, but regardless

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
 
> -- 
> 2.51.0
> 

-- 
Sincerely yours,
Mike.


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2025-10-30 14:57 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-29 19:56 [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Israel Batista
2025-10-29 19:56 ` [PATCH v2 1/3] mm: convert memory block states (MEM_*) macros to enum Israel Batista
2025-10-30 10:52   ` Lorenzo Stoakes
2025-10-30 11:31   ` David Hildenbrand
2025-10-29 19:56 ` [PATCH v2 2/3] mm: change type of state in struct memory_block Israel Batista
2025-10-29 20:59   ` Randy Dunlap
2025-10-30 11:00   ` Lorenzo Stoakes
2025-10-30 11:32   ` David Hildenbrand
2025-10-29 19:56 ` [PATCH v2 3/3] mm: change type of parameter for memory_notify Israel Batista
2025-10-30 10:56   ` Lorenzo Stoakes
2025-10-30 11:16     ` Israel Batista
2025-10-30 11:34       ` David Hildenbrand
2025-10-30 12:00         ` Israel Batista
2025-10-30 14:57 ` [PATCH v2 0/3] mm: Convert memory block states (MEM_*) macros to Mike Rapoport

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).