All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Alcantara <pc@manguebit.org>
To: linux-cifs@vger.kernel.org, netfs@lists.linux.dev
Cc: David Howells <dhowells@redhat.com>,
	Christian Brauner <brauner@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Namjae Jeon <linkinjeon@kernel.org>,
	Ronnie Sahlberg <ronniesahlberg@gmail.com>,
	Shyam Prasad N <sprasad@microsoft.com>,
	Tom Talpey <tom@talpey.com>, Bharath SM <bharathsm@microsoft.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 1/5] netfs: clear post-EOF pagecache when extending a file via write
Date: Mon, 21 Sep 2026 21:08:40 -0300	[thread overview]
Message-ID: <242c19b39a3f30b93bdfa6574e99eb5a@manguebit.org> (raw)
In-Reply-To: <20260921230755.1133425-1-pc@manguebit.org>

Paulo Alcantara <pc@manguebit.org> writes:

> Fix netfs to erase the contents of a hole created after the EOF by an
> ordinary write if dirty data has been previously left there by writes
> through an mmapped region.  Neither the buffered nor the unbuffered/DIO
> write path clears that stale pagecache.
>
> Zero the tail of the folio straddling the EOF before an extending
> write.  That is the only folio that can hold data written past the EOF
> through an mmap, as pages wholly beyond the EOF can't be faulted in.
> The folio is zeroed rather than dropped so a concurrent extending write
> can't lose data.
>
> truncate_pagecache() can't be used here: it must be called with the
> i_rwsem held exclusively, but these write paths only hold it shared,
> and it would block unconditionally, breaking IOCB_NOWAIT.
>
> Export the helper so filesystems can clear the same stale data from
> their own truncate paths.
>
> Closes: https://sashiko.dev/#/patchset/20260921154957.903891-1-pc%40manguebit.org
> Fixes: 938e13a73b24 ("netfs: Implement buffered write API")
> Fixes: 153a9961b551 ("netfs: Implement unbuffered/DIO write support")
> Reviewed-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Paulo Alcantara <pc@manguebit.org>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Namjae Jeon <linkinjeon@kernel.org>
> Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
> Cc: Shyam Prasad N <sprasad@microsoft.com>
> Cc: Tom Talpey <tom@talpey.com>
> Cc: Bharath SM <bharathsm@microsoft.com>
> Cc: stable@vger.kernel.org
> ---
>  Documentation/filesystems/netfs_library.rst | 18 ++++++++
>  fs/netfs/buffered_write.c                   |  9 ++++
>  fs/netfs/direct_write.c                     |  9 ++++
>  fs/netfs/misc.c                             | 51 +++++++++++++++++++++
>  include/linux/netfs.h                       |  2 +
>  5 files changed, 89 insertions(+)

Will address more Sashiko comments in next version.  Please ignore this
one.

  parent reply	other threads:[~2026-09-22  0:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 23:07 [PATCH v2 1/5] netfs: clear post-EOF pagecache when extending a file via write Paulo Alcantara
2026-09-21 23:07 ` [PATCH v2 2/5] smb: client: clear post-EOF pagecache when extending a file via truncate Paulo Alcantara
2026-09-21 23:07 ` [PATCH v2 3/5] smb: client: discard post-EOF pagecache when extending a file via zero range Paulo Alcantara
2026-09-21 23:07 ` [PATCH v2 4/5] smb: client: discard post-EOF pagecache when extending a file via copy range Paulo Alcantara
2026-09-21 23:07 ` [PATCH v2 5/5] smb: client: discard post-EOF pagecache when extending a file via clone range Paulo Alcantara
2026-09-22  0:08 ` Paulo Alcantara [this message]
2026-09-22  1:08 ` [PATCH v2 1/5] netfs: clear post-EOF pagecache when extending a file via write Matthew Wilcox
2026-09-23 19:20   ` David Howells
2026-09-23 23:46   ` Paulo Alcantara
2026-09-24  4:16     ` Matthew Wilcox
2026-09-24 13:43       ` Paulo Alcantara

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=242c19b39a3f30b93bdfa6574e99eb5a@manguebit.org \
    --to=pc@manguebit.org \
    --cc=bharathsm@microsoft.com \
    --cc=brauner@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=netfs@lists.linux.dev \
    --cc=ronniesahlberg@gmail.com \
    --cc=sprasad@microsoft.com \
    --cc=stable@vger.kernel.org \
    --cc=tom@talpey.com \
    --cc=willy@infradead.org \
    /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.