1. 08 2月, 2008 3 次提交
    • S
      [SCSI] aacraid: do not set valid bit in sense information · 8e31e607
      Salyzyn, Mark 提交于
      Luben Tuikov [mailto:ltuikov@yahoo.com] sez:
      > Just as in your case and Tony's case, which I presume
      > uses the same RAID firmware vendor, it would've
      > probably been better if the RAID firmware vendor
      > fixed the firmware to not set the VALID bit if the
      > INFORMATION field is not valid.
      
      Point taken regarding the aacraid driver. Dropped the VALID bit, and
      then did some cleanup/simplification of the set_sense procedure and
      the associated parameters. Mike did some preliminary tests when the
      VALID bit was dropped before the 'Re: [PATCH] [SCSI] sd: make error
      handling more robust' patches came on the scene. The change in the
      SCSI subsystem does make this enclosed aacraid patch unnecessary, so
      this aacraid patch is merely post battle ground cleanup. If the
      simplification is an issue, repugnant, too much for a back-port to the
      stable trees or clouds the point, this patch could be happily
      distilled down to:
      
      diff -ru a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
      --- a/drivers/scsi/aacraid/aachba.c     2008-02-06 16:26:45.834938955 -0500
      +++ b/drivers/scsi/aacraid/aachba.c     2008-02-06 16:32:01.109035329 -0500
      @@ -865,7 +865,7 @@
                               u32 residue)
       {
      -        sense_buf[0] = 0xF0;    /* Sense data valid, err code 70h (current error) */
      +        sense_buf[0] = 0x70;    /* Sense data invalid, err code 70h (current error) */
               sense_buf[1] = 0;       /* Segment number, always zero */
      
               if (incorrect_length) {
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      8e31e607
    • S
      [SCSI] aacraid: pci_set_dma_max_seg_size opened up for late model controllers · 62e9f5c4
      Salyzyn, Mark 提交于
      This patch ensures that the modern adapters get a maximum sg segment
      size on par with the maximum transfer size. Added some localized
      janitor fixes to the discussion patch I used with Fujita.
      
      FUJITA Tomonori [mailto:fujita.tomonori@lab.ntt.co.jp] sez:
      > I think that setting the proper maximum segment size for the late
      > model cards (as you did above) makes sense.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      62e9f5c4
    • S
      [SCSI] aacraid: fib context lock for management ioctls (take 2) · 5234e25c
      Salyzyn, Mark 提交于
      The first patch (a119ee8e) was a bit
      too aggressive and nested the locks (!) unit testing was in
      error. This patch was reverted by
      203a512f.
      
      This new patch should fix the locks correctly.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      5234e25c
  2. 06 2月, 2008 1 次提交
  3. 31 1月, 2008 2 次提交
  4. 25 1月, 2008 1 次提交
  5. 24 1月, 2008 16 次提交
  6. 12 1月, 2008 3 次提交
    • S
      [SCSI] aacraid: fix driver failure with Dell PowerEdge Expandable RAID Controller 3/Di · 94cf6ba1
      Salyzyn, Mark 提交于
      As reported in http://bugzilla.kernel.org/show_bug.cgi?id=3D9133 it was
      discovered that the PERC line of controllers lacked a key 64 bit
      ScatterGather capable SCSI pass-through function. The adapters are still
      capable of 64 bit ScatterGather I/O commands, but these two can not be
      mixed. This problem was exacerbated by the introduction of the SCSI
      Generic access to the DASD physical devices.
      
      The fix for users before this patch is applied is aacraid.dacmode=3D0 on
      the kernel command line to disable 64 bit I/O.
      
      The enclosed patch introduces a new adapter quirk and tries to limp
      along by enabling pass-through in situations where memory is 32 bit
      addressable on 64 bit machines, or disable the pass-through functions
      altogether. I expect that the check for 32 bit addressable memory to be
      controversial in that it can be incorrect in non-Dell non-Intel systems
      that PERC would never be installed under, the alternative is to disable
      pass-through in all cases which could be reported as another regression.
      
      Pass-through is used for SCSI Generic access to the physical devices, or
      for the management applications to properly function.
      
      In systems where this patch has disabled pass-through because it is
      unsupportable in combination with I/O performance, the user can choose
      to enable pass-through by turning off dacmode (aacraid.dacmode=3D0) or
      limiting the discovered kernel memory (mem=3D4G) with an associated loss
      in runtime performance. If we chose instead to turn off 64 bit dacmode
      for the adapters with this quirk, then this would be reported as another
      regression.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      94cf6ba1
    • C
      [SCSI] aacraid: don't assign cpu_to_le32(int) to u8 · f3307f72
      Christoph Hellwig 提交于
      On Wed, Nov 07, 2007 at 01:51:44PM -0500, Salyzyn, Mark wrote:
      > Christoph Hellwig [mailto:hch@infradead.org] sez:
      > > Did anyone run the driver through sparse to see if we have
      > > more issues like this?
      >
      > There are some warnings from sparse, none like this one. I will deal
      > with the warnings ...
      
      Actually there are a lot of endianess warnings, fortunately most of them
      harmless.  The patch below fixes all of them up (including the ones in
      the patch I replied to), except for aac_init_adapter which is really odd
      and I don't know what to do.
      
      [jejb fixed up rejections and checkpatch issues]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NMark Salyzyn <mark_salyzyn@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f3307f72
    • S
      [SCSI] aacraid: forced reset override · f858317d
      Salyzyn, Mark 提交于
      Some of our vendors have requested that our adapters ignore the hardware
      reset attempts during recovery and have enforced this with changes in
      Adapter Firmware. Some of our customers have requested the option to be
      able to reset the adapter under adverse adapter failure, we even had a
      few defects reported here considering it a regression that the Adapter
      could not be reset. This patch addresses this dichotomy. The user can
      force the adapter to be reset if it supports the IOP_RESET_ALWAYS
      command, in cases where the adapter has been programmed to ignore the
      reset, by setting the aacraid.check_reset parameter to a value of -1.
      
      The driver will not reset an Adapter that does not support the reset
      command(s).
      
      This patch also fixes and cleans up some of the logic associated with
      resetting the adapter.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f858317d
  7. 12 11月, 2007 1 次提交
    • A
      [SCSI] aacraid: fix security weakness · 5f78e89b
      Alan Cox 提交于
      Actually there are several but one is trivially fixed
      
      1.	FSACTL_GET_NEXT_ADAPTER_FIB ioctl does not lock dev->fib_list
      but needs to
      2.	Ditto for FSACTL_CLOSE_GET_ADAPTER_FIB
      3.	It is possible to construct an attack via the SRB ioctls where
      the user obtains assorted elevated privileges. Various approaches are
      possible, the trivial ones being things like writing to the raw media
      via scsi commands and the swap image of other executing programs with
      higher privileges.
      
      So the ioctls should be CAP_SYS_RAWIO - at least all the FIB manipulating
      ones. This is a bandaid fix for #3 but probably the ioctls should grow
      their own capable checks. The other two bugs need someone competent in that
      driver to fix them.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Acked-by: NMark Salyzyn <mark_salyzyn@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      5f78e89b
  8. 08 11月, 2007 3 次提交
  9. 29 10月, 2007 1 次提交
    • A
      fix abuses of ptrdiff_t · 142956af
      Al Viro 提交于
      Use of ptrdiff_t in places like
      
      -                       if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
      +                       if (!access_ok(VERIFY_WRITE, (u8 __user *)
      +                                               (ptrdiff_t) u_tmp->rx_buf,
      +                                               u_tmp->len))
      
      is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general
      we are not even promised that ptrdiff_t is large enough to hold a pointer,
      just enough to hold a difference between two pointers within the same object).
      For another, it confuses the fsck out of sparse.
      
      Use unsigned long or uintptr_t instead.  There are several places misusing
      ptrdiff_t; fixed.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      142956af
  10. 23 10月, 2007 1 次提交
  11. 20 10月, 2007 1 次提交
  12. 16 10月, 2007 1 次提交
  13. 13 10月, 2007 1 次提交
  14. 04 8月, 2007 1 次提交
  15. 28 7月, 2007 2 次提交
    • S
      [SCSI] aacraid: fix Sunrise Lake reset handling · 9859c1aa
      Salyzyn, Mark 提交于
      The patch is *much* smaller than the description. I am attempting to
      answer to those that want to understand an issue that was reported in
      May this year.
      
      If a Sunrise Lake based card that requires an alternate reset mechanism
      is set up to ignore the commanded IOP_RESET it reports 0x00000010
      (IOP_RESET ignored) instead of 0x3803000F (use alternate reset mechanism
      to reset all cores), and thus the reset platform function decides to
      switch to IOP_RESET_ALWAYS because the reset platform function
      parameters indicate that we *need* to reset the card. IOP_RESET_ALWAYS
      then responds with the 0x3803000F return code, but alas we treat this as
      an error instead of using the alternate reset mechanism (put a 0x03 into
      the register offset 0x38). The reset fails, but the fact that the
      IOP_RESET_ALWAYS command was issued has put the card in a purposeful
      shutdown state in preparation for the alternate hardware reset to be
      applied. Yuck.
      
      IOP_RESET is ignored in internal production cards, typically to ensure
      that we catch all adapter lockup issues without the driver progressing
      further, so this would not appear to be a field issue and thus this
      patch was destined to be only in the internal Adaptec source tree.
      IOP_RESET_ALWAYS is reserved for
      kexec/kdump/FirmwareUpdate/AutomatedTestFrames so we did not function as
      expected in any case. Also in the past we have had OEMs specifically
      request that cards not be resetable after a BlinkLED/FirmwareAssert for
      one reason or another and To head off the possibility that the Sunrise
      Lake based cards would suffer a similar fate, we propose the enclosed
      fix.
      
      Yinghai Lu of SUN had a pre-production card with IOP_RESET disabled when
      he reported an issue to the linux kernel list back in May regarding a
      kexec problem resulting from this reset being ignore. His fix was to
      update the Firmware to one that did not ignore the IOP_RESET. Previous
      kernels did not attempt to reset the adapter and that is why it surfaced
      as a regression in his hands.
      
      The current list of aacraid based cards that use Sunrise Lake:
      
      9005:0285:9005:02b5     Adaptec 5445
      9005:0285:9005:02b6     Adaptec 5805
      9005:0285:9005:02b7     Adaptec 5085
      9005:0285:9005:02c3     Adaptec 51205
      9005:0285:9005:02c4     Adaptec 51605
      9005:0285:9005:02ce     Adaptec 51245
      9005:0285:9005:02cf     Adaptec 51645
      9005:0285:9005:02d0     Adaptec 52445
      9005:0285:9005:02d1     Adaptec 5405
      9005:0285:9005:02b8     ICP     ICP5445SL
      9005:0285:9005:02b9     ICP     ICP5085SL
      9005:0285:9005:02ba     ICP     ICP5805SL
      9005:0285:9005:02c5     ICP     ICP5125SL
      9005:0285:9005:02c6     ICP     ICP5165SL
      9005:0285:108e:7aac     SUN     STK RAID REM
      9005:0285:108e:0286     SUN     STK RAID INT
      9005:0285:108e:0287     SUN     STK RAID EXT
      9005:0285:108e:7aae     SUN     STK RAID EM
      
      All of these are publicly released with IOP_RESET enabled. So there is
      no immediate need for this patch.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      9859c1aa
    • S
      [SCSI] aacraid: add SCSI SYNCHONIZE_CACHE range checking · b90f90d2
      Salyzyn, Mark 提交于
      Customer running an application that issues SYNCHRONIZE_CACHE calls
      directly noticed the broad stroke of the current implementation in the
      aacraid driver resulting in multiple applications feeding I/O to the
      storage causing the issuing application to stall for long periods of
      time. By only waiting for the current WRITE commands, rather than all
      commands, to complete; and those that are in range of the
      SYNCHRONIZE_CACHE call that would associate more tightly with the
      issuing application before telling the Firmware to flush it's dirty
      cache, we managed to reduce the stalling. The Firmware itself still
      flushes all the dirty cache associated with the array ignoring the
      range, it just does so in a more timely manner.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b90f90d2
  16. 27 7月, 2007 1 次提交
  17. 25 7月, 2007 1 次提交