[EMAIL PROTECTED] wrote: > From: Mike Christie <[EMAIL PROTECTED]> > > The timer_pending check is broken in fc_fcp.c, because if the > timer function is running there is no timer_pending. If that > timer function is just trying to grab the pkt lock, then > fc_io_compl (which has the lock) would see no timer pending, > and free the pkt from under the timer function. We just > want to call del_timer_sync in this case. > > This patch also removes the fc_fcp_complete del_timer_sync > since it is a dup of what fc_io_compl does. And this > patch fixes the refcounting for when we drop the pkt > lock to call del_timer_sync. We must take a ref in > case the lun reset code were to clean us up or if > the timeout code were killing the command we then we > got a response we could hit the same problem. > > Patch was made over > libfc: remove shared tag map and fix timer usage in fc_fcp.c (take 2) > > This patch is not tested. I am having hardware troubles, and only > have a laptop (has anyone run stgt and the initiator on the same box > and do you have to use aliases or something to get it to work?) > I will have a new target box soon but will not be done for day or so > > The patch is small and we hit this code patch already > (normally when a command is completed the fsp->timer is not > running (it is pending) so we go down the del_timer_sync path), so > I think it should be ok, But do a simple IO test to make sure if you > merge before I can test. >
Forget this patch. I do not think it is going to do what I thought if del_timer_sync is called from a timer function. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
