Files
rockchip-kernel/include/linux
Martin Peschke d79ff14262 [SCSI] zfcp: fix lock imbalance by reworking request queue locking
This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
straight-forward descendant of wait_event_interruptible_timeout() and
wait_event_interruptible_lock_irq().

The zfcp driver used to call wait_event_interruptible_timeout()
in combination with some intricate and error-prone locking. Using
wait_event_interruptible_lock_irq_timeout() as a replacement
nicely cleans up that locking.

This rework removes a situation that resulted in a locking imbalance
in zfcp_qdio_sbal_get():

BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
    last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]

It was introduced by commit c2af7545aa
"[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
without a required lock being held. The problem occured when a
special, non-SCSI I/O request was being submitted in process context,
when the adapter's queues had been torn down. In this case the bug
surfaced when the Fibre Channel port connection for a well-known address
was closed during a concurrent adapter shut-down procedure, which is a
rare constellation.

This patch also fixes these warnings from the sparse tool (make C=1):

drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
 'zfcp_qdio_sbal_check' - wrong count at exit
drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
 'zfcp_qdio_sbal_get' - unexpected unlock

Last but not least, we get rid of that crappy lock-unlock-lock
sequence at the beginning of the critical section.

It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.

Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org #2.6.35+
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2013-08-22 08:53:30 -07:00
..
2013-06-27 13:42:16 -04:00
2013-03-01 13:39:00 -08:00
2013-06-17 14:38:54 -04:00
2013-05-07 19:46:02 -07:00
2013-05-29 15:50:34 -04:00
2013-04-29 15:40:23 -04:00
2013-07-03 16:07:39 -07:00
2013-03-22 15:18:18 -07:00
2013-03-12 11:30:04 -07:00
2013-07-10 23:41:18 +01:00
2013-05-01 16:36:22 +05:30
2013-07-23 16:01:28 -07:00
2013-02-26 02:46:08 -05:00
2013-05-07 18:38:27 -07:00
2013-03-15 15:09:43 +10:30
2013-04-29 18:28:40 -07:00
2013-06-17 16:38:57 -07:00
2013-06-19 23:32:07 -04:00
2013-06-10 13:45:49 -07:00
2013-05-06 13:07:33 +02:00
2013-07-03 16:07:32 -07:00
2013-06-13 17:51:04 -07:00
2013-07-18 13:05:23 -07:00
2013-06-17 16:38:57 -07:00
2013-04-30 17:04:06 -07:00
2013-04-01 11:04:50 -07:00
2013-07-16 22:00:14 -07:00
2013-07-09 10:33:30 -07:00
2013-05-31 00:48:22 -07:00
2013-07-10 18:11:34 -07:00
2013-03-15 15:09:43 +10:30
2013-07-02 15:38:19 +09:30
2013-07-03 16:08:05 -07:00
2013-06-08 16:20:14 -04:00
2013-05-04 14:47:26 -04:00
2013-06-12 12:37:40 +01:00
2013-06-12 12:37:30 +01:00
2013-04-29 15:54:28 -07:00
2013-06-26 15:55:52 -06:00
2013-06-26 21:10:05 +02:00
2013-05-31 17:19:05 -07:00
2013-06-21 11:32:51 +02:00
2013-04-29 15:54:28 -07:00
2013-04-12 10:26:23 +02:00
2013-07-03 16:08:05 -07:00
2013-06-17 16:38:57 -07:00
2013-02-19 08:43:34 +01:00
2013-06-17 18:09:53 +09:00
2013-03-29 15:31:30 -04:00
2013-06-20 13:08:01 -07:00
2013-04-30 15:50:12 +05:30
2013-05-21 12:25:02 -05:00
2013-03-20 12:10:38 -04:00
2013-04-29 15:54:37 -07:00
2013-05-27 10:57:53 +09:00
2013-07-10 18:11:34 -07:00