Hannes Reinecke <hare@xxxxxxx> writes: >> So, looked into things a bit more. >> It looks as if you're on the right track, although I doubt your >> patch will fix the issue for me :-( >> >> Thing is, you're right there is a race window between requeuing >> and softirq triggering, which could well be fixed by your patch. >> So for that reason alone I would like to take it. >> >> However, including your patch will end up opening another can of >> worms: the softirq might now be triggering _while the request is >> queued on the request queue_. >> blk_requeue_request will be putting the request back on the request >> queue, where it'll be stuck until being pulled off from >> scsi_request_fn(). >> So if the softirq triggers during that condition we'll end up >> calling the BUG_ON((!list_empty(&req->queuelist)) in >> __blk_put_request(). >> >> Guess we'd need to fix that one, too ... >> > Ah. Now I see it. > > We're requeuing from the softirq context, ie after the completion > has triggered. So the above scenario can't actually happen and the > patch is valid. Do you still think it won't solve the issue you're seeing? What issue is that, btw? > > So: > > Acked-by: Hannes Reinecke <hare@xxxxxxx> Thanks, I guess I'll have to send a properly signed-off patch, now. ;-) Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
