From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36A441EB9E1 for ; Wed, 7 Jan 2026 16:13:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767802433; cv=none; b=B+vHk11e/XmgpocwAqkXcMDJ4oB0FnPaimPTCoF5aLuaCTo/d0EXAKbZbtf1QNNdVWQysx37ec0M96JhMog6SHK11mXfDz5Xo7SpPgOVDvJneYBKdr1B6RsUs5mnwGSuZva4buk6NbwaLBR6RKMWTyEfh79TgIOErvcSQa0Ud2M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767802433; c=relaxed/simple; bh=fRqYo11JBdve3W4eeTgCq44i1S19cYFl7kPZLt3GQ5w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KcmJ7nK7vEvteYOKe1dRVByH0cMwQ267YK4lP16UNWPU4oocQ1O0tS1GLpwmbErQb20zG6wbFy+olfYJ0mwNr4NZuJgGl+HX5CP9sWb3ItKC3P/4xTBmaDD6kkLJ7yHLDLuo4MNYnOFWozcpp7CAX5qyVFK829/Py5xCbke7SDU= 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=chFS53lF; arc=none smtp.client-ip=95.215.58.176 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="chFS53lF" Date: Wed, 7 Jan 2026 11:13:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1767802410; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fPQWIADjQC4TwHC8EiEiCB9H2oAaqtO+F3440ryzkow=; b=chFS53lFvbAgqR/F2l0q9UIIt5jKIUa8bUnrVWOreRvouZxaQlayxNBmeNT8oJ2QJFNftd Igbho/vMjGiYhwOWnd+IP23I2HreqRABjgaLhfODP+Gs3TfpAyDkksSxE2l0DlQlWufVpR zHC9GRuKYT9b9iXvSzgcPp3kdn/xJEE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: David Wang <00107082@163.com> Cc: Suren Baghdasaryan , akpm@linux-foundation.org, hannes@cmpxchg.org, pasha.tatashin@soleen.com, souravpanda@google.com, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] alloc_tag: add option to pick the first codetag along callchain Message-ID: References: <20251216064349.74501-1-00107082@163.com> <75285cc4.3c52.19b916d9490.Coremail.00107082@163.com> <37169c79.a0e5.19b93a2768f.Coremail.00107082@163.com> <4736b304.38a2.19b96888104.Coremail.00107082@163.com> <5b356cfa.4ab3.19b97196d49.Coremail.00107082@163.com> 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: <5b356cfa.4ab3.19b97196d49.Coremail.00107082@163.com> X-Migadu-Flow: FLOW_OUT On Wed, Jan 07, 2026 at 02:16:24PM +0800, David Wang wrote: > > At 2026-01-07 12:07:34, "Kent Overstreet" wrote: > >I'm curious why you need to change __filemap_get_folio()? In filesystem > >land we just lump that under "pagecache", but I guess you're doing more > >interesting things with it in driver land? > > Oh, in [1], there is a report about possible memory leak in cephfs, (The issue is still open, tracked in [2].), > large trunk of memory could not be released even after dropcache. > memory allocation profiling shows those memory belongs to __filemap_get_folio, > something like > >> ># sort -g /proc/allocinfo|tail|numfmt --to=iec > >> > 12M 2987 mm/execmem.c:41 func:execmem_vmalloc > >> > 12M 3 kernel/dma/pool.c:96 func:atomic_pool_expand > >> > 13M 751 mm/slub.c:3061 func:alloc_slab_page > >> > 16M 8 mm/khugepaged.c:1069 func:alloc_charge_folio > >> > 18M 4355 mm/memory.c:1190 func:folio_prealloc > >> > 24M 6119 mm/memory.c:1192 func:folio_prealloc > >> > 58M 14784 mm/page_ext.c:271 func:alloc_page_ext > >> > 61M 15448 mm/readahead.c:189 func:ractl_alloc_folio > >> > 79M 6726 mm/slub.c:3059 func:alloc_slab_page > >> > 11G 2674488 mm/filemap.c:2012 func:__filemap_get_folio > > After adding codetag to __filemap_get_folio, it shows > > ># sort -g /proc/allocinfo|tail|numfmt --to=iec > > 10M 2541 drivers/block/zram/zram_drv.c:1597 [zram] > >func:zram_meta_alloc 12M 3001 mm/execmem.c:41 func:execmem_vmalloc > > 12M 3605 kernel/fork.c:311 func:alloc_thread_stack_node > > 16M 992 mm/slub.c:3061 func:alloc_slab_page > > 20M 35544 lib/xarray.c:378 func:xas_alloc > > 31M 7704 mm/memory.c:1192 func:folio_prealloc > > 69M 17562 mm/memory.c:1190 func:folio_prealloc > > 104M 8212 mm/slub.c:3059 func:alloc_slab_page > > 124M 30075 mm/readahead.c:189 func:ractl_alloc_folio > > 2.6G 661392 fs/netfs/buffered_read.c:635 [netfs] func:netfs_write_begin > > > > Helpful or not, I am not sure. So far no bug has been spotted in the cephfs write path, yet. > But at least, it provides more information and narrow down the scope of suspicious. > > > https://lore.kernel.org/lkml/2a9ba88e.3aa6.19b0b73dd4e.Coremail.00107082@163.com/ [1] > https://tracker.ceph.com/issues/74156 [2] Well, my first thought when looking at that is that memory allocation profiling is unlikely to be any more help there. Once you're dealing with the page cache, if you're looking at a genuine leak it would pretty much have to be a folio refcount leak, and the code that leaked the ref could be anything that touched that folio - you're looking at a pretty wide scope. Unfortunately, we're not great at visibility and introspection in mm/, and refcount bugs tend to be hard in general. Better mm introspection would be helpful to say definitively that you're looking at a refcount leak, but then once that's determined it's still going to be pretty painful to track down. The approach I took in bcachefs for refcount bugs was to write a small library that in debug mode splits a refcount into sub-refcounts, and then enumerate every single codepath that takes refs and gives them distinct sub-refs - this means in debug mode we can instantly pinpoint the function that's buggy (and even better, with the new CLASS() and guard() stuff these sorts of bugs have been going away). But grafting that onto folio refcounts would be a hell of a chore. OTOH, converting code to CLASS() and guards is much more straightforward - just a matter of writing little helpers if you need them and then a bunch of mechanical conversions, and it's well worth it. But, I'm reading through the Ceph code, and it has /less/ code involving folio refcounts than I would expect. Has anyone checked if the bug reproduces without zswap? I've definitely seen a lot of bug reports involving that code.