Linux RAID subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: yukuai@fygo.io, linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/3] md: Use folio_alloc_buffers()
Date: Mon, 14 Sep 2026 04:27:46 +0000	[thread overview]
Message-ID: <20260914042747.712831F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260914041830.2072626-1-willy@infradead.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Severe memory leak of bitmap pages in free_buffers() when PagePrivate is not set.
--

commit 9822ba9b718b51ce47732b5412e326f063b30c60
Author: Matthew Wilcox (Oracle) <willy@infradead.org>

md: Use folio_alloc_buffers()

This commit removes the last user of alloc_page_buffers(), replacing it
with folio_alloc_buffers() to prevent new callers from existing.

> diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
> index b8325cb09a371..5f1637f974c15 100644
> --- a/drivers/md/md-bitmap.c
> +++ b/drivers/md/md-bitmap.c
> @@ -560,6 +560,7 @@ static int read_file_page(struct file *file, unsigned long index,
>  {
>  	int ret = 0;
>  	struct inode *inode = file_inode(file);
> +	struct folio *folio = page_folio(page);
>  	struct buffer_head *bh;
>  	sector_t block, blk_cur;
>  	unsigned long blocksize = i_blocksize(inode);
> @@ -567,12 +568,12 @@ static int read_file_page(struct file *file, unsigned long index,
>  	pr_debug("read bitmap file (%dB @ %llu)\n", (int)PAGE_SIZE,
>  		 (unsigned long long)index << PAGE_SHIFT);
>  
> -	bh = alloc_page_buffers(page, blocksize);
> +	bh = folio_alloc_buffers(folio, blocksize, GFP_NOFS | __GFP_ACCOUNT);
>  	if (!bh) {
>  		ret = -ENOMEM;
>  		goto out;
>  	}
> -	attach_page_private(page, bh);
> +	folio_attach_private(folio, bh);

[Severity: High]
This isn't a bug introduced by this patch, but it is a severe pre-existing
resource leak in the cleanup path for these pages.

md_bitmap_storage_alloc() allocates pages via alloc_page() for
store->filemap. On teardown, md_bitmap_file_unmap() iterates over these
pages and calls free_buffers() to clean them up.

For internal bitmaps, read_sb_page() uses raw bios and never attaches
buffer heads, so the pages never have the PagePrivate flag set. 
When this happens, free_buffers() returns early:

static void free_buffers(struct page *page)
{
	struct buffer_head *bh;

	if (!PagePrivate(page))
		return;
...
	detach_page_private(page);
	put_page(page);
}

Does this early return mistakenly skip the final put_page() call,
permanently leaking the page when no buffer heads are attached?

This leaks memory pages allocated for the MD bitmap every time an array
with an internal bitmap is stopped, potentially leading to memory
exhaustion.

I verified that the follow-up patches in this series (which migrate this
function to the folio API) faithfully reproduce the exact same leak by
returning early when bh is NULL before calling folio_put(folio).

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com?part=1

  reply	other threads:[~2026-09-14  4:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14  2:23 [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Zi Yan
2026-09-14  2:24 ` [PATCH v4 13/16] md/md-bitmap: replace PagePrivate() with page_private() Zi Yan
2026-09-14  2:24 ` [PATCH v4 14/16] buffer: replace page_buffer() with page_private() and delete it Zi Yan
2026-09-14  3:39 ` [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Andrew Morton
2026-09-15 17:16   ` Zi Yan
2026-09-14  4:18 ` [PATCH 1/3] md: Use folio_alloc_buffers() Matthew Wilcox (Oracle)
2026-09-14  4:27   ` sashiko-bot [this message]
2026-09-14 13:12   ` David Hildenbrand (Arm)
2026-09-14 13:17     ` Matthew Wilcox
2026-09-14 13:20       ` David Hildenbrand (Arm)
2026-09-14 14:36         ` Zi Yan
2026-09-14  4:18 ` [PATCH 2/3] md: Use folio APIs in free_page() Matthew Wilcox (Oracle)
2026-09-14  4:31   ` sashiko-bot
2026-09-14 16:21     ` Matthew Wilcox
2026-09-14 16:25       ` Zi Yan
2026-09-14 13:13   ` David Hildenbrand (Arm)
2026-09-14  4:18 ` [PATCH 3/3] md: Remove the last use of page_buffers() Matthew Wilcox (Oracle)
2026-09-14  4:29   ` sashiko-bot
2026-09-14 13:14   ` David Hildenbrand (Arm)
2026-09-14  4:21 ` [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Matthew Wilcox
2026-09-14 13:10   ` David Hildenbrand (Arm)
2026-09-14 15:30 ` [f2fs-dev] " patchwork-bot+f2fs

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=20260914042747.712831F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=willy@infradead.org \
    --cc=yukuai@fygo.io \
    /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