Linux EXT4 FS development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: Alan <3164729207@qq.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH v2] ext4: free the new extent block on failure to grow the tree
Date: Wed, 11 Nov 2026 07:51:01 +0000	[thread overview]
Message-ID: <sashiko-outbox-208546@kernel.org> (raw)
In-Reply-To: <tencent_DF25FDEF46DA68C4E18D6DB40F08E30BB705@qq.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] ext4: single-word name in Author and Signed-off-by trailer
--

commit 28c8d79985e366b191e9eac1f2d5415854ca0289
Author: Alan <3164729207@qq.com>

> ext4: free the new extent block on failure to grow the tree
>
> ext4_ext_grow_indepth() allocates and accounts a metadata block before
> getting its buffer, obtaining journal create access and dirtying the
> new extent block. If any of these operations fails, the new block has
> not been linked into the extent tree. However, the error paths return
> without freeing it, leaking the block and leaving i_blocks larger
> than the number of blocks reachable from the inode.
>
> Commit 8a83ac54940d ("ext4: call bdev_getblk() from sb_getblk_gfp()")
> removed the implicit __GFP_NOFAIL from the buffer allocation, making
> the allocation failure path reachable. The two journal error paths
> already lacked cleanup before that commit and are fixed here as well.
>
> Route all three failures through a common cleanup label to free the
> unpublished metadata block and undo its inode accounting. Keep the
> existing buffer unlock and release handling. Once the new block has
> been linked by ext4_idx_store_pblock(), an ext4_mark_inode_dirty()
> failure must not free it because the extent tree already references it.
>
> Tested on Linux 6.12.1 by injecting NULL for buffer acquisition and
> -EIO for each of the two metadata helper calls at their caller
> boundaries. Each unfixed case leaves seven unreachable blocks and
> i_blocks of 40 instead of 32 on a filesystem with 4 KiB blocks. With
> the fix, all three cases retain i_blocks of 32, preserve the original
> data and pass e2fsck -fn after a normal unmount. Retry, truncate and
> uninjected growth also pass for each case.
>
> Fixes: 8a83ac54940d ("ext4: call bdev_getblk() from sb_getblk_gfp()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alan <3164729207@qq.com>

[Severity: High]
Documentation/process/submitting-patches.rst requires a full real name in
the Author header and Signed-off-by trailer to satisfy the Developer's
Certificate of Origin, rather than a single-word name or handle ("Alan").

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_DF25FDEF46DA68C4E18D6DB40F08E30BB705@qq.com?part=1

  reply	other threads:[~2026-11-11  7:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  7:27 [PATCH] ext4: free the new extent block when getting its buffer fails Alan
2026-11-10  7:51 ` sashiko-bot
2026-11-10 12:31 ` Jan Kara
2026-11-11  7:34 ` [PATCH v2] ext4: free the new extent block on failure to grow the tree Alan
2026-11-11  7:51   ` sashiko-bot [this message]
2026-11-11 11:11   ` Jan Kara

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=sashiko-outbox-208546@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=3164729207@qq.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tytso@mit.edu \
    /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