All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tal Zussman" <tz2294@columbia.edu>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH RFC v2 2/3] ext4: never fall back to buffered I/O for atomic direct writes
Date: Mon, 12 Oct 2026 17:28:57 +0000	[thread overview]
Message-ID: <sashiko-outbox-168457@kernel.org> (raw)
In-Reply-To: <20261012-ext4-atomic-no-fallback-v2-2-c4b30c60e500@columbia.edu>

> ext4_dio_write_iter() finishes a short direct write through the page
> cache. ext4_buffered_write_iter() now rejects IOCB_ATOMIC, so a short
> atomic write would warn and then fail with -EOPNOTSUPP, as if atomic
> writes were unsupported on the inode.
> 
> This came out of a block device fix [1], where an IOCB_ATOMIC direct
> write could complete short when only part of the buffer could be
> pinned, with the rest going through the buffered fallback. Christoph
> Hellwig noted that ext4 has the same fallback and only warns in it [2],
> and John Garry agreed it should reject the write instead [3].
> 
> In contrast to the block device, nothing reaches the branch on ext4
> today: iomap requires the mapping to cover the whole atomic write, a
> buffer that can't be pinned in full fails in iomap before the bio is
> submitted, and a failed page cache invalidation returns -EAGAIN rather
> than reaching the buffered fallback. A short atomic write is therefore
> a bug, and neither a short count nor -EOPNOTSUPP is a valid result for
> one. Fail the write with -EIO before the fallback, keeping the WARN()
> so any future bug is visible.
> 
> Link: https://lore.kernel.org/linux-block/20260828-blkdev-fixes-v2-0-32f3f40cebed@columbia.edu/ [1]
> Link: https://lore.kernel.org/linux-block/20260907071217.GD934@lst.de/ [2]
> Link: https://lore.kernel.org/linux-block/a7752d1e-8ec1-44d1-a266-c287c315e8ab@oracle.com/ [3]
> Signed-off-by: Tal Zussman <tz2294@columbia.edu>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012-ext4-atomic-no-fallback-v2-0-c4b30c60e500@columbia.edu?part=2


  reply	other threads:[~2026-10-12 17:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 17:17 [PATCH RFC v2 0/3] ext4: don't complete atomic writes through buffered I/O Tal Zussman
2026-10-12 17:17 ` [PATCH RFC v2 1/3] ext4: reject atomic writes on inodes that can't do direct I/O Tal Zussman
2026-10-12 17:33   ` sashiko-bot
2026-10-13 12:27   ` Jan Kara
2026-10-12 17:17 ` [PATCH RFC v2 2/3] ext4: never fall back to buffered I/O for atomic direct writes Tal Zussman
2026-10-12 17:28   ` sashiko-bot [this message]
2026-10-13 12:28   ` Jan Kara
2026-10-12 17:17 ` [PATCH RFC v2 3/3] ext4: don't advertise atomic writes for DAX inodes Tal Zussman
2026-10-12 17:25   ` sashiko-bot
2026-10-13 12:30   ` Jan Kara

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-168457@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tytso@mit.edu \
    --cc=tz2294@columbia.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 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.