Linux EXT4 FS development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hengyu Liang" <hengyul@cs.unc.edu>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] ext4: do not advance i_size on a buffered write that copied nothing
Date: Fri, 09 Oct 2026 04:59:24 +0000	[thread overview]
Message-ID: <sashiko-outbox-164860@kernel.org> (raw)
In-Reply-To: <20261009044656.1993196-1-hengyul@cs.unc.edu>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ext4: delayed block and quota leak on failed writes in delalloc path
--

commit acb80c0263f3e15c2b0d945f36271eb41aefe50e
Author: Hengyu Liang <hengyul@cs.unc.edu>

ext4: do not advance i_size on a buffered write that copied nothing

This commit changes the ext4 buffered write path to avoid updating i_size
when a write past EOF copies zero bytes. It also attempts to clean up the
page cache and delayed extents beyond i_size in the delalloc path.

> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 9a9ec02dce9fd..339b20a238053 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c

[ ... ]

> @@ -3210,6 +3213,24 @@ static int ext4_da_should_update_i_disksize(struct folio *folio,
>  	return 1;
>  }
>  
> +/*
> + * Delalloc counterpart of ext4_truncate_failed_write(): ->write_begin() only
> + * reserved delayed blocks, so drop the page cache and the delayed extents
> + * beyond i_size and leave the blocks that are allocated there alone.
> + */
> +static void ext4_da_truncate_failed_write(struct inode *inode)
> +{
> +	struct address_space *mapping = inode->i_mapping;
> +	ext4_lblk_t lblk = EXT4_B_TO_LBLK(inode, inode->i_size);

[Severity: High]
Does this EXT4_B_TO_LBLK() conversion round up the block number?

If i_size is not block-aligned, won't this skip the delayed extent reserved
for the block overlapping EOF, leaking its reservation since the folio is
never dirtied?

> +
> +	filemap_invalidate_lock(mapping);
> +	truncate_inode_pages(mapping, inode->i_size);
> +	down_write(&EXT4_I(inode)->i_data_sem);
> +	ext4_es_remove_extent(inode, lblk, EXT_MAX_BLOCKS - lblk);
> +	up_write(&EXT4_I(inode)->i_data_sem);
> +	filemap_invalidate_unlock(mapping);
> +}

[ ... ]

> @@ -3261,9 +3282,16 @@ static int ext4_da_do_write_end(struct address_space *mapping,
>  	folio_unlock(folio);
>  	folio_put(folio);
>  
> -	if (pos > old_size)
> +	if (copied && pos > old_size)
>  		pagecache_isize_extended(inode, old_size, pos);
>  
> +	/*
> +	 * A write past i_size that copied nothing leaves i_size alone, so
> +	 * trim what ->write_begin() set up beyond it.
> +	 */
> +	if (!copied && pos > old_size)
> +		ext4_da_truncate_failed_write(inode);

[Severity: High]
Does this condition miss cases where the write starts before or exactly at EOF
but extends past it?

If a failed write (copied == 0) starts exactly at EOF (pos == old_size) or
overlaps EOF (pos < old_size and pos + len > old_size), pos > old_size is
false. 

Since the write_begin path already reserved delayed blocks past i_size,
will skipping this cleanup permanently leak those reserved blocks and quota?

> +
>  	if (!disksize_changed)
>  		return copied;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009044656.1993196-1-hengyul@cs.unc.edu?part=1

      reply	other threads:[~2026-10-09  4:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  4:46 [PATCH] ext4: do not advance i_size on a buffered write that copied nothing Hengyu Liang
2026-10-09  4:59 ` sashiko-bot [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=sashiko-outbox-164860@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=hengyul@cs.unc.edu \
    --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