On Mon, 2018-04-02 at 15:01 -0700, tj@xxxxxxxxxx wrote: > On Mon, Apr 02, 2018 at 09:56:41PM +0000, Bart Van Assche wrote: > > This patch increases the time during which .aborted_gstate == .gstate if the > > timeout is reset. Does that increase the chance that a completion will be missed > > if the request timeout is reset? > > It sure does, but we're comparing an outright kernel bug vs. an > inherently opportunistic mechanism being a bit more lossy. I think > the answer is pretty clear. Hello Tejun, Please elaborate what your long-term goal is for the blk-mq timeout handler. The legacy block layer suspends request state changes while a timeout is being processed by holding the request queue lock while requests are being processed, while processing a timeout and while calling q->rq_timed_out_fn(rq). Do you think it is possible to make the blk-mq core suspend request processing while processing a timeout without introducing locking in blk_mq_complete_request()? If you do not plan to add locking in blk_mq_complete_request(), do you think it is possible to fix all the races we discussed in previous e-mails? Thanks, Bart.
