Re: [PATCH 3/3] nvme/fcloop: flush workqueue before calling nvme_fc_unregister_remoteport()

[Hannes Reinecke <hare@suse.de>]

On 3/7/20 2:12 AM, James Smart wrote:
> 
> 
> On 3/6/2020 5:04 AM, Hannes Reinecke wrote:
>> nvme_fc_unregister_remoteport() will be sending LS requests, which then
>> would end up on a workqueue for processing. This will deadlock with
>> fcloop_remoteport_delete() which would try to flush the very same queue.
>>
>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>> ---
>>   drivers/nvme/target/fcloop.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/nvme/target/fcloop.c b/drivers/nvme/target/fcloop.c
>> index 4f9435d9fa61..0209da9bcb67 100644
>> --- a/drivers/nvme/target/fcloop.c
>> +++ b/drivers/nvme/target/fcloop.c
>> @@ -943,7 +943,6 @@ fcloop_remoteport_delete(struct 
>> nvme_fc_remote_port *remoteport)
>>   {
>>       struct fcloop_rport *rport = remoteport->private;
>> -    flush_work(&rport->ls_work);
>>       fcloop_nport_put(rport->nport);
>>   }
>> @@ -1278,6 +1277,7 @@ __remoteport_unreg(struct fcloop_nport *nport, 
>> struct fcloop_rport *rport)
>>       if (!rport)
>>           return -EALREADY;
>> +    flush_work(&rport->ls_work);
>>       return nvme_fc_unregister_remoteport(rport->remoteport);
>>   }
> 
> And this is what we really needed, although there's probably a like 
> thing that should be done on the targetport as well.
> 
As mentioned in the previous mail: I tried, but that crashed even more 
horribly.
Might've been to stupid to do it correctly, though.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@suse.de                               +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme