From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 B294826ED59 for ; Fri, 27 Feb 2026 07:46:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772178383; cv=none; b=jBVP88Xqeje5gvm47WVCiNMSiEUbSgpGQGm+mrV45ueJLYyvvOP9yEZRizomSxnCkQJwzOzbl7LNrT+Eu7loD3QSwTL2x2Kz/HlVLF7S3RoHxEqPs928EtqHx6n0ymkmTIayoyVmjdM9oe70QiFaGp44tIVeOOwCbLY5N46opn8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772178383; c=relaxed/simple; bh=Bx+B5gjKJI/vlC7buqYj0K8xUC8oHqthHvN3Xe1DHxM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ftNUrpEetCGGx9prXD2Q3R7+jXUnP3x6vCiLMbk1Qu3GDr01Io+6nqRFquAjfjBLRbubXgHqZEJVoHSb8WMvaEad6yZeTij/Ta8h91RORdH87/mkoGDdGnkkXjWaXo1R+rxu0tzOMz8tnAZLIhKpWRRzz/J2Qwp/+j6T624GQyY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=fvk6pM9e; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="fvk6pM9e" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-483ad568d68so2729015e9.2 for ; Thu, 26 Feb 2026 23:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772178380; x=1772783180; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=aPz8QjAwZvhtyd1YXSG1O5BxKJR3PUgfbJT3DkGnKNY=; b=fvk6pM9e2MRJDqOB1thCS9SZqnXo2PSsXaLS9IFIGgc7HaIz/8P/F5mG1bK6NGYS9O pemHaISBjWPzJEqZVLwdTAs6nVJQODBOlAerix9A6whuYRgSWaKwCG+pGhuIk55nult9 DomU2y74/p2G4J1AFVsYb56NAQ3sQsn1RZ2h19J+vEHYMuripbOjygs0ixXmG6ZNuDmm ouKS4BvrPUD2Q2p67vJz0SdgSpIV94CevUy9wOz/OH31RSkAP3fgh6EDj0J6aNRTHguV oTa/5w9fJcPbkjrUMoEi60jgbH+ljovDkNzO2qIgihrE526su9wJ0aR38DB+0ai5DW1r xntg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772178380; x=1772783180; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aPz8QjAwZvhtyd1YXSG1O5BxKJR3PUgfbJT3DkGnKNY=; b=TnC7b035dZHgV1OmrrHPDAnXjGO2PNjfoGJhHcsJ+B51nzEx+KNc8pUaGl600FYZGQ 2z19IABDLibVY6Qt2vzMjy7ZhVyAnP2B212Oz5SWy6eeyMUc1h20AOCh1J5UNMi1Q0f8 9Ux2vL2dIWLVfXUDNbvXCUU6ZYTFe93fPH4aQYhHlUTS+M4pQeTpKZxn9eZTNiXeXXVZ SrLb4U9wzMKKgPBfnltR0xiHoKVZgacqrbgEY+Aq8hV5JBu/EOpYgfm0578Tjyn56v2X PCwVncqb3hg5SCbwJr0avx+wKqefl4F/ftVDCSRVYjLRBZFK44ytXseEs0hS2cAaeI4s sEEg== X-Forwarded-Encrypted: i=1; AJvYcCXLpJL6yawt3k106sr0FLzhr12D3wnA8ggu94pY/VxhAtlj9403biUj4llH0v3ySyMUpYx236N7w8grhEY=@vger.kernel.org X-Gm-Message-State: AOJu0Yy+tz5DouK5DqlP0/cT29jCGTDBfPvN0LzgWpGL/x0Dukoq/yBN LjpDnVBkfCLR+y+ZfX1ulkPsmEZ0kW19ON8O8Hr9SzEVpnsERsT5L61ACWGWko79bC8V48XVI5v BJFCB2ClRfw== X-Gm-Gg: ATEYQzylVhAyow/4pzTtEOsUQeMkM+KzbSWJY/FnaIQh1XqZ2HbEEpBIpN4LnY2MH33 g30f098aVggX/7+JSwJEkrgwUoXB0FT1Iev1pSfmH7ccHcgSS4Lz0+pMjKRu0eczeFd+GjZqwxm xjZV9fCEFA2vSwqv/acTs760I3+/WvVLrJs7VWx//tCYKdnD5VweOvJu3CgAcKQampnCd+mLcdW ykp9f959HMhMSQsuqMtru8+ua2LS+4WAx7UMPdYpViR7tnaKPpQClMLQeaMp7O33uucdV9jBuEg seG8PVU06Y/H34ZgAFLizd4G3u7RVLhoJ88UobpRxrJM6XBw6Py+WYYEMTalJebwh4lToRfTwE6 5sWWANrsTNZRI+BrJ6DJGFDC3L6X6pYwnDJOxg/BAHemCa0SfY+KCIfaU4ZXok3q6KTAHsd10Qs +yUNIzPMyl9ydlb6v01P70Fm25am29NuC2G/8oCdLepDHO9/4q5xJUOBUSSw== X-Received: by 2002:a05:600c:4592:b0:46f:ab96:58e9 with SMTP id 5b1f17b1804b1-483c9b7fadcmr14391835e9.0.1772178380074; Thu, 26 Feb 2026 23:46:20 -0800 (PST) Received: from ?IPV6:2001:1a48:8:903:1ed6:4f73:ce38:f9d4? ([2001:1a48:8:903:1ed6:4f73:ce38:f9d4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483bffc17dasm97998005e9.2.2026.02.26.23.46.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Feb 2026 23:46:19 -0800 (PST) Message-ID: <25f6a18c-0600-4a21-977e-19b8b4b203b2@suse.com> Date: Fri, 27 Feb 2026 08:46:18 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] memcg: fix slab accounting in refill_obj_stock() trylock path Content-Language: en-US To: Hao Li Cc: Shakeel Butt , hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, vbabka@suse.cz, harry.yoo@oracle.com, muchun.song@linux.dev, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260226115145.62903-1-hao.li@linux.dev> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/27/26 02:01, Hao Li wrote: > On Thu, Feb 26, 2026 at 02:44:02PM +0100, Vlastimil Babka wrote: >> On 2/26/26 14:39, Shakeel Butt wrote: >> > On Thu, Feb 26, 2026 at 07:51:37PM +0800, Hao Li wrote: >> >> In the trylock path of refill_obj_stock(), mod_objcg_mlstate() should >> >> use the real alloc/free bytes (i.e., nr_acct) for accounting, rather >> >> than nr_bytes. >> >> >> >> Fixes: 200577f69f29 ("memcg: objcg stock trylock without irq disabling") >> >> Cc: stable@vger.kernel.org >> >> Signed-off-by: Hao Li >> > >> > Thanks for the fix. >> > >> > Acked-by: Shakeel Butt >> >> What are the user-visible effects of the bug? > > The user-visible impact is that the NR_SLAB_RECLAIMABLE_B and > NR_SLAB_UNRECLAIMABLE_B stats can end up being incorrect. > > For example, if a user allocates a 6144-byte object, then before this fix > refill_obj_stock() calls mod_objcg_mlstate(..., nr_bytes=2048), even though it > should account for 6144 bytes (i.e., nr_acct). > > When the user later frees the same object with kfree(), refill_obj_stock() calls > mod_objcg_mlstate(..., nr_bytes=6144). This ends up adding 6144 to the stats, > but it should be applying -6144 (i.e., nr_acct) since the object is being > freed. Thanks, I'm sure Andrew will amend the changelog with those useful details. Weird that we went since 6.16 with nobody noticing the stats were off - it sounds they could get really way off?