From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794048294; b=l2o7GxaLlYkrznq7fn9hUuin+RBmQDh3rxqvufU7TJEn2Q2/WwsQFoknPK0RmAqjUx7R HnYFd2jHYTaajPykTiORwpL23/km9KzzpHcGFi+RXDdDV2N2Tt7f3LdLtIsokl28fO/S1 QkDIoJI81gOZMaorELwd1uvvsPyK0bJjyGiEGcxQa6NWzNqBvC6Wij3fipt/OCwVtw/x6 yyYUakCH7rtMTVp0nw1W6Sh1nFSYSIYtMF/YME3W5/M3BLvjlFIN9oT8web2NKt5CmFig A4P+17BqnUv6O7G7humtjaYiBGKFQ967Qgeppkex6tix6c80g7XUKSUbnCn2HR7esew== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794048294; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=hsbphYaEzBguM4xYfXaAAkL+oqgv8dEwRROWLFXt+Ec=; b=bPN1BDV3SfahUngDfY9bPK9IJ1Vv1xBLb3lawtwfdWoo+v0w3eQJC5LnV6JjBxS3b6h0 hVpxaZocZ9umlUNTD27tif1+crXYCKK/TI7iqmVi8ZHVJkJLTSLXDqwzdvO9v/RtyhmE5 iuArnQb9LfWcg9gMkKiliuSqQeWLatUmgWO8EHAvklH+6Aum8lfjk6rZmXgGuosFN+mTx u+c4rzMAVC0fNi0SDYv/FyyC+knHtctaDRuPasEx13Pkir2tQhaTTc7dyTq7phD+h4iL0 lDiNEhomJNGWlBn+GxFPz4Hb1jszZJAIRzWpFq/y6Jz/VkfwJNiUoqafmwriCn2aimw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=InRAjZY9; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29803606A326 for ; Sat, 7 Nov 2026 10:44:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=InRAjZY9 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 366521F0089F; Sat, 7 Nov 2026 10:44:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794048294; bh=hsbphYaEzBguM4xYfXaAAkL+oqgv8dEwRROWLFXt+Ec=; h=From:To:Cc:Subject:Date; b=InRAjZY9dYGGbu5T9Px6dhuF/TcyjqGdhcihCW9HrKhj/mDWiXCQtDBi0OzUcfVGS jvuBPGAGvVBzvDODrCa6LXE0TEWv0HReWqlwviaSsNrz+FvPz/E2UQ53MGcLPTWeXR cSHAa5i/wvE7PzZE68+ATFgKdkc5i9ra4dXMcw2RAFbK+wVmcRTkLTzBFpuJNBThJj yRqhGYmdBq9vzTahEaLupifmU7Yv5xibf/h6BwgO+xmP4pwuP1BePnN49wfn7rxRCU 49KqMRioGtKEt/7ew8cNLS7cPKlUlPXcA4ydDi3UzN+eBHDxhFA6vqoO/MiYlFmK/b 8WxQTsOrIEbgQ== From: Sasha Levin To: joe@dama.to, akpm@linux-foundation.org, shakeel.butt@linux.dev, hannes@cmpxchg.org, mhocko@kernel.org, muchun.song@linux.dev, roman.gushchin@linux.dev Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] mm: memcontrol: raise MEMCG_MAX for charges that fail without reclaiming" failed to apply to 6.1-stable tree Date: Sat, 7 Nov 2026 05:44:51 -0500 Message-ID: <20261107054451-failed-6.1-374f65b14819@kernel.org> X-Mailer: git-send-email 2.53.0 X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 374f65b1481992eb6b9c6bffd53f3afa5c2e94cf # git commit -s git send-email --to '' --in-reply-to '20261107054451-failed-6.1-374f65b14819@kernel.org' --subject-prefix 'PATCH 6.1.y' 'HEAD^..' Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From 374f65b1481992eb6b9c6bffd53f3afa5c2e94cf Mon Sep 17 00:00:00 2001 From: Joe Damato Date: Mon, 31 Aug 2026 10:48:35 -0700 Subject: [PATCH] mm: memcontrol: raise MEMCG_MAX for charges that fail without reclaiming Charges that exceed memory.max and return through the nomem label can raise no event and simply return -ENOMEM. A non-blocking charge can hit the limit, get rejected, but is not visible in memory.events. This was noticed in a production setting where bpf_mem_alloc() attempted to refill its per-cpu freelists, which triggered a non-blocking charge while at the limit. Commit d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations") added raised_max_event to cover charges that are force charged without ever reaching reclaim, but charges that are rejected outright were left out. Getting an allocation failure without the corresponding MEMCG_MAX event is unexpected and makes debugging and monitoring harder. Raise the event on the way out for rejected charges as well, by routing the -ENOMEM return through the same exit path that already covers forced charges. The existing behavior of raising a MEMCG_MAX event on every charge/reclaim/retry iteration is left unchanged. Tested with a module that performs accounted GFP_NOWAIT page allocations from a task in a cgroup at its memory.max, and measures the resulting memory.events:max delta. Without this patch the rejected charges raise no event at all; with it the delta matches the number of rejected charges exactly. A GFP_KERNEL|__GFP_NORETRY control, which reaches reclaim, raises the same two events per failed charge before and after, confirming the existing charge/reclaim/retry accounting is unchanged. Link: https://lore.kernel.org/20260831174836.3102406-1-joe@dama.to Fixes: d6e103a757fa ("mm: memcontrol: do not miss MEMCG_MAX events for enforced allocations") Signed-off-by: Joe Damato Signed-off-by: Andrew Morton Suggested-by: Shakeel Butt Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: --- mm/memcontrol.c | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index d5ebe83eae3ef..aeaa09e01d70e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2685,10 +2685,11 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, bool raised_max_event = false; unsigned long pflags; bool allow_spinning = gfpflags_allow_spinning(gfp_mask); + int ret = 0; retry: if (consume_stock(memcg, nr_pages)) - return 0; + return ret; if (!allow_spinning) /* Avoid the refill and flush of the older stock */ @@ -2799,16 +2800,11 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, * put the burden of reclaim on regular allocation requests * and let these go through as privileged allocations. */ - if (!(gfp_mask & (__GFP_NOFAIL | __GFP_HIGH))) - return -ENOMEM; + if (!(gfp_mask & (__GFP_NOFAIL | __GFP_HIGH))) { + ret = -ENOMEM; + goto out; + } force: - /* - * If the allocation has to be enforced, don't forget to raise - * a MEMCG_MAX event. - */ - if (!raised_max_event) - __memcg_memory_event(mem_over_limit, MEMCG_MAX, allow_spinning); - /* * The allocation either can't fail or will lead to more memory * being freed very soon. Allow memory usage go over the limit @@ -2818,7 +2814,15 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, if (do_memsw_account()) page_counter_charge(&memcg->memsw, nr_pages); - return 0; +out: + /* + * Don't forget to raise a MEMCG_MAX event for forced or rejected + * requests. + */ + if (!raised_max_event) + __memcg_memory_event(mem_over_limit, MEMCG_MAX, allow_spinning); + + return ret; done_restock: if (batch > nr_pages) @@ -2877,7 +2881,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, !(current->flags & PF_MEMALLOC) && gfpflags_allow_blocking(gfp_mask)) __mem_cgroup_handle_over_high(gfp_mask); - return 0; + return ret; } static inline int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, -- 2.53.0