Message ID | DDB9C85B850785449757F9914A034FCB44430852@G9W0766.americas.hpqcorp.net (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
"Seymour, Shane M" <shane.seymour@hp.com> writes: > Two SLES11 SP3 servers encountered similar crashes simultaneously > following some kind of SAN/tape target issue: > Thanks, Reviewed-by: Johannes Thumshirn <jthumshirn@suse.com>
> On 2.7.2015, at 15.01, Seymour, Shane M <shane.seymour@hp.com> wrote: > > > Two SLES11 SP3 servers encountered similar crashes simultaneously > following some kind of SAN/tape target issue: > ... > The crash is fixed by reordering the code so we no longer access > the struct scsi_tape after the kref_put() is done on it in st_open(). > > Signed-off-by: Shane Seymour <shane.seymour@hp.com> > Signed-off-by: Darren Lavender <darren.lavender@hp.com> Acked-by: Kai Mäkisara <kai.makisara@kolumbus.fi> Thanks for finding this. No code should touch an object after put(). Thanks, Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/drivers/scsi/st.c 2015-06-25 15:52:15.728031313 -0500 +++ b/drivers/scsi/st.c 2015-07-01 15:10:49.584360250 -0500 @@ -1329,9 +1329,9 @@ static int st_open(struct inode *inode, spin_lock(&st_use_lock); STp->in_use = 0; spin_unlock(&st_use_lock); - scsi_tape_put(STp); if (resumed) scsi_autopm_put_device(STp->device); + scsi_tape_put(STp); return retval; }