All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@linux.dev>
To: Tal Zussman <tz2294@columbia.edu>, Jens Axboe <axboe@kernel.dk>,
	Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] block: fail a short atomic bounce in bio_iov_iter_bounce_write()
Date: Mon, 9 Nov 2026 18:41:58 +0000	[thread overview]
Message-ID: <002d78a8-e344-45cc-9529-f2dd345a9ee4@linux.dev> (raw)
In-Reply-To: <74c7632e-52fa-4378-a15b-f90b492fe613@columbia.edu>

On 11/9/26 18:27, Tal Zussman wrote:
>> This looks reasonable, as atomic stable writes are implied to be
>> supported from 3373503df025a ("xfs: use bounce buffering direct I/O when
>> the device requires stable pages"). I am wondering how to test and prove
>> this (change is good and maintained)?
>>
> I tested this with XFS on scsi_debug (dif=1 dix=1 atomic_wr=1), doing
> 1M RWF_ATOMIC direct writes and using fail_page_alloc to make the
> folio allocations in bio_alloc_bounce_folios() fail partway through.
> I had an LLM make it pretty precise and target bio_alloc_bounce_folios()
> using the stack filtering mechanism, so I don't think this necessarily
> makes sense as an xfstest if that's what you were thinking...
> 
> Without this patch, the write returns -EINVAL and hits the
> WARN_ON_ONCE() in iomap_dio_bio_iter_one(). With it, the write returns
> -EINVAL without the warning.
> 
> This also happened to turn up a scsi_debug bug: with dif=1 dix=1 it
> doesn't store the protection information for WRITE ATOMIC(16), so
> reading back an atomic write fails. I'll send a separate patch for that.

ok, I'll await the patch.

> 
> Does that answer your question/is that what you were getting at?

Yes, this is ok. I am really just getting at whether we can add a test 
for this scenario.

Thanks,
John

  reply	other threads:[~2026-11-09 18:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08  4:24 [PATCH 0/2] block: fail short atomic bounce bios in bio_iov_iter_bounce_write() Tal Zussman
2026-11-08  4:24 ` [PATCH 1/2] block: fail a short atomic bounce " Tal Zussman
2026-11-08 17:13   ` John Garry
2026-11-09 18:27     ` Tal Zussman
2026-11-09 18:41       ` John Garry [this message]
2026-11-08  4:24 ` [PATCH 2/2] iomap: remove the atomic write length check in iomap_dio_bio_iter_one() Tal Zussman
2026-11-08 17:06   ` John Garry
2026-11-09 18:34     ` Tal Zussman
2026-11-09 18:44       ` John Garry
2026-11-09 22:46         ` Tal Zussman
2026-11-10  8:42           ` John Garry

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=002d78a8-e344-45cc-9529-f2dd345a9ee4@linux.dev \
    --to=john.garry@linux.dev \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --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.