diff options
author | David Howells <dhowells@redhat.com> | 2024-08-24 12:56:53 +0100 |
---|---|---|
committer | Christian Brauner <brauner@kernel.org> | 2024-08-24 16:09:17 +0200 |
commit | e00e99ba6c6b8e5239e75cd6684a6827d93c39a2 (patch) | |
tree | ba563e4f2115181fe3024bf1a600598f5fe0c6e3 /arch/m68k/include/asm/zorro.h | |
parent | 950b03d0f664a54389a555d79215348ed413161f (diff) | |
download | linux-e00e99ba6c6b8e5239e75cd6684a6827d93c39a2.tar.gz linux-e00e99ba6c6b8e5239e75cd6684a6827d93c39a2.tar.bz2 linux-e00e99ba6c6b8e5239e75cd6684a6827d93c39a2.zip |
netfs: Fix interaction of streaming writes with zero-point tracker
When a folio that is marked for streaming write (dirty, but not uptodate,
with partial content specified in the private data) is written back, the
folio is effectively switched to the blank state upon completion of the
write. This means that if we want to read it in future, we need to reread
the whole folio.
However, if the folio is above the zero_point position, when it is read
back, it will just be cleared and the read skipped, leading to apparent
local corruption.
Fix this by increasing the zero_point to the end of the dirty data in the
folio when clearing the folio state after writeback. This is analogous to
the folio having ->release_folio() called upon it.
This was causing the config.log generated by configuring a cpython tree on
a cifs share to get corrupted because the scripts involved were appending
text to the file in small pieces.
Fixes: 288ace2f57c9 ("netfs: New writeback implementation")
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/563286.1724500613@warthog.procyon.org.uk
cc: Steve French <sfrench@samba.org>
cc: Paulo Alcantara <pc@manguebit.com>
cc: Jeff Layton <jlayton@kernel.org>
cc: linux-cifs@vger.kernel.org
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'arch/m68k/include/asm/zorro.h')
0 files changed, 0 insertions, 0 deletions