From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-240.mta0.migadu.com [91.218.175.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08D3448D883 for ; Wed, 12 Aug 2026 23:40:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.240 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786578064; cv=none; b=bUayFv4ZQqgz5/9Wllsx4bOFBOsvC4Ab1sF+6cbommZPl1VjLiW43zKtJKUSZonxDDea+jfkROj8Z4ytgdrUu6atGOHWCTP+FsHcIIkRkkfK+jaFfPRbFxuCZMoJVvw1AGIa8w2WZyGBwQEKaSTLS8rX0EEHuf6wWGTmAMr7+3M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786578064; c=relaxed/simple; bh=yase8ojYlvTroh3czrYooSzU3qkMRoxgGLJx7SI36pA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QnkbmJZmow5vJTarcdcShwmBXAge51XsO7Qj3pffLAtXGEyuRPataiOjDiRUmsJaDbxFHPwb7CCFZRwQYT42JY4k4JZbn7uk4+xOF4n3jxLh6WdWAt6IkxsYkpytMJhXDDTNjYXNVJfQe+ThMw6cOy7SlIUlkNwik69/eGGQuGQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=SOtQe+VC; arc=none smtp.client-ip=91.218.175.240 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="SOtQe+VC" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=yase8ojYlvTroh3czrYooSzU3qkMRoxgGLJx7SI36pA=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786578057; v=1; x=1787182857; b=SOtQe+VCa2lKT2DRQ26s0zYpWrbz7Q4CIoZA4353SDSd0SNZBT2fQzOjlHr8lGkm1vqEpSnP pekpHhPgbbUqunc7/NWektN8D2uB9kIHK0cP/aMN17xGIJGPZXN1TTS6srHB41AW27QCEwsOrXu CdffMo+aZy8Rci+7CcDFMkCk= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (2a03:2880:10ff:16::) by smtp.migadu.com with ESMTPS id 8bf1ca111f2545f7; Wed, 12 Aug 2026 23:40:46 +0000 X-Migadu-Flow: FLOW_OUT Date: Wed, 12 Aug 2026 16:40:41 -0700 From: Shakeel Butt To: Andrew Morton Cc: Michal Hocko , Johannes Weiner , Roman Gushchin , Muchun Song , David Hildenbrand , Lorenzo Stoakes , Kairui Song , Qi Zheng , Barry Song , Axel Rasmussen , Meta kernel team , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com Subject: Re: [PATCH 1/9] memcg: make the v1 soft limit knob inert Message-ID: References: <20260811203203.3456029-1-shakeel.butt@linux.dev> <20260811203203.3456029-2-shakeel.butt@linux.dev> <20260812155010.8710b4a9191c9ee4ad6da255@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260812155010.8710b4a9191c9ee4ad6da255@linux-foundation.org> On Wed, Aug 12, 2026 at 03:50:10PM -0700, Andrew Morton wrote: > On Tue, 11 Aug 2026 13:31:55 -0700 Shakeel Butt 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.