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.