Re: deadlock during fc_remove_host

["Bhanu Prakash Gollapudi" <bprakash@broadcom.com>]

On 4/20/2011 7:53 PM, Mike Christie wrote:
> On 04/20/2011 07:24 PM, Bhanu Prakash Gollapudi wrote:
>> Hi,
>>
>> We are seeing a similar issue to what Joe has observed a while back -
>> http://www.mail-archive.com/devel@open-fcoe.org/msg02993.html.
>>
>> This happens in a very corner case scenario by creating and destroying
>> fcoe interface in a tight loop. (fcoeadm -c followed by fcoeadm -d). The
>> system had a simple configuration with a single local port 2 remote ports.
>>
>> Reason for the deadlock:
>>
>> 1. destroy (fcoeadm -d) thread hangs in fc_remove_host().
>> 2. fc_remove_host() is trying to flush the shost->work_q, via
>> scsi_flush_work(), but the operation never completes.
>> 3. There are two works scheduled to be run in this work_q, one belonging
>> to rport A, and other rport B.
>> 4. The thread is currently executing rport_delete_work (fc_rport_final
>> _delete) for rport A. It calls fc_terminate_rport_io() that unblocks the
>> sdev->request_queue, so that __blk_run_queue() can be called. So, IO for
>> rport A is ready to run, but stuck at the async layer.
>> 5. Meanwhile, async layer is serializing all the IOs belonging to both
>> rport A and rport B. At this point, it is waiting for IO belonging to
>> rport B to complete.
>> 6. However, the request_queue for rport B is stopped and
>> fc_terminate_rport_io on rport B is not called yet to unblock the
>> device, which will only be called after rport A completes. rport A does
>
> Is the reason that rport b's terminate_rport_io has not been called,
> because that workqueue is queued behind rport a's workqueue and rport
> b's workqueue function is not called? If so, have you tested this with
> the current upstream kernel?
>
Yes, this has been tested with upstream kernel.