Re: [PATCH 1/9] memcg: make the v1 soft limit knob inert

Shakeel Butt <[email protected]>
Newsgroups org.kernel.vger.linux-kernel,org.kernel.vger.cgroups,org.kvack.linux-mm
Message-ID <[email protected]>
On Wed, Aug 12, 2026 at 03:50:10PM -0700, Andrew Morton wrote:
> On Tue, 11 Aug 2026 13:31:55 -0700 Shakeel Butt <[email protected]> wrote:
> 
> > The v1 soft limit has been deprecated since v6.12 and nobody has
> > reported depending on it. Start the removal by decoupling the interface
> > from the implementation: keep memory.soft_limit_in_bytes, but ignore
> > writes to it and always report the maximum value on read similar to
> > what memory.kmem.limit_in_bytes already does.
> > 
> > Writes are still parsed, so malformed input keeps returning -EINVAL.
> > The knob now also behaves the same everywhere: it used to return
> > -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been
> > disabled.
> > 
> > This also fixes the syzbot report linked below. Soft limit reclaim is
> > the only caller that runs shrink_lruvec() from kswapd against a
> > specific memcg, so it is the only way to reach lru_gen_shrink_lruvec()
> > and in turn set_mm_walk(), which warns when called from kswapd.
> 
> Thanks, I'll pluck this one as a hotfix.

Sounds good.

> 
> It's old code, yes?

Yes.

> Are there any theories about why the sysbot issue
> has just popped up?

The reproducer is toggling MGLRU on and off continuosly which is not really
recommended.


> Should we backport the fix?

I have no concerns in backporting this to older stable kernels.
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.