Re: [PATCH v2 1/2] mm: introduce memalloc_flags_move() for transferring allocation scopes

Andrew Morton <[email protected]>
Newsgroups org.kernel.vger.linux-xfs,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <[email protected]>
On Sun, 19 Jul 2026 17:57:31 +0800 Yun Zhou <[email protected]> wrote:

> Add memalloc_flags_move() to transfer a saved memalloc scope from one
> tracking variable to another.  The source is zeroed so that a
> subsequent memalloc_flags_restore() on it becomes a no-op, effectively
> transferring ownership of the scope to the destination.
> 
> This is needed when a subsystem hands off an allocation context from
> one structure to another (e.g. during transaction rolling in
> filesystems), and needs to ensure the scope remains active without an
> extra save/restore cycle.
> 
> ...
>

Thanks.  fyi, Sashiko might have found a pre-existing xfs issue:
	https://sashiko.dev/#/patchset/[email protected]

>  include/linux/sched/mm.h | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)

This file isn't mentioned in MAINTAINERS.  Could someone please propose
a patch?

From the MM side, probably just place it in every record which mentions
include/linux/mm.h - close enough.

> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -342,6 +342,23 @@ static inline void memalloc_flags_restore(unsigned flags)
>  	current->flags &= ~flags;
>  }
>  
> +/**
> + * memalloc_flags_move - transfer a memalloc scope from one tracking
> + * variable to another.
> + * @old_flags: pointer to the source flags (will be zeroed)
> + *
> + * Returns the flags value to store in the destination.  The source is
> + * set to zero so that a subsequent memalloc_flags_restore() on it is
> + * a no-op.
> + */
> +static inline unsigned int memalloc_flags_move(unsigned int *old_flags)
> +{
> +	unsigned int ret = *old_flags;
> +
> +	*old_flags = 0;
> +	return ret;
> +}
> +

I've added linux-mm to cc here.  Please include it in any future
versions of this patchset.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.