Re: [PATCH 1/4] mm: introduce zone lock wrappers

[Shakeel Butt <shakeel.butt@linux.dev>]

On Tue, Feb 24, 2026 at 03:18:04PM +0000, Dmitry Ilvokhin wrote:
> On Mon, Feb 23, 2026 at 02:36:01PM -0800, Shakeel Butt wrote:
> > On Wed, Feb 11, 2026 at 03:22:13PM +0000, Dmitry Ilvokhin 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>
> > > ---
> > >  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 b4088f7290be..680c9ae02d7e 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -16498,6 +16498,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);		\
> > > +})
> > 
> > Any reason you used macros for above two and inlined functions for remaining?
> >
> 
> The reason for using macros in those two cases is that they need to
> modify the flags variable passed by the caller, just like
> spin_lock_irqsave() and spin_trylock_irqsave() do. I followed the same
> convention here.
> 
> If we used normal inline functions instead, we would need to pass a
> pointer to flags, which would change the call sites and diverge from the
> existing *_irqsave() locking pattern.
> 
> There is also a difference between zone_lock_irqsave() and
> zone_trylock_irqsave() implementations: the former is implemented as a
> do { } while (0) macro since it does not return a value, while the
> latter uses a GCC extension in order to return the trylock result. This
> matches spin_lock_* convention as well.
> 

Cool, thanks for the explanation.