On 11/28/18 9:26 AM, Keith Busch wrote:

On Wed, Nov 28, 2018 at 08:58:00AM -0700, Jens Axboe wrote:

quoted

On 11/28/18 8:49 AM, Keith Busch wrote:

quoted

On Wed, Nov 28, 2018 at 11:08:48AM +0100, Christoph Hellwig wrote:

quoted

On Wed, Nov 28, 2018 at 06:07:01PM +0800, Ming Lei wrote:

quoted

quoted

Is this the nvme target on top of null_blk?

Yes.

And it goes away if you revert just the last patch?

It looks like a problem existed before that last patch. Reverting it
helps only if the request happened to have not been reallocated. If it
had been reallocated, the NULL_IRQ_TIMER would have completed the wrong
request out-of-order. If this were a real device, that'd probably result
in data corruption.

null_blk just needs updating for this.

Isn't this the nvme target's problem? It shouldn't complete requests
dispatched to its backing device, so I'm thinking something like the
following is what should happen. Untested at the moment, but will try
it out shortly.

I looked at null_blk after the fact, and my recollection of how
that timeout stuff worked was wrong. I think you are right.

-- 
Jens Axboe