Re: [PATCH v6 3/4] mm: huge_memory: refactor enabled_store() with change_enabled()

Sohil Mehta
2026-03-13T22:31:40Z

Hello,

On 3/11/2026 3:17 AM, Breno Leitao wrote:

> +static bool set_global_enabled_mode(enum global_enabled_mode mode)
> +{
> + static const unsigned long thp_flags[] = {
> + TRANSPARENT_HUGEPAGE_FLAG,
> + TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
> + };
> + enum global_enabled_mode m;
> + bool changed = false;
> +
> + for (m = 0; m < ARRAY_SIZE(thp_flags); m++) {
> + if (m == mode)
> + changed |= !__test_and_set_bit(thp_flags[m],
> + &transparent_hugepage_flags);
> + else
> + changed |= __test_and_clear_bit(thp_flags[m],
> + &transparent_hugepage_flags);

I am not a mm expert and typically do not follow the mm list. Is there
an issue with the usage of non-atomic variants here? The commit message
says this uses the same pattern as set_anon_enabled_mode().

However, set_anon_enabled_mode() has a spinlock=>huge_anon_orders_lock
protecting the access. But, transparent_hugepage_flags seems to be
unprotected in that regard.

IIUC, David's suggestion to use the lockless version was also based on
the use of a lock in that context.
https://lore.kernel.org/all/4f2abf42-983f-4cc2-92f5-c81827e7b7e2@kernel.org/

Note: We ran into this issue while experimenting with an AI review agent
internally. The patch was selected at random from the mailing list. I
analyzed the issue independently and came to the same conclusion. I
apologize if this is a false alarm.

> + }
> +
> + return changed;
> +}
> +