From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (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 5FD06477E41 for ; Wed, 15 Jul 2026 12:31:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784118665; cv=none; b=Np6NnY2M8PLlpFTxwhZ4yq6divzrRPtG9p2TvXBj2AJcGDSooA+WZR3RESVn30rKVCQ/ZLTRcJQhV5UA39hXeL3oYVkiL5hlsWAhHjFeKWfqO0UrYmZBbVAKYlepLIi/XxAp2Xqwv9f0xQnWNR0h5GZyt/I/RoVt3tJVqcCwtFA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784118665; c=relaxed/simple; bh=n69afPvxXMg5pJEtJyjh27rhLIgr92BGrls45LTgHSQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qfvcHWbdwfUb9llbjMjKy8iQbGVUc+TPWXoeZpdBfZWuKGIBP7qNLYJTTSFbyHymBSLDQBhOB9d9jyJ2LCX9dCI6anOPFPzADNhlkXR+7047ZHLmh8DYYRiEkx1gTsmoW3H9YXxiZLl8EEX4e50fzFo8OVpaVvqLr6lVdYJeDkw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=sQO+FYZX; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="sQO+FYZX" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-848761b5897so2733854b3a.3 for ; Wed, 15 Jul 2026 05:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784118664; x=1784723464; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=FL4DH6iSB8h5Gk2sonUHgNYBuRFyDX29syp4nQdWWD4=; b=sQO+FYZXlXwSVXQNNzCrbDjHIO/shqU9KIXF99Rh6myELdKJ1IO2jlm/yBFPePsTqS JT6S3Hj7KN8J2FO9Q0CFJH07ILf+c4OresvXfbwt0biaWf9VGTkLc/6PisFxqFmLTm2f yAD+w8ETJ6XSZt1BfvGQ4pZUN1MFxuHNBvBFg9jvbmtbWF2829+SZeLH0Xli5fJV6Hpk nwMIMZtCTrhvL/R44tEqWSlLiPoG5CbxqljpUeMCxFUyBVvIAlF/m49cty+i95VBAqhM X4T39CmwvT9eMTn5cWbz2IsNVip7AJSrdTor4FObMg6MHrSANNyTGRsCdje4LfQ4rxNb /E4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784118664; x=1784723464; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=FL4DH6iSB8h5Gk2sonUHgNYBuRFyDX29syp4nQdWWD4=; b=ekDu6xGsIpSgMwNW2lKY0Sr0hXHI/jjuxpBhDKmjJppeA1Wo7TQE7PugwQv/g4IVL/ 4dqfKhZ8f2jQuqKsZZG5TJ9fK0ppwGH95n+XtRq/GeHPLkTrkIMUmY44H+uSsmVnsjTM hzKZFA58IRLh8+bGJ6NhlQAMy9zIwtHO9+yxwdmrWYiI/iDMY+NO1niJhgWYmvJmdp9T jlKsCirqQWouxF17fglBPX5mbV3Bjuim9bj2/rxW+YMGLw7Ak4IiH0YF8hBiWTNutklr l5zaW9fhz1O99bda9PS/FCl30jRRtC4xUpjruwSlPLUiDFwKs/0594zDRAR7em51Ajda prXA== X-Forwarded-Encrypted: i=1; AHgh+RqaiGdXLl5OJAukX8nN8JmVI17g7toBuhMsfMcMBcNNJv5ECKqsPOLf3YIOe3TE3GZLMqYtMP4bJRPtlz0=@vger.kernel.org X-Gm-Message-State: AOJu0YyKFDrgojLHGFOWlOntUBEqAMoCPMIG55cnPhVnC2hVmpuVr0zN ZXgpyeVpdZI6dxp7M0H4nm/BLraw7cvAmSsXWxlt6sHiD11MvvBwyNNA X-Gm-Gg: AfdE7ckX5Pc005a2FQ2iVyYDfZ6A1KWwN2JVVXtHQDJf3gqdvycFv7lSyeMVlsd2w32 yKh0gZlS9A+0TUxDxzbMst5snx8pgeLwqzLfMabLpJtFtyyjubkdT9JjMIgNjhX5vp9g8b7TiWI 9NqQbZE9x6qXrStn9EPqCr0/Y7TK+geDYLdfHFwIKXxa+xBdXczEkGRFPteEoRtSxu+TDxGtU8z tNa363NUcAWeIH2QQk54GkWZzr+qYBQr8HGixQNaABM+/T6MC4XFagvyfSouqTkhupk++oU9Icg NhqJTSHMJkY7kpjmYvijqwy10SyB/uN5K75wu2RneisPBDuF46SUsncM/oFJrGsGq6GXpMB6XDZ b12y3i2RpY0ZgmOE24bbDF0kdMf2SHc7BE1/FfVXSUiMUyFPtIXY463Ou8bJv1KyW9XeZf8ApQ6 cRiY+k4Up6eqkFM/DNMxAv2aIiyXxFYitZtQ== X-Received: by 2002:a05:6a00:4612:b0:848:2f6e:e52e with SMTP id d2e1a72fcca58-84a5587a0a1mr6247775b3a.66.1784118663610; Wed, 15 Jul 2026 05:31:03 -0700 (PDT) Received: from [10.125.192.114] ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84a4f7dade0sm3092157b3a.46.2026.07.15.05.30.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2026 05:31:03 -0700 (PDT) Message-ID: <7a1fe347-7ca6-4768-9308-420bf1251f54@gmail.com> Date: Wed, 15 Jul 2026 20:30:43 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH 1/2] mm/zswap: Fix global shrinker when memory cgroup is disabled To: Andrew Morton , Yosry Ahmed , nphamcs@gmail.com Cc: tj@kernel.org, hannes@cmpxchg.org, shakeel.butt@linux.dev, mhocko@kernel.org, mkoutny@suse.com, chengming.zhou@linux.dev, muchun.song@linux.dev, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Hao Jia , stable@vger.kernel.org References: <20260714081510.16895-1-jiahao.kernel@gmail.com> <20260714081510.16895-2-jiahao.kernel@gmail.com> <20260714193129.f81711f516504b659d544741@linux-foundation.org> From: Hao Jia In-Reply-To: <20260714193129.f81711f516504b659d544741@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/7/15 10:31, Andrew Morton wrote: > On Tue, 14 Jul 2026 09:52:59 -0700 Yosry Ahmed wrote: > >>> When memory cgroup is disabled, mem_cgroup_iter() always returns NULL. >>> Therefore, the global shrinker shrink_worker() always takes the !memcg >>> branch. After MAX_RECLAIM_RETRIES empty walks, the worker simply gives up, >>> so it fails to write back anything. >>> >>> Therefore, when memory cgroup is disabled, fall through with the !memcg >>> branch and shrink the root memcg directly. >>> >>> With memcg disabled, shrink_memcg() only returns -ENOENT when the root >>> LRU is empty, which means the total pages are already below thr. The >>> loop then safely bails out via the zswap_total_pages() <= thr check. >>> For any other return value from shrink_memcg(), the loop is guaranteed >>> to terminate, either after MAX_RECLAIM_RETRIES failures or once the >>> threshold is met. >>> >>> Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware") >>> Cc: stable@vger.kernel.org >>> Suggested-by: Nhat Pham >>> Acked-by: Nhat Pham >>> Acked-by: Yosry Ahmed >>> Reported-by: Yosry Ahmed >>> Closes: https://lore.kernel.org/all/CAO9r8zPVzMKFbCixxD-qgtRrkFxWVrHiZZeLc=eyTPKPVQgX4g@mail.gmail.com >>> Signed-off-by: Hao Jia >> >> Patch 2 doesn't really depend on this one, right? >> >> If that's the case I think this can (and should be) picked up >> separately as a hotfix. Andrew, WDYT? > > Please update the changelog to clearly describe the userspace-visible > effects of the bug, thanks. I am not entirely sure if my understanding is correct here, but maybe I should add something like this to the commit message? When cgroup_disable=memory is used (or with CONFIG_MEMCG=n), the global shrinker fails to write back any pages. Consequently, the zswap pool fills up to its limit and rejects further storage, preventing memory pressure from being offloaded to the backing swap device. > Also, AI review has flagged several possible issues, all appear to be > serious: > https://sashiko.dev/#/patchset/20260714081510.16895-1-jiahao.kernel@gmail.com For AI review comments on this patch: I suspect this scenario might only exist in theory. For zswap LRU to be empty while zswap_total_pages() > thr holds true, it would require a prolonged state where there are always more than thr zswap entries on the zswap LRU whenever zswap_total_pages() > thr is evaluated, yet the zswap LRU happens to be empty during shrink_memcg(root_memcg). If we want to fix this, perhaps we could do something like this? Yosry, Nhat, what are your thoughts on this? diff --git a/mm/zswap.c b/mm/zswap.c index b5a17ea20237..ca71b517a58d 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1356,11 +1356,12 @@ static void shrink_worker(struct work_struct *w) } while (memcg && !mem_cgroup_tryget_online(memcg)); spin_unlock(&zswap_shrink_lock); - if (!memcg) { - /* - * Continue shrinking without incrementing failures if - * we found candidate memcgs in the last tree walk. - */ + /* + * A NULL memcg ends a full hierarchy pass (except when memcg is + * disabled, where it is always NULL: fall through to the root LRU). + * Count a failure only if the last pass found no candidates. + */ + if (!memcg && !mem_cgroup_disabled()) { if (!attempts && ++failures == MAX_RECLAIM_RETRIES) break; @@ -1378,8 +1379,15 @@ static void shrink_worker(struct work_struct *w) * with pages in zswap. Skip this without incrementing attempts * and failures. */ - if (ret == -ENOENT) + if (ret == -ENOENT) { + /* + * With memcg disabled the root LRU is the only target, so + * we should abort if it has no writeback-candidate pages. + */ + if (mem_cgroup_disabled()) + break; continue; + } ++attempts; if (ret && ++failures == MAX_RECLAIM_RETRIES) Thanks, Hao