1. 20 11月, 2013 1 次提交
  2. 15 11月, 2013 6 次提交
  3. 09 11月, 2013 1 次提交
  4. 07 11月, 2013 1 次提交
  5. 06 11月, 2013 1 次提交
  6. 29 10月, 2013 1 次提交
  7. 28 10月, 2013 1 次提交
  8. 24 10月, 2013 8 次提交
  9. 22 10月, 2013 1 次提交
    • M
      s390/time: correct use of store clock fast · 8c071b0f
      Martin Schwidefsky 提交于
      The result of the store-clock-fast (STCKF) instruction is a bit fuzzy.
      It can happen that the value stored on one CPU is smaller than the value
      stored on another CPU, although the order of the stores is the other
      way around. This can cause deltas of get_tod_clock() values to become
      negative when they should not be.
      
      We need to be more careful with store-clock-fast, this patch partially
      reverts git commit e4b7b4238e666682555461fa52eecd74652f36bb "time:
      always use stckf instead of stck if available". The get_tod_clock()
      function now uses the store-clock-extended (STCKE) instruction.
      get_tod_clock_fast() can be used if the fuzziness of store-clock-fast
      is acceptable e.g. for wait loops local to a CPU.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8c071b0f
  10. 15 10月, 2013 2 次提交
  11. 14 10月, 2013 1 次提交
  12. 30 9月, 2013 2 次提交
  13. 12 9月, 2013 1 次提交
  14. 07 9月, 2013 2 次提交
  15. 04 9月, 2013 1 次提交
  16. 03 9月, 2013 4 次提交
  17. 30 8月, 2013 2 次提交
  18. 28 8月, 2013 1 次提交
  19. 23 8月, 2013 2 次提交
    • M
      [SCSI] zfcp: remove access control tables interface (keep sysfs files) · b5dc3c48
      Martin Peschke 提交于
      By popular demand, this patch brings back a couple of sysfs attributes
      removed by commit 663e0890
      "[SCSI] zfcp: remove access control tables interface".
      The content has been irrelevant for years, but the files must be
      there forever for whatever user space tools that may rely on them.
      
      Since these files always return a constant value, a new stripped
      down show-macro was required. Otherwise build warnings would have
      been introduced.
      Signed-off-by: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      b5dc3c48
    • M
      [SCSI] zfcp: fix schedule-inside-lock in scsi_device list loops · 924dd584
      Martin Peschke 提交于
      BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
      in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
      CPU: 1 Not tainted 3.9.3+ #69
      Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30)
      <snip>
      Call Trace:
      ([<00000000001165de>] show_trace+0x106/0x154)
       [<00000000001166a0>] show_stack+0x74/0xf4
       [<00000000006ff646>] dump_stack+0xc6/0xd4
       [<000000000017f3a0>] __might_sleep+0x128/0x148
       [<000000000015ece8>] flush_work+0x54/0x1f8
       [<00000000001630de>] __cancel_work_timer+0xc6/0x128
       [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
       [<0000000000161816>] execute_in_process_context+0x96/0xa8
       [<00000000004d33d8>] device_release+0x60/0xc0
       [<000000000048af48>] kobject_release+0xa8/0x1c4
       [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130
       [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
       [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
       [<000000000016b75a>] kthread+0xf2/0xfc
       [<000000000070c9de>] kernel_thread_starter+0x6/0xc
       [<000000000070c9d8>] kernel_thread_starter+0x0/0xc
      
      Apparently, the ref_count for some scsi_device drops down to zero,
      triggering device removal through execute_in_process_context(), while
      the lldd error recovery thread iterates through a scsi device list.
      Unfortunately, execute_in_process_context() decides to immediately
      execute that device removal function, instead of scheduling asynchronous
      execution, since it detects process context and thinks it is safe to do
      so. But almost all calls to shost_for_each_device() in our lldd are
      inside spin_lock_irq, even in thread context. Obviously, schedule()
      inside spin_lock_irq sections is a bad idea.
      
      Change the lldd to use the proper iterator function,
      __shost_for_each_device(), in combination with required locking.
      
      Occurences that need to be changed include all calls in zfcp_erp.c,
      since those might be executed in zfcp error recovery thread context
      with a lock held.
      
      Other occurences of shost_for_each_device() in zfcp_fsf.c do not
      need to be changed (no process context, no surrounding locking).
      
      The problem was introduced in Linux 2.6.37 by commit
      b62a8d9b
      "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".
      Reported-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.37+
      Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      924dd584
  20. 22 8月, 2013 1 次提交
    • M
      [SCSI] zfcp: fix lock imbalance by reworking request queue locking · d79ff142
      Martin Peschke 提交于
      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 c2af7545
      "[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: NMikulas Patocka <mpatocka@redhat.com>
      Reported-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org #2.6.35+
      Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      d79ff142