From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
"Darrick J. Wong" <djwong@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Avi Kivity <avi@scylladb.com>,
Damien Le Moal <dlemoal@kernel.org>,
Naohiro Aota <naohiro.aota@wdc.com>,
Johannes Thumshirn <jth@kernel.org>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org
Subject: Re: [PATCH 4/5] iomap: support write completions from interrupt context
Date: Thu, 13 Nov 2025 13:35:32 +0100 [thread overview]
Message-ID: <20251113123532.GA21292@lst.de> (raw)
In-Reply-To: <ewzcc5tots6ughnbqlqmvje4ex2eb5tug2mapzvcf4zstb7fxn@qruu4xs4nblt>
On Thu, Nov 13, 2025 at 01:06:34PM +0100, Jan Kara wrote:
> On Thu 13-11-25 11:06:30, Christoph Hellwig wrote:
> > On Thu, Nov 13, 2025 at 10:54:46AM +0100, Jan Kara wrote:
> > > > You mean drop the common helper? How would that be better and less
> > > > fragile? Note that I care strongly, but I don't really see the point.
> > >
> > > Sorry I was a bit terse. What I meant is that the two users of
> > > iomap_dio_is_overwrite() actually care about different things and that
> > > results in that function having a bit odd semantics IMHO. The first user
> > > wants to figure out whether calling generic_write_sync() is needed upon io
> > > completion to make data persistent (crash safe).
> >
> > Yes.
> >
> > > The second user cares
> > > whether we need to do metadata modifications upon io completion to make data
> > > visible at all.
> >
> > Not quite. It cares if either generic_write_sync needs be called,
> > or we need a metadata modification, because both require the workqueue.
>
> I agree but generic_write_sync() calling is handled by
>
> + else if (dio->flags & IOMAP_DIO_NEED_SYNC)
> + dio->flags &= ~IOMAP_DIO_INLINE_COMP;
>
> in your patch. So I assumed (maybe wrongly) that the second call to
> iomap_dio_is_overwrite() in iomap_dio_bio_iter() is only about detecting a
> need of metadata modification. And my argument is that the patch could use
> IOMAP_DIO_UNWRITTEN | IOMAP_DIO_COW the same way as it uses
> IOMAP_DIO_NEED_SYNC instead of calling iomap_dio_is_overwrite().
>
> But if you don't like that I don't think it makes a huge difference and the
> code is correct as is so feel free to add:
I'll take a look if there is a way to clear thing up a bit.
next prev parent reply other threads:[~2025-11-13 12:35 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 7:21 enable iomap dio write completions from interrupt context Christoph Hellwig
2025-11-12 7:21 ` [PATCH 1/5] fs, iomap: remove IOCB_DIO_CALLER_COMP Christoph Hellwig
2025-11-12 19:59 ` Jan Kara
2025-11-13 0:00 ` Chaitanya Kulkarni
2025-11-12 7:21 ` [PATCH 2/5] iomap: always run error completions in user context Christoph Hellwig
2025-11-12 20:01 ` Jan Kara
2025-11-13 0:02 ` Chaitanya Kulkarni
2025-11-12 7:21 ` [PATCH 3/5] iomap: rework REQ_FUA selection Christoph Hellwig
2025-11-12 20:07 ` Jan Kara
2025-11-12 7:21 ` [PATCH 4/5] iomap: support write completions from interrupt context Christoph Hellwig
2025-11-12 20:25 ` Jan Kara
2025-11-13 6:50 ` Christoph Hellwig
2025-11-13 9:54 ` Jan Kara
2025-11-13 10:06 ` Christoph Hellwig
2025-11-13 12:06 ` Jan Kara
2025-11-13 12:35 ` Christoph Hellwig [this message]
2025-11-12 7:21 ` [PATCH 5/5] iomap: invert the polarity of IOMAP_DIO_INLINE_COMP Christoph Hellwig
2025-11-13 12:09 ` Jan Kara
2025-11-12 8:43 ` enable iomap dio write completions from interrupt context Damien Le Moal
2025-11-12 8:44 ` Christoph Hellwig
2025-11-12 8:46 ` Damien Le Moal
2025-11-13 9:58 ` Jan Kara
2025-11-13 10:05 ` Christoph Hellwig
2025-11-13 10:07 ` Damien Le Moal
2025-11-13 11:52 ` Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2025-11-13 17:06 enable iomap dio write completions from interrupt context v2 Christoph Hellwig
2025-11-13 17:06 ` [PATCH 4/5] iomap: support write completions from interrupt context Christoph Hellwig
2025-11-24 11:11 ` 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=20251113123532.GA21292@lst.de \
--to=hch@lst.de \
--cc=avi@scylladb.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=dlemoal@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=jth@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=naohiro.aota@wdc.com \
--cc=viro@zeniv.linux.org.uk \
/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.