On 2023/8/10 05:49, Christoph Hellwig wrote:
> Oh well. I don't feel like we're going to find the root cause
> given that its late in the merge window and I'm running out of
> time I have to work due to the annual summer vacation. Unless
> someone like Chengming who knows the flush code pretty well
> feels like working with chuck on a few more iterations we'll
Hi,
No problem, I can work with Chuck to find the root cause if Chuck
has time too, since I still can't reproduce it by myself.
Maybe we should first find what's the status of the hang request?
I can write a Drgn script to find if any request hang in the queue.
Christoph, it would be very helpful if you share some thoughts
and directions.
> have to revert it. Which is going to be a very painful merge
> with Chengming's work in the for-6.6 branch.
>
Maybe we can revert it manually if we still fail since that commit
just let postflushes go to the normal I/O path, instead of going to
the flush state machine.
So I think it should be fine if we just delete that case?
Chuck, could you please help to check this change on block/for-next?
Thanks!
diff --git a/block/blk-flush.c b/block/blk-flush.c
index e73dc22d05c1..7ea3c00f40ce 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -442,17 +442,6 @@ bool blk_insert_flush(struct request *rq)
* Queue for normal execution.
*/
return false;
- case REQ_FSEQ_DATA | REQ_FSEQ_POSTFLUSH:
- /*
- * Initialize the flush fields and completion handler to trigger
- * the post flush, and then just pass the command on.
- */
- blk_rq_init_flush(rq);
- rq->flush.seq |= REQ_FSEQ_PREFLUSH;
- spin_lock_irq(&fq->mq_flush_lock);
- fq->flush_data_in_flight++;
- spin_unlock_irq(&fq->mq_flush_lock);
- return false;
default:
/*
* Mark the request as part of a flush sequence and submit it
