Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 6月, 2009 1 次提交
    • C
      [SCSI] FC transport: Locking fix for common-code FC pass-through patch · 39562e78
      由 Christof Schmitt 提交于 
      Fix this:
------------[ cut here ]------------
Badness at block/blk-core.c:244
CPU: 0 Tainted: G        W  2.6.31-rc1-00004-gd3a263a8 #3
Process zfcp_wq (pid: 901, task: 000000002fb7a038, ksp: 000000002f02bc78)
Krnl PSW : 0704300180000000 00000000002141ba (blk_remove_plug+0xb2/0xb8)
           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000001 0000000022811440 0000000022811798
           000000000027ff4e 0000000000000000 0000000000000000 000000002f00f000
           070000000006a0f4 000000002af70000 000000002af2a800 00000000228d1c00
           0000000022811440 000000000050c708 000000002f02bca8 000000002f02bc80
Krnl Code: 00000000002141b0: b9140022		lgfr	%r2,%r2
           00000000002141b4: 07fe		bcr	15,%r14
           00000000002141b6: a7f40001		brc	15,2141b8
          >00000000002141ba: a7f4ffbe		brc	15,214136
           00000000002141be: 0707		bcr	0,%r7
           00000000002141c0: ebaff0680024	stmg %r10,%r15,104(%r15)
           00000000002141c6: c0d00017c2a9	larl	%r13,50c718
           00000000002141cc: a7f13fc0		tmll	%r15,16320
Call Trace:
([<000000000050e7d8>] C.272.16122+0x88/0x110)
 [<00000000002141ec>] __blk_run_queue+0x2c/0x154
 [<000000000028013a>] fc_remote_port_add+0x85e/0x95c
 [<000000000037596e>] zfcp_scsi_rport_work+0xe6/0x148
 [<000000000006908c>] worker_thread+0x25c/0x318
 [<000000000006f10c>] kthread+0x94/0x9c
 [<000000000001c2b2>] kernel_thread_starter+0x6/0xc
 [<000000000001c2ac>] kernel_thread_starter+0x0/0xc
INFO: lockdep is turned off.
Last Breaking-Event-Address:
 [<00000000002141b6>] blk_remove_plug+0xae/0xb8

The FC pass-through support triggers the WARN_ON(!irqs_disabled()) in
blk_plug_device. Since blk_plug_device requires being called with
disabled interrupts, use spin_lock_irqsave in fc_bsg_goose_queue to
disable the interrupts before calling into the block layer.
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Acked-by: NJames Smart <james.smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      39562e78
  3. 22 6月, 2009 3 次提交
  5. 13 6月, 2009 1 次提交
    • J
      [SCSI] FC Pass Thru support · 9e4f5e29
      由 James Smart 提交于 
      Attached is the ELS/CT pass-thru patch for the FC Transport. The patch
creates a generic framework that lays on top of bsg and the SGIO v4 ioctl
in order to pass transaction requests to LLDD's.

The interface supports the following operations:
  On an fc_host basis:
    Request login to the specified N_Port_ID, creating an fc_rport.
    Request logout of the specified N_Port_ID, deleting an fc_rport
    Send ELS request to specified N_Port_ID w/o requiring a login, and
      wait for ELS response.
    Send CT request to specified N_Port_ID and wait for CT response.
      Login is required, but LLDD is allowed to manage login and decide
      whether it stays in place after the request is satisfied.
    Vendor-Unique request. Allows a LLDD-specific request to be passed
      to the LLDD, and the passing of a response back to the application.
  On an fc_rport basis:
    Send ELS request to nport and wait for ELS response.
    Send CT request to nport and wait for CT response.

The patch also exports several headers from include/scsi such that
they can be available to user-space applications:
  include/scsi/scsi.h
  include/scsi/scsi_netlink.h
  include/scsi/scsi_netlink_fc.h
  include/scsi/scsi_bsg_fc.h

For further information, refer to the last RFC:
http://marc.info/?l=linux-scsi&m=123436574018579&w=2

Note: Documentation is still spotty and will be added later.

[bharrosh@panasas.com: update for new block API]
Signed-off-by: NJames Smart <james.smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      9e4f5e29
  7. 13 3月, 2009 1 次提交
  9. 06 2月, 2009 1 次提交
    • P
      netlink: change return-value logic of netlink_broadcast() · ff491a73
      由 Pablo Neira Ayuso 提交于 
      Currently, netlink_broadcast() reports errors to the caller if no
messages at all were delivered:

1) If, at least, one message has been delivered correctly, returns 0.
2) Otherwise, if no messages at all were delivered due to skb_clone()
   failure, return -ENOBUFS.
3) Otherwise, if there are no listeners, return -ESRCH.

With this patch, the caller knows if the delivery of any of the
messages to the listeners have failed:

1) If it fails to deliver any message (for whatever reason), return
   -ENOBUFS.
2) Otherwise, if all messages were delivered OK, returns 0.
3) Otherwise, if no listeners, return -ESRCH.

In the current ctnetlink code and in Netfilter in general, we can add
reliable logging and connection tracking event delivery by dropping the
packets whose events were not successfully delivered over Netlink. Of
course, this option would be settable via /proc as this approach reduces
performance (in terms of filtered connections per seconds by a stateful
firewall) but providing reliable logging and event delivery (for
conntrackd) in return.

This patch also changes some clients of netlink_broadcast() that
may report ENOBUFS errors via printk. This error handling is not
of any help. Instead, the userspace daemons that are listening to
those netlink messages should resync themselves with the kernel-side
if they hit ENOBUFS.

BTW, netlink_broadcast() clients include those that call
cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
internally call netlink_broadcast() and return its error value.
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff491a73
  11. 06 1月, 2009 1 次提交
  13. 03 1月, 2009 1 次提交
  15. 30 12月, 2008 1 次提交
  17. 13 10月, 2008 1 次提交
    • M
      [SCSI] fc class: unblock target after calling terminate callback (take 2) · fff9d40c
      由 Mike Christie 提交于 
      When we block a rport and the driver implements the terminate
callback we will fail IO that was running quickly. However
IO that was in the scsi_device/block queue sits there until
the dev_loss_tmo fires, and this can make it look like IO is
lost because new IO will get executed but that IO stuck in
the blocked queue sits there for some time longer.

With this patch when the fast io fail tmo fires, we will
fail the blocked IO and any new IO. This patch also allows
all drivers to partially support the fast io fail tmo. If the
terminate io callback is not implemented, we will still fail blocked
IO and any new IO, so multipath can handle that.

This patch also allows the fc and iscsi classes to implement the
same behavior. The timers are just unfornately named differently.

This patch also fixes the problem where drivers were unblocking
the target in their terminate callback, which was needed for
rport removal, but for fast io fail timeout it would cause
IO to bounce arround the scsi/block layer and the LLD queuecommand.
And it for drivers that could have IO stuck but did not have
a terminate callback the unblock calls in the class will fix
them.

v2.
- fix up bit setting style to meet JamesS's pref.
- Broke out new host byte error changes to make it easier to read.
- added JamesS's ack from list.
v1
- initial patch
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Acked-by: NJames Smart <James.Smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      fff9d40c
  19. 09 10月, 2008 1 次提交
  21. 04 10月, 2008 1 次提交
  23. 27 7月, 2008 1 次提交
  25. 22 7月, 2008 1 次提交
  27. 28 4月, 2008 1 次提交
  29. 20 4月, 2008 1 次提交
  31. 12 1月, 2008 1 次提交
  33. 13 10月, 2007 3 次提交
  35. 19 7月, 2007 1 次提交
  37. 18 6月, 2007 1 次提交
  39. 27 5月, 2007 1 次提交
  41. 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
  43. 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
  45. 20 3月, 2007 1 次提交
  47. 18 2月, 2007 1 次提交
  49. 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
  51. 22 11月, 2006 1 次提交
  53. 24 9月, 2006 1 次提交
  55. 05 9月, 2006 1 次提交
  57. 03 9月, 2006 2 次提交
  59. 20 8月, 2006 2 次提交
  61. 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
  63. 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
  65. 10 6月, 2006 1 次提交