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

[Michal Hocko <mhocko@suse.com>]

On Fri 20-03-26 03:39:40, Bing Jiao wrote:
> 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).

OK, that is always good to clarify in the changelog.
-- 
Michal Hocko
SUSE Labs