On Fri, 12/18 07:05, Paolo Bonzini wrote:
>
>
> On 18/12/2015 01:57, Fam Zheng wrote:
> > Oh hang on, in scsi_req_dequeue, if req->enqueued is already false, the
> > matching scsi_req_unref is never called.
>
> The matching unref for scsi_req_cancel_async's ref is in
> scsi_req_cancel_complete.
On 18/12/2015 01:57, Fam Zheng wrote:
> Oh hang on, in scsi_req_dequeue, if req->enqueued is already false, the
> matching scsi_req_unref is never called.
The matching unref for scsi_req_cancel_async's ref is in
scsi_req_cancel_complete. You're right that there is a leak if
we get to the secon
On Thu, 12/17 18:46, Paolo Bonzini wrote:
> This was found by code inspection. If the request is cancelled twice,
> the notifier is never called on the second cancellation request,
> and hence for example a TMF might never finish.
>
> All the calls in scsi_req_cancel_async are idempotent, so the
This was found by code inspection. If the request is cancelled twice,
the notifier is never called on the second cancellation request,
and hence for example a TMF might never finish.
All the calls in scsi_req_cancel_async are idempotent, so the change
is safe.
Reviewed-by: Fam Zheng
Signed-off-
