Re: [PATCH v3] mm/memcontrol: fix reclaim_options leak in try_charge_memcg()

[Bing Jiao <bingjiao@google.com>]

On Thu, Mar 19, 2026 at 10:29:15AM +0100, Michal Hocko wrote:
> On Wed 18-03-26 22:19:46, Bing Jiao wrote:
> > In try_charge_memcg(), the 'reclaim_options' variable is initialized
> > once at the start of the function. However, the function contains a
> > retry loop. If reclaim_options were modified during an iteration
> > (e.g., by encountering a memsw limit), the modified state would
> > persist into subsequent retries.
> >
> > This leads to incorrect reclaim behavior. Specifically,
> > MEMCG_RECLAIM_MAY_SWAP is cleared when the combined memcg->memsw limit
> > is reached. After reclaimation attemps, a subsequent retry may
> > successfully charge memcg->memsw but fail on the memcg->memory charge.
> > In this case, swapping should be permitted, but the carried-over state
> > prevents it.
>
> Have you noticed this happening in practice or is this based on the code
> reading?

Hi, Michal, thanks for the ack.

This issue was identified during code reading, when I was analyzing
the memsw limit behavior in try_charge_memcg(); specifically how
retries are handled when demotion is disabled (the demotion patch
itself was dropped).

Best,
Bing