Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 9月, 2006 10 次提交
    • S
      ieee1394: sbp2: safer agent reset in error handlers · 1f427e80
      由 Stefan Richter 提交于 
      The scsi_host_template's eh_abort_handler and eh_device_reset_handler
are allowed to sleep.  Use this to run sbp2_agent_reset in the more
reliable mode which returns _after_ its write transaction was finished.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      1f427e80
    • S
      ieee1394: sbp2: handle "sbp2util_node_write_no_wait failed" · 09ee67ab
      由 Stefan Richter 提交于 
      Fix for http://bugzilla.kernel.org/show_bug.cgi?id=6948

Because sbp2 writes to the target's fetch agent's registers from within
atomic context, it cannot sleep to guaranteedly get a free transaction
label.  This may repeatedly lead to "sbp2util_node_write_no_wait failed"
and consequently to SCSI command abortion after timeout.  A likely cause
is that many queue_command softirqs may occur before khpsbpkt (the
ieee1394 driver's thread which cleans up after finished transactions) is
woken up to recycle tlabels.

Sbp2 now schedules a workqueue job whenever sbp2_link_orb_command fails
in sbp2util_node_write_no_wait.  The job will reliably get a transaction
label because it can sleep.

We use the kernel-wide shared workqueue because it is unlikely that the
job itself actually needs to sleep.  In the improbable case that it has
to sleep, it doesn't need to sleep long since the standard transaction
timeout is 100ms.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      09ee67ab
    • S
      ieee1394: safer definition of empty macros · 611aa19f
      由 Stefan Richter 提交于 
      A deactivated macro, defined as "#define foo(bar)", will result in
silent corruption if somebody forgets a semicolon after a call to foo.
Replace it by "#define foo(bar) do {} while (0)" which will reveal any
respective syntax errors.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      611aa19f
    • A
      the scheduled removal of drivers/ieee1394/sbp2.c:force_inquiry_hack · a1b3206b
      由 Adrian Bunk 提交于 
      This patch contains the scheduled removal of the force_inquiry_hack
module parameter.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      a1b3206b
    • S
      ieee1394: sbp2: convert sbp2util_down_timeout to waitqueue · e8398bb7
      由 Stefan Richter 提交于 
      The waitqueue API is used to replace a custom wait mechanism.  Only one
global waitqueue (instead of per-device waitqueues or completions) is
added because there is usually just one waiter.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      e8398bb7
    • S
      ieee1394: sbp2: more checks of status block · 6065772d
      由 Stefan Richter 提交于 
       - Add checks for the (very unlikely) cases that the target writes too
   little or too much status data or writes unsolicited status.
 - Indicate that these and similar conditions are unlikely().
 - Check the 'resp' and 'sbp_status' fields for possible failure status.
 - Slightly optimize access macros for the status block bitfields.
 - Unify a few related log messages.

TODO:  Check if 'src'==1, then withhold the respective ORB from reuse
until status for any subsequent ORB was received.  This is an old bug
whose fix requires more complex command queue handling.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      6065772d
    • S
      ieee1394: sbp2: safer initialization of status fifo · 3e98eab4
      由 Stefan Richter 提交于 
      Sbp2's copy of the status fifo was cleared when management ORBs or new
command ORBs were prepared.  The latter had potential for a race
condition if the block layer's soft IRQ and the 1394 LLD's interrupt
handler ran on different CPUs.  It would also yield wrong status if a
command was completed with non-zero completion status before other
commands that had zero completion status, and no new command was
enqueued in the meantime.

Now, the status buffer is cleared right before it is written.  Thus it
ends up in the following simpler and safer access pattern:
 - sbp2_alloc_device: allocates and implicitly clears once,
 - sbp2_handle_status_write: clears, writes, and reads,
 - sbp2_query_logins, sbp2_login_device, sbp2_reconnect_device: read.
The latter three do not race with sbp2_handle_status_write because of
how the protocol works.

As a tiny optimization, the first two quadlets of the status never need
to be cleared.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      3e98eab4
    • S
      ieee1394: sbp2: optimize DMA direction of command ORBs · d4018d7f
      由 Stefan Richter 提交于 
      Only the driver writes ORBs, the device just reads them.  Therefore
PCI_DMA_BIDIRECTIONAL can be replaced by PCI_DMA_TODEVICE which may be
cheaper on some architectures.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      d4018d7f
    • S
      ieee1394: sbp2: discard return value of sbp2_link_orb_command · 28212767
      由 Stefan Richter 提交于 
      Since sbp2 is at the moment unable to do anything with the return value
of sbp2_link_orb_command, just discard it.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      28212767
    • S
      ieee1394: sbp2: safer last_orb and next_ORB handling · cc078189
      由 Stefan Richter 提交于 
      The sbp2 initiator has two ways to tell a target's fetch agent about new
command ORBs:
 - Write the ORB's address to the ORB_POINTER register.  This must not
   be done while the fetch agent is active.
 - Put the ORB's address into the previously submitted ORB's next_ORB
   field and write to the DOORBELL register.  This may be done while the
   fetch agent is active or suspended.  It must not be done while the
   fetch agent is in reset state.
Sbp2 has a last_orb pointer which indicates in what way a new command
should be announced.  That pointer is concurrently accessed at various
occasions.  Furthermore, initiator and target are accessing the next_ORB
field of ORBs concurrently and asynchronously.

This patch does:
 - Protect all initiator accesses to last_orb by sbp2_command_orb_lock.
 - Add pci_dma_sync_single_for_device before a previously submitted
   ORB's next_ORB field is overwritten.
 - Insert a memory barrier between when next_ORB_lo and next_ORB_hi are
   overwritten.  Next_ORB_hi must not be updated before next_ORB_lo.
 - Remove the rather unspecific and now superfluous qualifier "volatile"
   from the next_ORB fields.
 - Add comments on how last_orb is connected with what is known about
   the target's fetch agent's state.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      cc078189
  3. 06 8月, 2006 1 次提交
  5. 04 7月, 2006 2 次提交
  7. 01 7月, 2006 1 次提交
  9. 13 6月, 2006 8 次提交
  11. 06 6月, 2006 1 次提交
  13. 18 5月, 2006 4 次提交
  15. 03 4月, 2006 1 次提交
    • S
      [PATCH] sbp2: fix spinlock recursion · 24c7cd06
      由 Stefan Richter 提交于 
      sbp2util_mark_command_completed takes a lock which was already taken by
sbp2scsi_complete_all_commands.  This is a regression in Linux 2.6.15.

 Reported by Kristian Harms at
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187394

[ More complete commentary, as response to questions by Andrew: ]

> This changes the call environment for all implementations of
> ->Current_done().  Are they all safe to call under this lock?

Short answer: Yes, trust me.  ;-) Long answer:

The done() callbacks are passed on to sbp2 from the SCSI stack along
with each SCSI command via the queuecommand hook.  The done() callback
is safe to call in atomic context.  So does
Documentation/scsi/scsi_mid_low_api.txt say, and many if not all SCSI
low-level handlers rely on this fact.  So whatever this callback does,
it is "self-contained" and it won't conflict with sbp2's internal ORB
list handling.  In particular, it won't race with the
sbp2_command_orb_lock.

Moreover, sbp2 already calls the done() handler with
sbp2_command_orb_lock taken in sbp2scsi_complete_all_commands().  I
admit this is ultimately no proof of correctness, especially since this
portion of code introduced the spinlock recursion in the first place and
we didn't realize it since this code's submission before 2.6.15 until
now.  (I have learned a lesson from this.)

I stress-tested my patch on x86 uniprocessor with a preemptible SMP
kernel (alas I have no SMP machine yet) and made sure that all code
paths which involve the sbp2_command_orb_lock were gone through multiple
times.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      24c7cd06
  17. 29 3月, 2006 4 次提交
  19. 23 2月, 2006 3 次提交
    • S
      sbp2: update 36byte inquiry workaround (fix compatibility regression) · a80614d1
      由 Stefan Richter 提交于 
      Since about Linux 2.6.14, sbp2's inquiry workaround did not work anymore
due to changes in the SCSI layer. Update it to become effective again.
Testing one of the two known affected bridges has shown that skip_ms_page_8
is required as well.

Also, make force_inquiry_hack tunable via /sys/module/sbp2/parameters.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJody McIntyre <scjody@modernduck.com>
(cherry picked from 99496037c6744fd938ffb8ccfc8fc91762322ff8 commit)
      a80614d1
    • S
      sbp2: variable status FIFO address (fix login timeout) · 35bdddb8
      由 Stefan Richter 提交于 
      Let the ieee1394 core select a suitable 1394 address range for sbp2's
status FIFO instead of using a fixed range. Since the core only selects
addresses which are guaranteed to be out of the "physical range" as per
OHCI 1.1, this patch also fixes an old bug:

OHCI controllers which implement a writeable PhysicalUpperBound register
included sbp2's status FIFO in the physical range. That way sbp2 was
never notified of a succesful login and always failed after timeout.
Affected OHCI host adapters include ALi and Fujitsu controllers.

As another side effect of this patch, the status FIFO is no longer
located in a range for which OHCI chips perform "posted writes". Each
status write now requires a response subaction. But since large data
transfers involve only few status writes, there is no measurable
decrease of I/O throughput. What's more, the status FIFO is now safe
from potential host bus errors. Nevertheless, posted writes could be
re-enabled by extensions to the ARM features of the 1394 stack.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJody McIntyre <scjody@modernduck.com>
(cherry picked from b2d38cccad4ef80d6b672b8f89aae5fe2907b113 commit)
      35bdddb8
    • S
      sbp2: fix another deadlock after disconnection · bf637ec3
      由 Stefan Richter 提交于 
      If there were commands enqueued but not completed before an SBP-2 unit
was unplugged (or an attempt to reconnect failed), knodemgrd or any
process which tried to remove the device would sleep uninterruptibly
in blk_execute_rq().  Therefore make sure that all commands are
completed when sbp2 retreats.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJody McIntyre <scjody@modernduck.com>
(cherry picked from 61daa34c132c5d4ed8630e2c46e9bf2f0c7b3428 commit)
      bf637ec3
  21. 19 2月, 2006 1 次提交
  23. 14 12月, 2005 2 次提交
  25. 13 12月, 2005 2 次提交