aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSwen Schillig <swen@vnet.ibm.com>2008-10-01 06:42:24 -0400
committerJames Bottomley <James.Bottomley@HansenPartnership.com>2008-10-03 13:11:56 -0400
commit9fb3cd86e4870d54d71a80323e97c48df4de05bd (patch)
treeb03dfde59ef84770511a7cace937bed26c55adb6
parente4e9ba5d9313f362d2192fb7a2d35a3bfb714b1e (diff)
[SCSI] zfcp: fix erp list usage without using locks
The zfcp_erp_thread was using the nolock version of the dbf function. This resulted in a list access while other tasks could modifying the list. The symptom was an erp thread running at 100% CPU and never returning from the dbf function. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
-rw-r--r--drivers/s390/scsi/zfcp_erp.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index 8c117416d5ad..4539530768a2 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -1395,9 +1395,9 @@ static int zfcp_erp_thread(void *data)
1395 zfcp_erp_wakeup(adapter); 1395 zfcp_erp_wakeup(adapter);
1396 } 1396 }
1397 1397
1398 zfcp_rec_dbf_event_thread(4, adapter); 1398 zfcp_rec_dbf_event_thread_lock(4, adapter);
1399 down_interruptible(&adapter->erp_ready_sem); 1399 down_interruptible(&adapter->erp_ready_sem);
1400 zfcp_rec_dbf_event_thread(5, adapter); 1400 zfcp_rec_dbf_event_thread_lock(5, adapter);
1401 } 1401 }
1402 1402
1403 atomic_clear_mask(ZFCP_STATUS_ADAPTER_ERP_THREAD_UP, &adapter->status); 1403 atomic_clear_mask(ZFCP_STATUS_ADAPTER_ERP_THREAD_UP, &adapter->status);