On Wed, 2013-06-12 at 21:25 -0400, Mikulas Patocka wrote: > Hi > > It looks ok. There is a difference - before this patch, > zfcp_erp_adapter_reopen was called without req_q_lock. With this patch, it > is called with the lock held. > > Can it cause any problems? (deadlock, sleep with spinlock or lock > inversion?) I didn't find a case where it could, but I am not familiar > with all the code in this driver. Hi Mikulas, good point! No, it's not an issue. The reopen-functions use the erp_lock. So I have checked all users of req_q_lock - which boils down to a list of functions in zfcp_fsf.c. None of them is called with the erp_lock held. A lot of them might schedule, so they must not be called with any lock held; which makes double-checking faster. Mmh... Another thought that has just crossed my mind: zfcp_qdio_sbal_get() might schedule. It must never be called with any lock held - except for req_q_lock, which is special. So it is absolutely impossible that we deadlock on erp_lock in zfcp_qdio_sbal_get(). Oops, I the additional code reading might have been a waste of time... Thanks, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
