public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
	changfengnan@bytedance.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] buffer: fix kmemleak false positive in submit_bh_wbc
Date: Wed, 25 Feb 2026 08:25:37 -0500	[thread overview]
Message-ID: <aZ74UbGA261L4mxQ@laps> (raw)
In-Reply-To: <825ab511-9335-4827-a3fd-6dd6f498326e@kernel.dk>

On Tue, Feb 24, 2026 at 02:57:35PM -0700, Jens Axboe wrote:
>On 2/24/26 12:06 PM, Sasha Levin wrote:
>> Bios allocated in submit_bh_wbc are properly freed via their end_io
>> handler. Since commit 48f22f80938d, bio_put() caches them in a per-CPU
>> bio cache for reuse rather than freeing them back to the mempool.
>> While cached bios are reachable by kmemleak via the per-CPU cache
>> pointers, once recycled for new I/O they are only referenced by block
>> layer internals that kmemleak does not scan, causing false positive
>> leak reports.
>>
>> Mark the bio allocation with kmemleak_not_leak() to suppress the false
>> positive.
>>
>> Fixes: 48f22f80938d ("block: enable per-cpu bio cache by default")
>> Assisted-by: Claude:claude-opus-4-6
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>>  fs/buffer.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/buffer.c b/fs/buffer.c
>> index 22b43642ba574..c298df6c7f8c6 100644
>> --- a/fs/buffer.c
>> +++ b/fs/buffer.c
>> @@ -49,6 +49,7 @@
>>  #include <linux/sched/mm.h>
>>  #include <trace/events/block.h>
>>  #include <linux/fscrypt.h>
>> +#include <linux/kmemleak.h>
>>  #include <linux/fsverity.h>
>>  #include <linux/sched/isolation.h>
>>
>> @@ -2799,6 +2800,7 @@ static void submit_bh_wbc(blk_opf_t opf, struct buffer_head *bh,
>>  		opf |= REQ_PRIO;
>>
>>  	bio = bio_alloc(bh->b_bdev, 1, opf, GFP_NOIO);
>> +	kmemleak_not_leak(bio);
>>
>>  	fscrypt_set_bio_crypt_ctx_bh(bio, bh, GFP_NOIO);
>
>What if they do end up getting leaked? This seems like an odd

I was under the impression that kmemleak doesn't really track much under the
hood of the block layer to begin with, but looking at the code I'm probably
wrong.

>work-around, would be better to ensure the caching side marks them as
>in-use when grabbed and freed when put.

Something like:?

diff --git a/block/bio.c b/block/bio.c
index d80d5d26804e3..45a19de02eca6 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -17,6 +17,7 @@
  #include <linux/cgroup.h>
  #include <linux/highmem.h>
  #include <linux/blk-crypto.h>
+#include <linux/kmemleak.h>
  #include <linux/xarray.h>
  
  #include <trace/events/block.h>
@@ -504,6 +505,9 @@ static struct bio *bio_alloc_percpu_cache(struct block_device *bdev,
         cache->nr--;
         put_cpu();
  
+       kmemleak_alloc((void *)bio - bs->front_pad,
+                      kmem_cache_size(bs->bio_slab), 1, gfp);
+
         if (nr_vecs)
                 bio_init_inline(bio, bdev, nr_vecs, opf);
         else
@@ -765,6 +769,9 @@ static int __bio_alloc_cache_prune(struct bio_alloc_cache *cache,
         while ((bio = cache->free_list) != NULL) {
                 cache->free_list = bio->bi_next;
                 cache->nr--;
+               kmemleak_alloc((void *)bio - bio->bi_pool->front_pad,
+                              kmem_cache_size(bio->bi_pool->bio_slab),
+                              1, GFP_NOWAIT);
                 bio_free(bio);
                 if (++i == nr)
                         break;
@@ -823,6 +830,7 @@ static inline void bio_put_percpu_cache(struct bio *bio)
  
         if (in_task()) {
                 bio_uninit(bio);
+               kmemleak_free((void *)bio - bio->bi_pool->front_pad);
                 bio->bi_next = cache->free_list;
                 /* Not necessary but helps not to iopoll already freed bios */
                 bio->bi_bdev = NULL;
@@ -832,6 +840,7 @@ static inline void bio_put_percpu_cache(struct bio *bio)
                 lockdep_assert_irqs_disabled();
  
                 bio_uninit(bio);
+               kmemleak_free((void *)bio - bio->bi_pool->front_pad);
                 bio->bi_next = cache->free_list_irq;
                 cache->free_list_irq = bio;
                 cache->nr_irq++;

-- 
Thanks,
Sasha

      reply	other threads:[~2026-02-25 13:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24 19:06 [PATCH] buffer: fix kmemleak false positive in submit_bh_wbc Sasha Levin
2026-02-24 21:57 ` Jens Axboe
2026-02-25 13:25   ` Sasha Levin [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=aZ74UbGA261L4mxQ@laps \
    --to=sashal@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=changfengnan@bytedance.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox