All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+f111db4cb2acd44eb2f4@syzkaller.appspotmail.com>
To: diasyzhangqing@gmail.com
Cc: adilger.kernel@dilger.ca, diasyzhang@tencent.com,
	diasyzhangqing@gmail.com,  jack@suse.cz,
	libaokun@linux.alibaba.com, linux-ext4@vger.kernel.org,
	 linux-kernel@vger.kernel.org, ojaswin@linux.ibm.com,
	ritesh.list@gmail.com,  tytso@mit.edu, yi.zhang@huawei.com,
	syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] ext4: wait for tail page commit before truncating a failed write
Date: Thu, 12 Nov 2026 03:59:20 -0800	[thread overview]
Message-ID: <6af5aa18.41d0a7c9.ab0b9.0108.GAE@google.com> (raw)
In-Reply-To: <20261112115906.17915-1-diasyzhangqing@gmail.com>

> From: Qing Zhang <diasyzhang@tencent.com>
>
> In data=journal mode, a failed extending write can leave buffers beyond
> i_size attached to the committing transaction. When blocksize < PAGE_SIZE,
> invalidating these buffers in the partial tail folio returns -EBUSY,
> triggering a warning in ext4_journalled_invalidate_folio() and leaving
> invalidation incomplete.
>
> Call ext4_wait_for_tail_page_commit() before truncating the page cache
> in ext4_truncate_failed_write(), as is already done when shrinking a file
> via ext4_setattr(). The helper releases the folio lock before waiting
> for the commit to finish, then retries invalidation.
>
> Fixes: 53e872681fed ("ext4: fix deadlock in journal_unmap_buffer()")
> Reported-by: syzbot+f111db4cb2acd44eb2f4@syzkaller.appspotmail.com
> Closes: https://syzbot.appspot.com/bug?extid=f111db4cb2acd44eb2f4
> Signed-off-by: Qing Zhang <diasyzhang@tencent.com>
> ---
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Patch testing via #syz test is temporarily disabled.
See https://github.com/google/syzkaller/issues/8122 for details.

>
>  fs/ext4/ext4.h    | 1 +
>  fs/ext4/inode.c   | 2 +-
>  fs/ext4/truncate.h |  2 ++
>  3 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index f38fec3167fb..505ec38fa508 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -3214,6 +3214,7 @@ int ext4_get_fc_inode_loc(struct super_block *sb, unsigned int ino,
>  extern int ext4_inode_attach_jinode(struct inode *inode);
>  extern int ext4_can_truncate(struct inode *inode);
>  extern int ext4_truncate(struct inode *);
> +extern void ext4_wait_for_tail_page_commit(struct inode *inode);
>  extern int ext4_break_layouts(struct inode *);
>  extern int ext4_truncate_page_cache_block_range(struct inode *inode,
>  						loff_t start, loff_t end);
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 10cd85d4c721..f59c4a5b7561 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -6845,7 +6845,7 @@ int ext4_sync_inode_metadata(struct inode *inode, struct writeback_control *wbc)
>   * buffers that are attached to a folio straddling i_size and are undergoing
>   * commit. In that case we have to wait for commit to finish and try again.
>   */
> -static void ext4_wait_for_tail_page_commit(struct inode *inode)
> +void ext4_wait_for_tail_page_commit(struct inode *inode)
>  {
>  	unsigned offset;
>  	journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
> diff --git a/fs/ext4/truncate.h b/fs/ext4/truncate.h
> index ce84aa2786c7..c10e4ab4242e 100644
> --- a/fs/ext4/truncate.h
> +++ b/fs/ext4/truncate.h
> @@ -17,6 +17,8 @@ static inline void ext4_truncate_failed_write(struct inode *inode)
>  	 * We don't need to call ext4_break_layouts() because the blocks we
>  	 * are truncating were never visible to userspace.
>  	 */
>  	filemap_invalidate_lock(mapping);
> +	if (ext4_should_journal_data(inode))
> +		ext4_wait_for_tail_page_commit(inode);
>  	truncate_inode_pages(mapping, inode->i_size);
>  	ext4_truncate(inode);
>  	filemap_invalidate_unlock(mapping);
> -- 
> 2.43.0
>

  reply	other threads:[~2026-11-12 11:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 11:59 [PATCH] ext4: wait for tail page commit before truncating a failed write diasyzhangqing
2026-11-12 11:59 ` syzbot [this message]
2026-11-12 12:11 ` sashiko-bot

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=6af5aa18.41d0a7c9.ab0b9.0108.GAE@google.com \
    --to=syzbot+f111db4cb2acd44eb2f4@syzkaller.appspotmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=diasyzhang@tencent.com \
    --cc=diasyzhangqing@gmail.com \
    --cc=jack@suse.cz \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huawei.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.