All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Hao Li <hao.li@linux.dev>, Hao Ge <hao.ge@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <cl@gentwo.org>,
	David Rientjes <rientjes@google.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/slab: Add alloc_tagging_slab_free_hook for memcg_alloc_abort_single
Date: Thu, 5 Feb 2026 14:17:48 +0900	[thread overview]
Message-ID: <aYQn_Mv93Pi2gnIu@hyeyoo> (raw)
In-Reply-To: <51489c81-1adb-4582-8564-7c97b6a1060f@suse.cz>

On Wed, Feb 04, 2026 at 05:28:34PM +0100, Vlastimil Babka wrote:
> On 2/4/26 13:00, Hao Li wrote:
> > On Wed, Feb 04, 2026 at 06:14:01PM +0800, Hao Ge wrote:
> >> When CONFIG_MEM_ALLOC_PROFILING_DEBUG is enabled, the following warning
> >> may be noticed:
> >> 
> >> [ 3959.023862] ------------[ cut here ]------------
> >> [ 3959.023891] alloc_tag was not cleared (got tag for lib/xarray.c:378)
> >> [ 3959.023947] WARNING: ./include/linux/alloc_tag.h:155 at alloc_tag_add+0x128/0x178, CPU#6: mkfs.ntfs/113998
> >> [ 3959.023978] Modules linked in: dns_resolver tun brd overlay exfat btrfs blake2b libblake2b xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel ext4 crc16 mbcache jbd2 rfkill sunrpc vfat fat sg fuse nfnetlink sr_mod virtio_gpu cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper ghash_ce drm sm4 backlight virtio_net net_failover virtio_scsi failover virtio_console virtio_blk virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod i2c_dev aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject]
> >> [ 3959.024170] CPU: 6 UID: 0 PID: 113998 Comm: mkfs.ntfs Kdump: loaded Tainted: G        W           6.19.0-rc7+ #7 PREEMPT(voluntary)
> >> [ 3959.024182] Tainted: [W]=WARN
> >> [ 3959.024186] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022
> >> [ 3959.024192] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> >> [ 3959.024199] pc : alloc_tag_add+0x128/0x178
> >> [ 3959.024207] lr : alloc_tag_add+0x128/0x178
> >> [ 3959.024214] sp : ffff80008b696d60
> >> [ 3959.024219] x29: ffff80008b696d60 x28: 0000000000000000 x27: 0000000000000240
> >> [ 3959.024232] x26: 0000000000000000 x25: 0000000000000240 x24: ffff800085d17860
> >> [ 3959.024245] x23: 0000000000402800 x22: ffff0000c0012dc0 x21: 00000000000002d0
> >> [ 3959.024257] x20: ffff0000e6ef3318 x19: ffff800085ae0410 x18: 0000000000000000
> >> [ 3959.024269] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> >> [ 3959.024281] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600064101293
> >> [ 3959.024292] x11: 1fffe00064101292 x10: ffff600064101292 x9 : dfff800000000000
> >> [ 3959.024305] x8 : 00009fff9befed6e x7 : ffff000320809493 x6 : 0000000000000001
> >> [ 3959.024316] x5 : ffff000320809490 x4 : ffff600064101293 x3 : ffff800080691838
> >> [ 3959.024328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000d5bcd640
> >> [ 3959.024340] Call trace:
> >> [ 3959.024346]  alloc_tag_add+0x128/0x178 (P)
> >> [ 3959.024355]  __alloc_tagging_slab_alloc_hook+0x11c/0x1a8
> >> [ 3959.024362]  kmem_cache_alloc_lru_noprof+0x1b8/0x5e8
> >> [ 3959.024369]  xas_alloc+0x304/0x4f0
> >> [ 3959.024381]  xas_create+0x1e0/0x4a0
> >> [ 3959.024388]  xas_store+0x68/0xda8
> >> [ 3959.024395]  __filemap_add_folio+0x5b0/0xbd8
> >> [ 3959.024409]  filemap_add_folio+0x16c/0x7e0
> >> [ 3959.024416]  __filemap_get_folio_mpol+0x2dc/0x9e8
> >> [ 3959.024424]  iomap_get_folio+0xfc/0x180
> >> [ 3959.024435]  __iomap_get_folio+0x2f8/0x4b8
> >> [ 3959.024441]  iomap_write_begin+0x198/0xc18
> >> [ 3959.024448]  iomap_write_iter+0x2ec/0x8f8
> >> [ 3959.024454]  iomap_file_buffered_write+0x19c/0x290
> >> [ 3959.024461]  blkdev_write_iter+0x38c/0x978
> >> [ 3959.024470]  vfs_write+0x4d4/0x928
> >> [ 3959.024482]  ksys_write+0xfc/0x1f8
> >> [ 3959.024489]  __arm64_sys_write+0x74/0xb0
> >> [ 3959.024496]  invoke_syscall+0xd4/0x258
> >> [ 3959.024507]  el0_svc_common.constprop.0+0xb4/0x240
> >> [ 3959.024514]  do_el0_svc+0x48/0x68
> >> [ 3959.024520]  el0_svc+0x40/0xf8
> >> [ 3959.024526]  el0t_64_sync_handler+0xa0/0xe8
> >> [ 3959.024533]  el0t_64_sync+0x1ac/0x1b0
> >> [ 3959.024540] ---[ end trace 0000000000000000 ]---
> >> 
> >> When __memcg_slab_post_alloc_hook() fails, there are two different
> >> free paths depending on whether size == 1 or size != 1. In the
> >> kmem_cache_free_bulk() path, we do call alloc_tagging_slab_free_hook().
> >> However, in memcg_alloc_abort_single() we don't, the above warning will be
> >> triggered on the next allocation.
> >> 
> >> Therefore, add alloc_tagging_slab_free_hook() to the
> >> memcg_alloc_abort_single() path.
> >> 
> >> Fixes: 9f9796b413d3 ("mm, slab: move memcg charging to post-alloc hook")
> >> Suggested-by: Hao Li <hao.li@linux.dev>
> >> Signed-off-by: Hao Ge <hao.ge@linux.dev>
> >> ---

Woohoo, nice catch!

> >> v2: Hao Li correctly pointed out the root cause of this problem.
> >>     Per his suggestion, this patch adds the missing hook call.
> >>     Many thanks to him for the thorough analysis.
> >> ---
> >>  mm/slub.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >> 
> >> diff --git a/mm/slub.c b/mm/slub.c
> >> index f77b7407c51b..452a92544c6a 100644
> >> --- a/mm/slub.c
> >> +++ b/mm/slub.c
> >> @@ -6689,6 +6689,8 @@ void slab_free(struct kmem_cache *s, struct slab *slab, void *object,
> >>  static noinline
> >>  void memcg_alloc_abort_single(struct kmem_cache *s, void *object)
> >>  {
> >> +	alloc_tagging_slab_free_hook(s, virt_to_slab(object), &object, 1);
> > 
> > LGTM.
> > 
> > Minor nit: It would be cleaner to store the result of `virt_to_slab(object)` in a local
> > variable and reuse it in the code that follows.
> 
> Did that locally, also added Cc: stable
> 
> > If you end up sending a v3, feel free to add:
> > Reviewed-by: Hao Li <hao.li@linux.dev>
> 
> Pushed to slab/for-next-fixes, thanks!

Reviewed-by: Harry Yoo <harry.yoo@oracle.com>

-- 
Cheers,
Harry / Hyeonggon


      parent reply	other threads:[~2026-02-05  5:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-04 10:14 [PATCH v2] mm/slab: Add alloc_tagging_slab_free_hook for memcg_alloc_abort_single Hao Ge
2026-02-04 12:00 ` Hao Li
2026-02-04 16:28   ` Vlastimil Babka
2026-02-04 16:35     ` Suren Baghdasaryan
2026-02-05  5:17     ` Harry Yoo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aYQn_Mv93Pi2gnIu@hyeyoo \
    --to=harry.yoo@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=hao.ge@linux.dev \
    --cc=hao.li@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.