Add thin wrappers around zone lock acquire/release operations. This
prepares the code for future tracepoint instrumentation without
modifying individual call sites.
Centralizing zone lock operations behind wrappers allows future
instrumentation or debugging hooks to be added without touching
all users.
No functional change intended. The wrappers are introduced in
preparation for subsequent patches and are not yet used.
Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
---
MAINTAINERS | 1 +
include/linux/zone_lock.h | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
create mode 100644 include/linux/zone_lock.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 55af015174a5..61e3d1f5bf43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16680,6 +16680,7 @@ F: include/linux/pgtable.h
F: include/linux/ptdump.h
F: include/linux/vmpressure.h
F: include/linux/vmstat.h
+F: include/linux/zone_lock.h
F: kernel/fork.c
F: mm/Kconfig
F: mm/debug.c
diff --git a/include/linux/zone_lock.h b/include/linux/zone_lock.h
new file mode 100644
index 000000000000..c531e26280e6
--- /dev/null
+++ b/include/linux/zone_lock.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_ZONE_LOCK_H
+#define _LINUX_ZONE_LOCK_H
+
+#include <linux/mmzone.h>
+#include <linux/spinlock.h>
+
+static inline void zone_lock_init(struct zone *zone)
+{
+ spin_lock_init(&zone->lock);
+}
+
+#define zone_lock_irqsave(zone, flags) \
+do { \
+ spin_lock_irqsave(&(zone)->lock, flags); \
+} while (0)
+
+#define zone_trylock_irqsave(zone, flags) \
+({ \
+ spin_trylock_irqsave(&(zone)->lock, flags); \
+})
+
+static inline void zone_unlock_irqrestore(struct zone *zone, unsigned long flags)
+{
+ spin_unlock_irqrestore(&zone->lock, flags);
+}
+
+static inline void zone_lock_irq(struct zone *zone)
+{
+ spin_lock_irq(&zone->lock);
+}
+
+static inline void zone_unlock_irq(struct zone *zone)
+{
+ spin_unlock_irq(&zone->lock);
+}
+
+#endif /* _LINUX_ZONE_LOCK_H */
--
2.47.3I should sent this together with the previous reply, but I forgot as usual,
sorry.
On Thu, 26 Feb 2026 18:26:18 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> Add thin wrappers around zone lock acquire/release operations. This
> prepares the code for future tracepoint instrumentation without
> modifying individual call sites.
>
> Centralizing zone lock operations behind wrappers allows future
> instrumentation or debugging hooks to be added without touching
> all users.
>
> No functional change intended. The wrappers are introduced in
> preparation for subsequent patches and are not yet used.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> ---
[...]
> --- /dev/null
> +++ b/include/linux/zone_lock.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_ZONE_LOCK_H
> +#define _LINUX_ZONE_LOCK_H
> +
> +#include <linux/mmzone.h>
> +#include <linux/spinlock.h>
> +
> +static inline void zone_lock_init(struct zone *zone)
> +{
> + spin_lock_init(&zone->lock);
> +}
> +
> +#define zone_lock_irqsave(zone, flags) \
> +do { \
> + spin_lock_irqsave(&(zone)->lock, flags); \
> +} while (0)
checkpatch.pl complains as below. Should be ok to ignore, but, may better to
kindly make it silence?
WARNING: Single statement macros should not use a do {} while (0) loop
#116: FILE: include/linux/zone_lock.h:13:
+#define zone_lock_irqsave(zone, flags) \
+do { \
+ spin_lock_irqsave(&(zone)->lock, flags); \
+} while (0)
Thanks,
SJ
[...]
On Thu, 26 Feb 2026 16:38:55 -0800
SeongJae Park <sj@kernel.org> wrote:
> checkpatch.pl complains as below. Should be ok to ignore, but, may better to
> kindly make it silence?
>
> WARNING: Single statement macros should not use a do {} while (0) loop
Hmm, why is this an issue?
> #116: FILE: include/linux/zone_lock.h:13:
> +#define zone_lock_irqsave(zone, flags) \
> +do { \
> + spin_lock_irqsave(&(zone)->lock, flags); \
> +} while (0)
>
I know this is checkpatch and not you complaining about it, but I really
think it's a useless complaint. I can see it better as a do { } while (0)
because it is creating a "function" like feature but can't be inline due to
flags.
This is one of the reasons I still never use checkpatch.pl :-(
-- Steve
On Thu, 26 Feb 2026 19:53:55 -0500 Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 26 Feb 2026 16:38:55 -0800
> SeongJae Park <sj@kernel.org> wrote:
>
> > checkpatch.pl complains as below. Should be ok to ignore, but, may better to
> > kindly make it silence?
> >
> > WARNING: Single statement macros should not use a do {} while (0) loop
>
> Hmm, why is this an issue?
>
> > #116: FILE: include/linux/zone_lock.h:13:
> > +#define zone_lock_irqsave(zone, flags) \
> > +do { \
> > + spin_lock_irqsave(&(zone)->lock, flags); \
> > +} while (0)
> >
>
> I know this is checkpatch and not you complaining about it, but I really
> think it's a useless complaint. I can see it better as a do { } while (0)
> because it is creating a "function" like feature but can't be inline due to
> flags.
>
> This is one of the reasons I still never use checkpatch.pl :-(
Makes sense to me, thank you Steve :)
Thanks,
SJ
[...]
On Thu, 26 Feb 2026 18:26:18 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote: > Add thin wrappers around zone lock acquire/release operations. This > prepares the code for future tracepoint instrumentation without > modifying individual call sites. > > Centralizing zone lock operations behind wrappers allows future > instrumentation or debugging hooks to be added without touching > all users. > > No functional change intended. The wrappers are introduced in > preparation for subsequent patches and are not yet used. > > Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com> > Acked-by: Shakeel Butt <shakeel.butt@linux.dev> > --- > MAINTAINERS | 1 + > include/linux/zone_lock.h | 38 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 39 insertions(+) > create mode 100644 include/linux/zone_lock.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 55af015174a5..61e3d1f5bf43 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -16680,6 +16680,7 @@ F: include/linux/pgtable.h > F: include/linux/ptdump.h > F: include/linux/vmpressure.h > F: include/linux/vmstat.h > +F: include/linux/zone_lock.h > F: kernel/fork.c > F: mm/Kconfig > F: mm/debug.c > diff --git a/include/linux/zone_lock.h b/include/linux/zone_lock.h > new file mode 100644 > index 000000000000..c531e26280e6 > --- /dev/null > +++ b/include/linux/zone_lock.h > @@ -0,0 +1,38 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_ZONE_LOCK_H > +#define _LINUX_ZONE_LOCK_H > + > +#include <linux/mmzone.h> > +#include <linux/spinlock.h> I'm bit worried if I will think this as a file for another general locking, not the mm specific one. I hence think renaming it to more clearly saying the fact, say, mmzone_lock.h, might be less confusing. Or, putting things in mmzone.h might also be an option? What do you think? Thanks, SJ [...]
On Thu, Feb 26, 2026 at 04:31:39PM -0800, SeongJae Park wrote: > On Thu, 26 Feb 2026 18:26:18 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote: > > > Add thin wrappers around zone lock acquire/release operations. This > > prepares the code for future tracepoint instrumentation without > > modifying individual call sites. > > > > Centralizing zone lock operations behind wrappers allows future > > instrumentation or debugging hooks to be added without touching > > all users. > > > > No functional change intended. The wrappers are introduced in > > preparation for subsequent patches and are not yet used. > > > > Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com> > > Acked-by: Shakeel Butt <shakeel.butt@linux.dev> > > --- > > MAINTAINERS | 1 + > > include/linux/zone_lock.h | 38 ++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 39 insertions(+) > > create mode 100644 include/linux/zone_lock.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 55af015174a5..61e3d1f5bf43 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -16680,6 +16680,7 @@ F: include/linux/pgtable.h > > F: include/linux/ptdump.h > > F: include/linux/vmpressure.h > > F: include/linux/vmstat.h > > +F: include/linux/zone_lock.h > > F: kernel/fork.c > > F: mm/Kconfig > > F: mm/debug.c > > diff --git a/include/linux/zone_lock.h b/include/linux/zone_lock.h > > new file mode 100644 > > index 000000000000..c531e26280e6 > > --- /dev/null > > +++ b/include/linux/zone_lock.h > > @@ -0,0 +1,38 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef _LINUX_ZONE_LOCK_H > > +#define _LINUX_ZONE_LOCK_H > > + > > +#include <linux/mmzone.h> > > +#include <linux/spinlock.h> > > I'm bit worried if I will think this as a file for another general locking, not > the mm specific one. I hence think renaming it to more clearly saying the > fact, say, mmzone_lock.h, might be less confusing. Or, putting things in > mmzone.h might also be an option? What do you think? Thanks for the feedback, SJ. Good point. I agree the current name looks too generic. Putting it into mmzone.h would further overload that header, so renaming zone_lock.h to mmzone_lock.h seems like the clearest option. I'll make that change in v4. > > > Thanks, > SJ > > [...]
© 2016 - 2026 Red Hat, Inc.