Hi Bastien, On Wed, Apr 6, 2016 at 7:19 AM, Bastien Philbert <bastienphilbert@xxxxxxxxx> wrote: > This fixes backwards locking in the function __csio_unreg_rnode to > properly lock before the call to the function csio_unreg_rnode and > not unlock with spin_unlock_irq as this would not allow the proper > protection for concurrent access on the shared csio_hw structure > pointer hw. In addition switch the locking after the critical region > function call to properly unlock instead with spin_unlock_irq on > > Signed-off-by: Bastien Philbert <bastienphilbert@xxxxxxxxx> > --- > drivers/scsi/csiostor/csio_rnode.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/csiostor/csio_rnode.c b/drivers/scsi/csiostor/csio_rnode.c > index e9c3b04..029a09e 100644 > --- a/drivers/scsi/csiostor/csio_rnode.c > +++ b/drivers/scsi/csiostor/csio_rnode.c > @@ -580,9 +580,9 @@ __csio_unreg_rnode(struct csio_rnode *rn) > ln->last_scan_ntgts--; > } > > - spin_unlock_irq(&hw->lock); > - csio_unreg_rnode(rn); > spin_lock_irq(&hw->lock); > + csio_unreg_rnode(rn); > + spin_unlock_irq(&hw->lock); Are you _certain_ this is correct? This construct usually appears when a function has a particular lock held, then needs to unlock it to call some other function. Are you _certain_ that this isn't the case? Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
