1. 05 12月, 2009 7 次提交
  2. 22 10月, 2009 1 次提交
  3. 02 10月, 2009 3 次提交
    • C
      [SCSI] zfcp: Fix hang when offlining device with offline chpid · d74cf7c3
      Christof Schmitt 提交于
      Running chchp --vary 0 and chccwdev -d on a FCP device with scsi
      devices attached can lead to this thread hanging:
      
      ================================================================
      STACK TRACE FOR TASK: 0x2fbfcc00 (kslowcrw)
      
       STACK:
       0 schedule+1136 [0x45f99c]
       1 schedule_timeout+534 [0x46054e]
       2 wait_for_common+374 [0x45f442]
       3 blk_execute_rq+160 [0x217a2c]
       4 scsi_execute+278 [0x26daf2]
       5 scsi_execute_req+150 [0x26dc86]
       6 sd_sync_cache+138 [0x28460a]
       7 sd_shutdown+130 [0x28486a]
       8 sd_remove+104 [0x284c84]
       9 __device_release_driver+152 [0x257430]
      10 device_release_driver+56 [0x2575c8]
      11 bus_remove_device+214 [0x25672a]
      12 device_del+352 [0x25456c]
      13 __scsi_remove_device+108 [0x272630]
      14 scsi_remove_device+66 [0x2726ba]
      15 zfcp_ccw_remove+824 [0x335558]
      16 ccw_device_remove+62 [0x2b3f2a]
      17 __device_release_driver+152 [0x257430]
      18 device_release_driver+56 [0x2575c8]
      19 bus_remove_device+214 [0x25672a]
      20 device_del+352 [0x25456c]
      21 ccw_device_unregister+92 [0x2b48c4]
      22 io_subchannel_remove+108 [0x2b4950]
      23 css_remove+62 [0x2af7ee]
      24 __device_release_driver+152 [0x257430]
      25 device_release_driver+56 [0x2575c8]
      26 bus_remove_device+214 [0x25672a]
      27 device_del+352 [0x25456c]
      28 device_unregister+38 [0x25464a]
      29 css_sch_device_unregister+68 [0x2af97c]
      30 ccw_device_call_sch_unregister+78 [0x2b581e]
      31 worker_thread+604 [0x69eb0]
      32 kthread+154 [0x6ff42]
      33 kernel_thread_starter+6 [0x1c952]
      ================================================================
      
      The problem is that the chchp --vary 0 leads to zfcp first calling
      fc_remote_port_delete which blocks all scsi devices on the remote
      port. Calling scsi_remove_device later lets the sd driver issue a
      SYNCHRONIZE_CACHE command. This command stays on the "stopped" request
      requeue because the SCSI device is blocked. Fix this by first removing
      the scsi and fc hosts which removes all scsi devices and do not use
      scsi_remove_device.
      Reviewed-by: NFelix Beck <felix.beck@de.ibm.com>
      Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      d74cf7c3
    • C
      [SCSI] zfcp: Fix lockdep warning when offlining device with offline chpid · f45a5421
      Christof Schmitt 提交于
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.31-39.x.20090917-s390xdefault #1
      -------------------------------------------------------
      kslowcrw/83 is trying to acquire lock:
       (&adapter->scan_work){+.+.+.}, at: [<0000000000169c5c>] __cancel_work_timer+0x64/0x3d4
      
      but task is already holding lock:
       (&zfcp_data.config_mutex){+.+.+.}, at: [<00000000004671ea>] zfcp_ccw_remove+0x66/0x384
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&zfcp_data.config_mutex){+.+.+.}:
             [<0000000000189962>] __lock_acquire+0xe26/0x1834
             [<000000000018a4b6>] lock_acquire+0x146/0x178
             [<000000000058cb5a>] mutex_lock_nested+0x82/0x3ec
             [<0000000000477170>] zfcp_fc_scan_ports+0x3ec/0x728
             [<0000000000168e34>] worker_thread+0x278/0x3a8
             [<000000000016ff08>] kthread+0x9c/0xa4
             [<0000000000109ebe>] kernel_thread_starter+0x6/0xc
             [<0000000000109eb8>] kernel_thread_starter+0x0/0xc
      
      -> #0 (&adapter->scan_work){+.+.+.}:
             [<0000000000189e60>] __lock_acquire+0x1324/0x1834
             [<000000000018a4b6>] lock_acquire+0x146/0x178
             [<0000000000169c9a>] __cancel_work_timer+0xa2/0x3d4
             [<0000000000465cb2>] zfcp_adapter_dequeue+0x32/0x14c
             [<00000000004673e4>] zfcp_ccw_remove+0x260/0x384
             [<00000000004250f6>] ccw_device_remove+0x42/0x1ac
             [<00000000003cb6be>] __device_release_driver+0x9a/0x10c
             [<00000000003cb856>] device_release_driver+0x3a/0x4c
             [<00000000003ca94c>] bus_remove_device+0xcc/0x114
             [<00000000003c8506>] device_del+0x162/0x21c
             [<0000000000425ff2>] ccw_device_unregister+0x5e/0x7c
             [<000000000042607e>] io_subchannel_remove+0x6e/0x9c
             [<000000000041ff9a>] css_remove+0x3e/0x7c
             [<00000000003cb6be>] __device_release_driver+0x9a/0x10c
             [<00000000003cb856>] device_release_driver+0x3a/0x4c
             [<00000000003ca94c>] bus_remove_device+0xcc/0x114
             [<00000000003c8506>] device_del+0x162/0x21c
             [<00000000003c85e8>] device_unregister+0x28/0x38
             [<0000000000420152>] css_sch_device_unregister+0x46/0x58
             [<00000000004276a6>] io_subchannel_sch_event+0x28e/0x794
             [<0000000000420442>] css_evaluate_known_subchannel+0x46/0xd0
             [<0000000000420ebc>] slow_eval_known_fn+0x88/0xa0
             [<00000000003caffa>] bus_for_each_dev+0x7e/0xd0
             [<000000000042188c>] for_each_subchannel_staged+0x6c/0xd4
             [<0000000000421a00>] css_slow_path_func+0x54/0xd8
             [<0000000000168e34>] worker_thread+0x278/0x3a8
             [<000000000016ff08>] kthread+0x9c/0xa4
             [<0000000000109ebe>] kernel_thread_starter+0x6/0xc
             [<0000000000109eb8>] kernel_thread_starter+0x0/0xc
      
      cancel_work_sync is called while holding the config_mutex. But the
      work that is being cancelled or flushed also uses the config_mutex.
      Fix the resulting deadlock possibility by calling cancel_work_sync
      earlier without holding the mutex. The best place to do is is after
      offlining the device.  No new port scan work will be scheduled for the
      offline device, so this is a safe place to call cancel_work_sync.
      Reviewed-by: NFelix Beck <felix.beck@de.ibm.com>
      Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      f45a5421
    • C
      [SCSI] zfcp: Fix initial device and cfdc for delayed adapter allocation · c5afd81e
      Christof Schmitt 提交于
      With the change for delaying the allocation of zfcp_adapter, the
      initial device parameter function has to first call
      ccw_device_set_online which allocates the zfcp_adapter structure.
      Change this and adapt the cfdc part accordingly.
      Reviewed-by: NFelix Beck <felix.beck@de.ibm.com>
      Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      c5afd81e
  4. 05 9月, 2009 16 次提交
  5. 13 6月, 2009 1 次提交
  6. 27 4月, 2009 3 次提交
  7. 13 3月, 2009 7 次提交
  8. 30 12月, 2008 2 次提交