Re: deadlock during fc_remove_host

[Mike Christie <michaelc@cs.wisc.edu>]

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?