All of lore.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 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.