Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 153
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 09 10月, 2008 1 次提交
  3. 04 10月, 2008 1 次提交
  5. 27 7月, 2008 1 次提交
  7. 22 7月, 2008 1 次提交
  9. 28 4月, 2008 1 次提交
  11. 20 4月, 2008 1 次提交
  13. 12 1月, 2008 1 次提交
  15. 13 10月, 2007 3 次提交
  17. 19 7月, 2007 1 次提交
  19. 18 6月, 2007 1 次提交
  21. 27 5月, 2007 1 次提交
  23. 16 5月, 2007 1 次提交
    • J
      [SCSI] FC Transport support for vports based on NPIV · a53eb5e0
      由 James Smart 提交于 
      This patch provides support for FC virtual ports based on NPIV.
For information on the interfaces and design, please read the
Documentation/scsi/scsi_fc_transport.txt file enclosed within
the patch.

The RFC was originally posted here:
http://marc.info/?l=linux-scsi&m=117226959918393&w=2

Changes from the initial RFC:
- Bug fix: needed a transport_class_unregister() for the vport class
- Create a symlink to the vport in the shost device if it is not the
    parent of the vport.
- Made symbolic name writable so it can be set after creation
- Made the temporary fc_vport_identifiers struct private to the
transport.
- Deleted the vport_id field from the vport. I couldn't find any good
  use for it (and symname is a good replacement).
- Made the vport_state and vport_last_state "private" attributes.
  Added the fc_vport_set_state() helper function to manage state
  transitions
- Updated vport_create() to allow a vport to be created in a disabled
  state.
- Added INITIALIZING and FAILED vport states
- Added VPCERR_xxx defines for errors to be returned from vport_create()
- Created a Documentation/scsi/scsi_fc_transport.txt file that describes
  the interfaces and expected LLDD behaviors.
Signed-off-by: NJames Smart <James.Smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a53eb5e0
  25. 06 5月, 2007 1 次提交
    • J
      [SCSI] fc_transport: make all rports wait dev_loss_tmo before removing them · 92740b24
      由 James Smart 提交于 
      Per the comment in the change - it's not always prudent to immediately
remove the rport upon first notice of a disconnect. Make all rports
wait dev_loss_tmo before being deleted (and each could have a separate
dev_loss_tmo value).

The original post was:
http://marc.info/?l=linux-scsi&m=117392196006703&w=2

The repost contains the following changes:
 - Bug fix in fc_starget_delete(). Dev_loss_tmo_callbk() was called prior to
   tearing down the target. The callback is to be the last thing called, as
   it tells the LLDD that the rport is completely finished and can be torn
   down.  Rework so that terminate_rport_io() is called to terminate the
   outstanding io. Isolated work so it's is simply "starget" work.
 - Fix holes in original patch. There were code paths that did not expect
   the dev_loss_tmo timer to be running for the non-fcp rports.
 - Bug Fix: the transport wasn't protecting against a LLDD calling
   fc_remote_port_delete() back-to-back. Thus, the dev_loss_tmo timer
   could be restarted such that it fires after the rport had been deleted.
   Validate rport state before starting the timer.
Signed-off-by: NJames Smart <James.Smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      92740b24
  27. 20 3月, 2007 1 次提交
  29. 18 2月, 2007 1 次提交
  31. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      由 Tim Schmielau 提交于 
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there.  Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.

To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm.  I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  33. 22 11月, 2006 1 次提交
  35. 24 9月, 2006 1 次提交
  37. 05 9月, 2006 1 次提交
  39. 03 9月, 2006 2 次提交
  41. 20 8月, 2006 2 次提交
  43. 28 6月, 2006 1 次提交
    • J
      [SCSI] fc transport: bug fix: correct references · 3bdad7bd
      由 James Smart 提交于 
      Original post was incorrect as it didn't realize that we already had
a self-referenc due to device_initialize(), and we were really only
missing the put on our own reference. This was hidden by the other bug
which had the midlayer reusing stargets after they were already free,
which was doing too many puts on our rport.

Updating FC transport for:
- Add put in fc_rport_final_delete(), to release the rport.
  Prior, we were leaving the rport with a reference, thus the shost
  with references, etc. If the driver was unloaded, shosts and rports
  remained, along with work threads, etc
- Fix fc_rport_create failure path - too many put's on parent
- Add commenting to easily track ref taking.
Signed-off-by: NJames Smart <james.smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      3bdad7bd
  45. 27 6月, 2006 2 次提交
    • J
      [SCSI] update max sdev block limit · 1c9e16e4
      由 James Smart 提交于 
      Updated patch to address comments from Pat Mansfield and Michael Reed:
Bumped max to 600 (10mins). Set default dev_loss_tmo to a value other
than the max (30s).
Signed-off-by: NJames Smart <James.Smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      1c9e16e4
    • J
      [SCSI] fc transport: resolve scan vs delete deadlocks · a0785edf
      由 James Smart 提交于 
      In a prior posting to linux-scsi on the fc transport and workq
deadlocks, we noted a second error that did not have a patch:
  http://marc.theaimsgroup.com/?l=linux-scsi&m=114467847711383&w=2
  - There's a deadlock where scsi_remove_target() has to sit behind
    scsi_scan_target() due to contention over the scan_lock().

Subsequently we posted a request for comments about the deadlock:
  http://marc.theaimsgroup.com/?l=linux-scsi&m=114469358829500&w=2

This posting resolves the second error. Here's what we now understand,
and are implementing:

  If the lldd deletes the rport while a scan is active, the sdev's queue
  is blocked which stops the issuing of commands associated with the scan.
  At this point, the scan stalls, and does so with the shost->scan_mutex held.
  If, at this point, if any scan or delete request is made on the host, it
  will stall waiting for the scan_mutex.

  For the FC transport, we queue all delete work to a single workq.
  So, things worked fine when competing with the scan, as long as the
  target blocking the scan was the same target at the top of our delete
  workq, as the delete workq routine always unblocked just prior to
  requesting the delete.  Unfortunately, if the top of our delete workq
  was for a different target, we deadlock.  Additionally, if the target
  blocking scan returned, we were unblocking it in the scan workq routine,
  which really won't execute until the existing stalled scan workq
  completes (e.g. we're re-scheduling it while it is in the midst of its
  execution).

  This patch moves the unblock out of the workq routines and moves it to
  the context that is scheduling the work. This ensures that at some point,
  we will unblock the target that is blocking scan.  Please note, however,
  that the deadlock condition may still occur while it waits for the
  transport to timeout an unblock on a target.  Worst case, this is bounded
  by the transport dev_loss_tmo (default: 30 seconds).

Finally, Michael Reed deserves the credit for the bulk of this patch,
analysis, and it's testing. Thank you for your help.

Note: The request for comments statements about the gross-ness of the
  scan_mutex still stand.
Signed-off-by: NMichael Reed <mdr@sgi.com>
Signed-off-by: NJames Smart <james.smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a0785edf
  47. 10 6月, 2006 1 次提交
  49. 14 4月, 2006 1 次提交
    • J
      [SCSI] FC transport: fixes for workq deadlocks · aedf3497
      由 James Smart 提交于 
      As previously reported via Michael Reed, the FC transport took a hit
in 2.6.15 (perhaps a little earlier) when we solved a recursion error.
There are 2 deadlocks occurring:
- With scan and the delete items sharing the same workq, flushing the
  workq for the delete code was getting it stalled behind a very long
  running scan code path.
- There's a deadlock where scsi_remove_target() has to sit behind
  scsi_scan_target() due to contention over the scan_lock().

This patch resolves the 1st deadlock and significantly reduces the
odds of the second. So far, we have only replicated the 2nd deadlock
on a highly-parallel SMP system. More on the 2nd deadlock in a following
email.

This patch reworks the transport to:
- Only use the scsi host workq for scanning
- Use 2 other workq's internally. One for deletions, the other for
  scheduled deletions. Originally, we tried this with a single workq,
  but the occassional flushes of the scheduled queues was hitting the
  second deadlock with a slightly higher frequency. In the future, we'll
  look at the LLDD's and the transport to see if we can get rid of this
  extra overhead.
- When moving to the other workq's we tightened up some object states
  and some lock handling.
- Properly syncs adds/deletes
- minor code cleanups
  - directly reference fc_host_attrs, rather than through attribute
    macros
  - flush the right workq on delayed work cancel failures.

Large kudos to Michael Reed who has been working this issue for the last
month.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      aedf3497
  51. 13 3月, 2006 1 次提交
  53. 10 3月, 2006 1 次提交
  55. 28 2月, 2006 2 次提交
  57. 15 1月, 2006 2 次提交
    • C
      [SCSI] remove target parent limitiation · e02f3f59
      由 Christoph Hellwig 提交于 
      When James Smart fixed the issue of the userspace scan atributes
crashing the system with the FC transport class he added a patch to
let the transport class check if the parent is valid for a given
transport class.

When adding support for the integrated raid of fusion sas devices
we ran into a problem with that, as it didn't allow adding virtual
raid volumes without the transport class knowing about it.

So this patch adds a user_scan attribute instead, that takes over from
scsi_scan_host_selected if the transport class sets it and thus lets
the transport class control the user-initiated scanning.  As this
plugs the hole about user-initiated scanning the target_parent hook
goes away and we rely on callers of the scanning routines to do
something sensible.

For SAS this meant I had to switch from a spinlock to a mutex to
synchronize the topology linked lists, in FC they were completely
unsynchronized which seems wrong.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      e02f3f59
    • A
      [SCSI] fc transport: add permanent_port_name fc_host attribute · 6b7281d0
      由 Andreas Herrmann 提交于 
      Add fc_host attribute permanent_port_name which is
used to show the port name of the primary port -
the port that initially logged into the fabric.

For a virtual port (registered via the primary port with
FDISC command) it is useful to know not only its (virtual)
port name but also the permanent port name.
Signed-off-by: NAndreas Herrmann <aherrman@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      6b7281d0
  59. 16 12月, 2005 1 次提交
    • J
      [SCSI] fix for fc transport recursion problem. · 42e33148
      由 James.Smart@Emulex.Com 提交于 
      In the scenario that a link was broken, the devloss timer for each
rport was expire at roughly the same time, causing lots of "delete"
workqueue items being queued. Depth is dependent upon the number of
rports that were on the link.

The rport target remove calls were calling flush_scheduled_work(),
which would interrupt the stream, and start the next workqueue item,
which did the same thing, and so on until recursion depth was large.

This fix stops the recursion in the initial delete path, and pushes it
off to a host-level work item that reaps the dead rports.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      42e33148
  61. 14 12月, 2005 1 次提交
  63. 31 10月, 2005 1 次提交
    • T
      [PATCH] fix missing includes · 4e57b681
      由 Tim Schmielau 提交于 
      I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.

In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch.  This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other.  So if any
hunk rejects or gets in the way of other patches, just drop it.  My scripts
will pick it up again in the next round.
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4e57b681
  65. 29 10月, 2005 1 次提交
    • J
      [SCSI] update fc_transport for removal of block/unblock functions · 19a7b4ae
      由 James.Smart@Emulex.Com 提交于 
      We recently went back to implement a board reset. When we perform the
reset, we wanted to tear down the internal data structures and rebuild
them. Unfortunately, when it came to the rport structure, things were
odd. If we deleted them, the scsi targets and sdevs would be
torn down. Not a good thing for a temporary reset. We could block the
rports, but we either maintain the internal structures to keep the
rport reference (perhaps even replicating what's in the transport),
or we have to fatten the fc transport with new search routines to find
the rport (and deal with a case of a dangling rport that the driver
forgets).

It dawned on me that we had actually reached this state incorrectly.
When the fc transport first started, we did the block/unblock first, then
added the rport interface. The purpose of block/unblock is to hide the
temporary disappearance of the rport (e.g. being deleted, then readded).
Why are we making the driver do the block/unblock ? We should be making
the transport have only an rport add/delete, and the let the transport
handle the block/unblock.

So... This patch removes the existing fc_remote_port_block/unblock
functions. It moves the block/unblock functionality into the
fc_remote_port_add/delete functions.  Updates for the lpfc driver are
included. Qlogic driver updates are also enclosed, thanks to the
contributions of Andrew Vasquez. [Note: the qla2xxx changes are
relative to the scsi-misc-2.6 tree as of this morning - which does
not include the recent patches sent by Andrew]. The zfcp driver does
not use the block/unblock functions.

One last comment: The resulting behavior feels very clean. The LLDD is
concerned only with add/delete, which corresponds to the physical
disappearance.  However, the fact that the scsi target and sdevs are
not immediately torn down after the LLDD calls delete causes an
interesting scenario... the midlayer can call the xxx_slave_alloc and
xxx_queuecommand functions with a sdev that is at the location the
rport used to be. The driver must validate the device exists when it
first enters these functions. In thinking about it, this has always
been the case for the LLDD and these routines. The existing drivers
already check for existence. However, this highlights that simple
validation via data structure dereferencing needs to be watched.
To deal with this, a new transport function, fc_remote_port_chkready()
was created that LLDDs should call when they first enter these two
routines. It validates the rport state, and returns a scsi result
which could be returned. In addition to solving the above, it also
creates consistent behavior from the LLDD's when the block and deletes
are occuring.

Rejections fixed up and
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      19a7b4ae