mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Prusakowski <jprusakowski@google.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>
Cc: linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org,
	 Jan Prusakowski <jprusakowski@google.com>,
	Eric Biggers <ebiggers@google.com>,
	 Yonggil Song <yonggil.song@samsung.com>,
	Hans Holmberg <hans.holmberg@wdc.com>
Subject: [PATCH RESEND 0/9] f2fs: fix stale data exposure on failed O_DIRECT writes
Date: Thu, 12 Nov 2026 14:33:46 +0000	[thread overview]
Message-ID: <20261112143355.2923939-1-jprusakowski@google.com> (raw)

Resending to include Jaegeuk Kim and the mailing lists
(linux-f2fs-devel and linux-kernel), which were accidentally omitted
from the initial submission. No changes to the patches.

When an O_DIRECT write fails with an I/O error, f2fs can leave the file
pointing to blocks that were never written, so reads return whatever the
disk contained before, possibly data of a deleted file. xfstests
generic/250 and generic/252 check this for direct writes to fallocated
blocks under dm-error, and both fail on f2fs. This series fixes them,
along with several error handling issues found on the way.

Patches 1-2 fix issues in compressed file paths hit by these tests:
sleeping in atomic context when reporting a decompression error, and a
read error in prepare_compress_overwrite() stopping the checkpoint
instead of failing the write.

Patch 3 keeps the old block address in the dnode when the block
allocation of an out-of-place write fails, instead of replacing it with
NULL_ADDR.

Patch 4 makes the buffered fallback of O_DIRECT writes return errors,
following direct_write_fallback(); generic/299 hits one of them.

Patch 5 truncates blocks allocated past EOF by a failed direct write.

Patch 6 tracks out-of-place block updates while an O_DIRECT write falls
back to buffered I/O, and rolls back those whose write failed, restoring
the old blocks or resetting the blocks to NEW_ADDR.

Patch 7 records blocks allocated during a native direct write (for holes,
preallocated NEW_ADDR ranges, and out-of-place overwrites in LFS mode)
per kiocb, and rolls back any unwritten blocks if the direct write fails
or stops short. Overlapping reads and writes wait for the in-flight
allocating direct write to complete, while non-overlapping async direct
writes proceed in parallel. This fixes generic/250 and generic/252
without falling back to buffered I/O.

Patches 8-9 fix compressed files (where O_DIRECT writes fall back to
buffered I/O): patch 8 cleans up when a compressed cluster write fails
to be submitted, and patch 9 extends the buffered fallback rollback to
compressed cluster writes.

Tested with full xfstests (-g auto) across default, compress and encrypt
configurations with CONFIG_PROVE_LOCKING and CONFIG_DEBUG_KMEMLEAK
enabled.

Assisted-by: LLM

Jan Prusakowski (9):
  f2fs: compress: avoid sleeping in atomic context in
    f2fs_decompress_cluster()
  f2fs: compress: abort on read error in prepare_compress_overwrite()
  f2fs: keep old block address when out-of-place write fails to allocate
  f2fs: propagate errors from buffered fallback of O_DIRECT writes
  f2fs: truncate blocks allocated past EOF by a failed direct write
  f2fs: roll back failed block updates of O_DIRECT buffered fallback
  f2fs: roll back failed block updates of direct writes
  f2fs: compress: fix cleanup when a cluster write fails to be submitted
  f2fs: compress: roll back failed cluster writes of O_DIRECT buffered
    fallback

 fs/f2fs/compress.c | 179 ++++++++++-
 fs/f2fs/data.c     | 185 ++++++++++-
 fs/f2fs/f2fs.h     |  99 ++++++
 fs/f2fs/file.c     | 745 +++++++++++++++++++++++++++++++++++++++++++--
 fs/f2fs/segment.c  |  49 ++-
 fs/f2fs/super.c    |  11 +
 6 files changed, 1217 insertions(+), 51 deletions(-)


base-commit: 9b12299b437e0cc3ebf402e7b36a89cc69151238
-- 
2.56.0.567.gdb80ae8cd5-goog


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

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 14:33 Jan Prusakowski [this message]
2026-11-12 14:33 ` [PATCH RESEND 1/9] f2fs: compress: avoid sleeping in atomic context in f2fs_decompress_cluster() Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 2/9] f2fs: compress: abort on read error in prepare_compress_overwrite() Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 3/9] f2fs: keep old block address when out-of-place write fails to allocate Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 4/9] f2fs: propagate errors from buffered fallback of O_DIRECT writes Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 5/9] f2fs: truncate blocks allocated past EOF by a failed direct write Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 6/9] f2fs: roll back failed block updates of O_DIRECT buffered fallback Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 7/9] f2fs: roll back failed block updates of direct writes Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 8/9] f2fs: compress: fix cleanup when a cluster write fails to be submitted Jan Prusakowski
2026-11-12 14:33 ` [PATCH RESEND 9/9] f2fs: compress: roll back failed cluster writes of O_DIRECT buffered fallback Jan Prusakowski

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=20261112143355.2923939-1-jprusakowski@google.com \
    --to=jprusakowski@google.com \
    --cc=chao@kernel.org \
    --cc=ebiggers@google.com \
    --cc=hans.holmberg@wdc.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yonggil.song@samsung.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®