Re: [PATCH 18/22] xfs: use BIO_COMPLETE_IN_TASK for bounce buffered read I/Os

Christoph Hellwig <[email protected]>
Newsgroups org.kernel.vger.linux-xfs,org.kernel.vger.linux-block,org.kernel.vger.linux-fsdevel
Message-ID <[email protected]>
On Fri, Jul 24, 2026 at 11:38:53AM +0200, Andrey Albershteyn wrote:
> On 2026-07-24 08:21:20, Christoph Hellwig wrote:
> > On Thu, Jul 23, 2026 at 05:58:49PM +0200, Andrey Albershteyn wrote:
> > > I would probably need something like this for fsverity.
> > > 
> > > When using integrity checksums with fsverity together, both file data
> > > ioends and fsverity metadata ioends get onto the inode queue
> > > (without checksums there's no metadata ioends). This way worker could
> > > self-deadlock if data ioend processed first in xfs_end_io(). It will
> > > call verify_bio to read merkle pages which could be already waiting
> > > in queue.
> > 
> > Yes.  Same as the situation we have (or had as this is changing
> > for 7.3) with fsverity and fscrypt.
> > 
> > > I initially considered changing xfs_end_io, for read ioends, to just
> > > schedule them instead of adding to the queue, but decided just sort
> > > metadata ioends first in the queue [1] as a bit simpler fix.
> > > 
> > > The difference is that work won't be scheduled on the high-priority
> > > fsverity's workqueue. Not sure how critical this is as with
> > > checksums all reads would be the same priority.
> > 
> > I'll need to go back to your series, but just sorting isn't going
> > to fix the problem, as the reading of the verity metadata could
> > be kicked off from the completion workqueue and you could be blocking
> > the rescuer thread.  So either verity needs it's own WQ, or we'd need
> > some way for a currently running I/O completion to exit and get
> > restarted.
> 
> Oh I see, then, the data reads could be queue further with
> fsverity_enqueue_verify_work(ioend). This way bio completion queue
> can continue process incoming metadata reads while data ioend is
> waiting for verification.


fsverity_enqueue_verify_work would actually really benefit from doing
a list (percpu or otherwise) so that the caller only needs a single
or doubly linked list entry instead of adding another struct.

But if we don't want to do that work yet, adding a verity context
of some sort and using fsverity_enqueue_verify_work could work.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.