mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: liubaolin <liubaolin12138@163.com>
To: Hongling Zeng <zenghongling@kylinos.cn>,
	linkinjeon@kernel.org, hyc.lee@gmail.com
Cc: ntfs@lists.linux.dev, linux-kernel@vger.kernel.org,
	zhongling0719@126.com, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] ntfs: write back the truncated range before dropping it
Date: Tue, 15 Sep 2026 17:03:44 +0800	[thread overview]
Message-ID: <a615a9b3-3d33-45bf-b317-3cffc61244ab@163.com> (raw)
In-Reply-To: <20260915062742.750092-1-zenghongling@kylinos.cn>



在 2026/9/15 14:27, Hongling Zeng 写道:
> On a truncate, ntfs_setattr_size() drops the page cache beyond the new
> size with truncate_setsize() and only then updates the attribute on
> disk.  If that update fails, the size is reverted and the data beyond
> the new size becomes visible again -- but the pages were already
> dropped, and dirty data in them is lost, even though the truncate, the
> operation the user asked for, never happened.
> 
> Write the range back before dropping it.  If the writeback fails, fail
> the truncate with that error and keep the page cache intact; if the
> on-disk truncation fails afterwards, the reverted size can be re-read
> from disk.
> 
> Fixes: 9c87959601e8 ("ntfs: update file operations")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> ---
>   fs/ntfs/file.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
> 
> diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
> index 007d1614b9ac..1417a76788ed 100644
> --- a/fs/ntfs/file.c
> +++ b/fs/ntfs/file.c
> @@ -283,12 +283,27 @@ static int ntfs_setattr_size(struct inode *vi, struct iattr *attr)
>   		i_size_write(vi, attr->ia_size);
>   		pagecache_isize_extended(vi, old_size, attr->ia_size);
>   	} else {
> +		/*
> +		 * The on-disk truncation below can fail, in which case
> +		 * the size is reverted and the data beyond the new size
> +		 * becomes visible again.  Write that range back first:
> +		 * truncate_setsize() drops those pages and dirty data
> +		 * cannot be recovered afterwards.
> +		 */
> +		if (attr->ia_size < old_size) {
> +			err = filemap_write_and_wait_range(vi->i_mapping,
> +					attr->ia_size, old_size - 1);
> +			if (err)
> +				goto out_unlock;
> +		}
> +
>   		truncate_setsize(vi, attr->ia_size);
>   	}
>   
>   	err = ntfs_truncate_vfs(vi, attr->ia_size, old_size);
>   	if (err)
>   		i_size_write(vi, old_size);
> +out_unlock:
>   	filemap_invalidate_unlock(vi->i_mapping);
>   
>   	return err;

Hi Hongling,
   Thanks for the patch.  This fixes the page-aligned truncate case.

   However, this does not fully preserve the original data for a 
non-page-aligned truncate.  For example, with 4 KiB pages, consider 
truncating an 8 KiB file to 3000 bytes.  The writeback added by this 
patch preserves bytes 3000..8191 on disk, but truncate_setsize() 
eventually calls truncate_inode_partial_folio(), which zeroes bytes 
3000..4095 in the folio containing the new EOF while leaving that folio 
in the page cache.
   If ntfs_truncate_vfs() then fails, restoring only i_size makes 
3000..4095 visible again, but the EOF folio is still uptodate. Reads can 
therefore return the cached zeros instead of refaulting the original 
data from disk.

   The error path also needs to restore the folio containing the new 
EOF, or invalidate it so that it is refaulted from disk, with mmap 
writers taken into account.

Thanks,
Baolin.


      parent reply	other threads:[~2026-09-15  9:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15  6:27 Hongling Zeng
2026-09-15  6:27 ` [PATCH 2/2] ntfs: roll back the in-memory attributes if the metadata update fails Hongling Zeng
2026-09-15  9:33   ` liubaolin
2026-09-15  9:03 ` liubaolin [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=a615a9b3-3d33-45bf-b317-3cffc61244ab@163.com \
    --to=liubaolin12138@163.com \
    --cc=hyc.lee@gmail.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=zenghongling@kylinos.cn \
    --cc=zhongling0719@126.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®