All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zhang Yi" <yi.zhang@huaweicloud.com>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v7 26/31] ext4: clear DISKSIZE_GROW_PENDING on truncate or error
Date: Fri, 09 Oct 2026 11:16:22 +0000	[thread overview]
Message-ID: <sashiko-outbox-165341@kernel.org> (raw)
In-Reply-To: <20261009103033.2920530-27-yi.zhang@huaweicloud.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] fs: missing DISKSIZE_GROW_PENDING clear during nlink > 0 eviction
--

commit b90813716147a7864ab2f3a3c46c2814d0084c2b
Author: Zhang Yi <yi.zhang@huawei.com>

ext4: clear DISKSIZE_GROW_PENDING on truncate or error

This commit clears the disksize-grow-pending state on various paths where a
zeroed EOF block is discarded before writeback completes. It also adds a
warning in destroy_inode to catch any inodes that missed clearing the state.

> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
[ ... ]
> @@ -266,6 +266,8 @@ void ext4_evict_inode(struct inode *inode)
>  
>  	if (ext4_should_order_data(inode))
>  		ext4_begin_ordered_truncate(inode, 0);
> +	if (ext4_inode_buffered_iomap(inode))
> +		ext4_iomap_clear_disksize_pending(inode);
>  	truncate_inode_pages_final(&inode->i_data);

[Severity: Medium]
When an inode with nlink > 0 is evicted and still has dirty pages (such as
during a forced unmount or after a failed sync_filesystem), ext4_evict_inode()
logs a data loss warning and forcefully truncates the page cache using
truncate_inode_pages_final() before jumping to the no_delete label.

Because the pages are discarded immediately without initiating writeback, the
writeback error path is never invoked, meaning the
EXT4_STATE_DISKSIZE_GROW_PENDING bit is never cleared.

Since the added state clearing logic is placed after the nlink > 0 block, does
this bypass clearing the bit for those inodes entirely?

[ ... ]
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1497,6 +1497,14 @@ static void ext4_destroy_inode(struct inode *inode)
>  			 "Inode %llu (%p): i_reserved_data_blocks (%u) not cleared!",
>  			 inode->i_ino, EXT4_I(inode),
>  			 EXT4_I(inode)->i_reserved_data_blocks);
> +
> +	if (!(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ERROR_FS) &&
> +	    !ext4_emergency_state(inode->i_sb) &&
> +	    WARN_ON_ONCE(ext4_test_inode_state(inode,
> +				EXT4_STATE_DISKSIZE_GROW_PENDING)))

[Severity: Medium]
Can this assertion be reliably triggered when unmounting a filesystem while
writeback is blocked or fails, since the pending bit is not cleared during
nlink > 0 eviction? This might potentially crash systems with panic_on_warn
enabled.

> +		ext4_msg(inode->i_sb, KERN_ERR,
> +			 "Inode %llu (%p): EXT4_STATE_DISKSIZE_GROW_PENDING not cleared!",
> +			 inode->i_ino, EXT4_I(inode));
>  }
>  
>  static void ext4_shutdown(struct super_block *sb)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009103033.2920530-1-yi.zhang@huaweicloud.com?part=26

  reply	other threads:[~2026-10-09 11:16 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 10:30 [PATCH v7 00/31] ext4: use iomap for regular file's buffered I/O path Zhang Yi
2026-10-09 10:30 ` [PATCH v7 01/31] ext4: simplify size updating in ext4_setattr() Zhang Yi
2026-10-09 10:51   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 02/31] ext4: factor out ext4_truncate_[up|down]() Zhang Yi
2026-10-09 10:54   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 03/31] ext4: set EXT4_MAP_NEW flag for delayed allocated blocks Zhang Yi
2026-10-09 10:50   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 04/31] ext4: recheck extent status tree before block allocation Zhang Yi
2026-10-09 10:54   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 05/31] ext4: fix orig_mlen initialization in ext4_map_blocks() Zhang Yi
2026-10-09 10:53   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 06/31] ext4: allow ext4_map_blocks() to start its own transaction handle Zhang Yi
2026-10-09 10:58   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 07/31] ext4: avoid unnecessary transaction in ext4_map_blocks() for unwritten extents Zhang Yi
2026-10-09 10:53   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 08/31] ext4: skip block allocation for holes in the data submission path Zhang Yi
2026-10-09 10:58   ` sashiko-bot
2026-10-10  0:55     ` Zhang Yi
2026-10-09 10:30 ` [PATCH v7 09/31] ext4: add iomap address space operations for buffered I/O Zhang Yi
2026-10-09 10:54   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 10/31] ext4: implement buffered read path using iomap Zhang Yi
2026-10-09 11:07   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 11/31] ext4: pass out extent seq counter when mapping da blocks Zhang Yi
2026-10-09 10:55   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 12/31] ext4: do not use data=ordered mode for inodes using buffered iomap path Zhang Yi
2026-10-09 11:01   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 13/31] ext4: implement buffered write path using iomap Zhang Yi
2026-10-09 11:03   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 14/31] ext4: rework handle credit accounting for unwritten extent conversion Zhang Yi
2026-10-09 11:20   ` sashiko-bot
2026-10-10  2:33     ` Zhang Yi
2026-10-09 10:30 ` [PATCH v7 15/31] ext4: implement writeback path using iomap Zhang Yi
2026-10-09 11:13   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 16/31] ext4: implement mmap " Zhang Yi
2026-10-09 11:10   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 17/31] ext4: implement partial block zero range " Zhang Yi
2026-10-09 11:09   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 18/31] ext4: drain writeback before removing extents on the iomap path Zhang Yi
2026-10-09 11:06   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 19/31] ext4: add block mapping tracepoints for iomap buffered I/O path Zhang Yi
2026-10-09 11:03   ` sashiko-bot
2026-10-10  3:04     ` Zhang Yi
2026-10-09 10:30 ` [PATCH v7 20/31] ext4: disable online defrag when inode using " Zhang Yi
2026-10-09 11:00   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 21/31] ext4: add EXT4_STATE_DISKSIZE_GROW_PENDING state bit and helpers Zhang Yi
2026-10-09 11:04   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 22/31] ext4: submit and wait for pending disksize-grow I/O on writeback Zhang Yi
2026-10-09 11:18   ` sashiko-bot
2026-10-10  3:11     ` Zhang Yi
2026-10-09 10:30 ` [PATCH v7 23/31] ext4: advance i_disksize to i_size upon disksize-grow I/O completion Zhang Yi
2026-10-09 11:19   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 24/31] ext4: defer i_disksize update while DISKSIZE_GROW_PENDING is set Zhang Yi
2026-10-09 11:21   ` sashiko-bot
2026-10-10  3:35     ` Zhang Yi
2026-10-09 10:30 ` [PATCH v7 25/31] ext4: submit and wait for disksize-grow I/O in fallocate paths Zhang Yi
2026-10-09 11:25   ` sashiko-bot
2026-10-09 10:30 ` [PATCH v7 26/31] ext4: clear DISKSIZE_GROW_PENDING on truncate or error Zhang Yi
2026-10-09 11:16   ` sashiko-bot [this message]
2026-10-10  4:59     ` Zhang Yi
2026-10-09 10:30 ` [PATCH v7 27/31] ext4: set DISKSIZE_GROW_PENDING after zeroing unaligned EOF block Zhang Yi
2026-10-09 11:21   ` sashiko-bot
2026-10-10  7:21     ` Zhang Yi
2026-10-10  9:00   ` Ojaswin Mujoo
2026-10-10  9:50     ` Zhang Yi
2026-10-10 13:49       ` Ojaswin Mujoo
2026-10-10 15:54         ` Zhang Yi
2026-10-11  9:30           ` Ojaswin Mujoo
2026-10-09 10:30 ` [PATCH v7 28/31] ext4: add tracepoints for DISKSIZE_GROW_PENDING set, clear, and wait Zhang Yi
2026-10-09 11:13   ` sashiko-bot
2026-10-09 10:38 ` [PATCH v7 29/31] ext4: add tracepoints for EOF block zeroing and disksize-grow I/O Zhang Yi
2026-10-09 11:16   ` sashiko-bot
2026-10-09 10:38 ` [PATCH v7 30/31] ext4: partially enable iomap for the buffered I/O path of regular files Zhang Yi
2026-10-09 11:33   ` sashiko-bot
2026-10-10  8:09     ` Zhang Yi
2026-10-09 10:38 ` [PATCH v7 31/31] ext4: introduce a mount option for iomap buffered I/O path Zhang Yi
2026-10-09 11:17   ` sashiko-bot
2026-10-09 17:54 ` [syzbot ci] Re: ext4: use iomap for regular file's " syzbot ci
2026-10-10  8:44   ` Zhang Yi

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-165341@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huaweicloud.com \
    /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.