aboutsummaryrefslogtreecommitdiff
path: root/include/scsi
diff options
context:
space:
mode:
authorVasu Dev <vasu.dev@intel.com>2010-10-08 17:12:31 -0700
committerJames Bottomley <James.Bottomley@suse.de>2010-10-25 15:11:35 -0500
commit8b7ac2bb07bbadb0636f21f51564e6d363bb6d20 (patch)
tree788c08b32a719f6c473482e7897ec5835dd9e03e /include/scsi
parent3067817a5d3ef99c5b1a4e4ca8c5b15bc7fc468d (diff)
[SCSI] libfc: possible race could panic system due to NULL fsp->cmd
It is unlikely but in case if it hits then it would cause panic due to null cmd ptr, so far only one instance seen recently with ESX though this was introduced long ago with this commit:- commit c1ecb90a66c5afc7cc5c9349f9c3714eef4a5cfb Author: Chris Leech <christopher.leech@intel.com> Date: Thu Dec 10 09:59:26 2009 -0800 [SCSI] libfc: reduce hold time on SCSI host lock Currently fsp->cmd is set to NULL w/o scsi_queue_lock before dequeuing from scsi_pkt_queue and that could cause NULL fsp->cmd in fc_fcp_cleanup_each_cmd for cmd completing with fsp->cmd = NULL after fc_fcp_cleanup_each_cmd taken reference. No need to set fsp->cmd to NULL as this is also protected by fc_fcp_lock_pkt(), for above race the fc_fcp_lock_pkt() in fc_fcp_cleanup_each_cmd() will fail as that cmd is already done. Mike mentioned same issue at http://www.open-fcoe.org/pipermail/devel/2010-September/010533.html Similarly moved sc_cmd->SCp.ptr = NULL under scsi_queue_lock so that scsi abort error handler won't abort on completed cmds. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Diffstat (limited to 'include/scsi')
0 files changed, 0 insertions, 0 deletions