[GIT PATCH] SCSI bug fixes for 2.6.23-rc1

[GIT PATCH] SCSI bug fixes for 2.6.23-rc1

[James Bottomley]

This is basically a set of bug fixes with a few minor cleanups thrown
in.  There are also a few bsg fixes we're taking through this tree
because SCSI is the current sole consumer. The reason for the huge size
is the lindent of the advansys driver along with a few cleanups.

The patch is available here:

master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git

The short changelog is:

Alan Cox (1):
      aacraid: Fix security hole

Boaz Harrosh (1):
      qla2xxx: Data accessors Cleanup of last merge

Chip Coldwell (1):
      sym53c8xx: don't claim cpqarray device

Darrick J. Wong (1):
      libsas: SMP request handler shouldn't crash when rphy is NULL

FUJITA Tomonori (3):
      simscsi: convert to use the data buffer accessors
      bsg: remove unnecessary code and comments
      bsg: use lib/idr.c to find a unique minor number

James Bottomley (2):
      aic79xx, aic7xxx: Fix incorrect width setting
      bsg: fix unused variable warnings for BLK_DEV_BSG=n

Jeff Garzik (1):
      libsas: Remove PCI dependencies

Jesper Juhl (1):
      libsas: Fix potential NULL dereference in sas_smp_get_phy_events()

Matthew Wilcox (1):
      advansys: lindent and other large, uninteresting changes

Mike Christie (4):
      iscsi_tcp: Turn off bounce buffers
      libiscsi: fix cmd seqeunce number checking
      iscsi_tcp, ib_iser Enable module refcounting for iscsi host template
      libiscsi: make sure session is not blocked when removing host

Paul Mundt (1):
      bsg: Fix build for CONFIG_BLOCK=n

Prakash, Sathya (5):
      mpt fusion: Changes in mptctl.c for logging support
      mpt fusion: Changes in mptfc.c mptlan.c mptsas.c and mptspi.c for logging support
      mpt fusion: Changes in mptscsih.c for logging support
      mpt fusion: Changes in mptbase.c for logging support
      mpt fusion: logging support in Kconfig, Makefile, mptbase.h and addition of mptdebug.h

Salyzyn, Mark (4):
      aacraid: fix Sunrise Lake reset handling
      aacraid: add SCSI SYNCHONIZE_CACHE range checking
      aacraid: draw line in sand, sundry cleanup and version update
      aacraid: sysfs adapter reset/status format change.

Seokmann Ju (1):
      qla2xxx: fix to honor ignored parameters in sysfs attributes

akpm@linux-foundation.org (1):
      add easyRAID to the no report luns blacklist


And the diffstat:

 arch/ia64/hp/sim/simscsi.c               |   66 
 block/Kconfig                            |    4 
 block/bsg.c                              |   78 
 drivers/infiniband/ulp/iser/iscsi_iser.c |    1 
 drivers/message/fusion/Kconfig           |   14 
 drivers/message/fusion/Makefile          |   37 
 drivers/message/fusion/mptbase.c         |  467 
 drivers/message/fusion/mptbase.h         |  198 
 drivers/message/fusion/mptctl.c          |  266 
 drivers/message/fusion/mptdebug.h        |  288 
 drivers/message/fusion/mptfc.c           |  108 
 drivers/message/fusion/mptlan.c          |    3 
 drivers/message/fusion/mptsas.c          |  276 
 drivers/message/fusion/mptscsih.c        |  446 
 drivers/message/fusion/mptspi.c          |   53 
 drivers/scsi/aacraid/aachba.c            |   66 
 drivers/scsi/aacraid/aacraid.h           |    6 
 drivers/scsi/aacraid/linit.c             |    9 
 drivers/scsi/aacraid/nark.c              |    3 
 drivers/scsi/aacraid/rkt.c               |    2 
 drivers/scsi/aacraid/rx.c                |    2 
 drivers/scsi/advansys.c                  |28261 +++++++++++++++----------------
 drivers/scsi/aic7xxx/aic79xx_osm.c       |   23 
 drivers/scsi/aic7xxx/aic7xxx_osm.c       |   11 
 drivers/scsi/aic94xx/aic94xx_init.c      |    4 
 drivers/scsi/iscsi_tcp.c                 |    2 
 drivers/scsi/libiscsi.c                  |   47 
 drivers/scsi/libsas/sas_ata.c            |   30 
 drivers/scsi/libsas/sas_discover.c       |    3 
 drivers/scsi/libsas/sas_dump.c           |    2 
 drivers/scsi/libsas/sas_expander.c       |   18 
 drivers/scsi/qla2xxx/qla_attr.c          |   39 
 drivers/scsi/qla2xxx/qla_def.h           |    4 
 drivers/scsi/qla2xxx/qla_init.c          |   19 
 drivers/scsi/qla2xxx/qla_isr.c           |    4 
 drivers/scsi/scsi_devinfo.c              |    3 
 drivers/scsi/sym53c8xx_2/sym_glue.c      |    2 
 include/linux/bsg.h                      |   10 
 include/scsi/libiscsi.h                  |    3 
 include/scsi/libsas.h                    |    2 
 40 files changed, 15957 insertions(+), 14923 deletions(-)

James

Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

[Jeff Garzik]

James Bottomley wrote:
> This is basically a set of bug fixes with a few minor cleanups thrown
> in.  There are also a few bsg fixes we're taking through this tree
> because SCSI is the current sole consumer. The reason for the huge size
> is the lindent of the advansys driver along with a few cleanups.
> 
> The patch is available here:
> 
> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git


You missed
[SCSI] arcmsr: Fix hardware wait loops

	Jeff

Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

[James Bottomley]

On Sun, 2007-07-29 at 18:51 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > This is basically a set of bug fixes with a few minor cleanups thrown
> > in.  There are also a few bsg fixes we're taking through this tree
> > because SCSI is the current sole consumer. The reason for the huge size
> > is the lindent of the advansys driver along with a few cleanups.
> > 
> > The patch is available here:
> > 
> > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
> 
> 
> You missed
> [SCSI] arcmsr: Fix hardware wait loops

Waiting for maintainer ack ... msleep_interruptible -> ssleep is a
change with zero practical impact for this driver, so I think we can
afford to wait.

Nick is usually pretty good ... but I'll add it to scsi-pending just in
case.

James

Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

[Jeff Garzik]

James Bottomley wrote:
> msleep_interruptible -> ssleep is a
> change with zero practical impact for this driver,

eh, how do you figure?

A signal can clearly cause the abort-related functions to delay far 
shorter than the driver wishes.

The msleep_interruptible() in arcmsr_wait_msgint_ready() probably isn't 
fatal -- unless it's there to ensure the hardware isn't pounded -- but 
again, a signal can cause a CPU-wasting busy loop that could last for 
quite a while (in CPU terms).

	Jeff

Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

[James Bottomley]

On Sun, 2007-07-29 at 21:04 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > msleep_interruptible -> ssleep is a
> > change with zero practical impact for this driver,
> 
> eh, how do you figure?
> 
> A signal can clearly cause the abort-related functions to delay far 
> shorter than the driver wishes.
> 
> The msleep_interruptible() in arcmsr_wait_msgint_ready() probably isn't 
> fatal -- unless it's there to ensure the hardware isn't pounded -- but 
> again, a signal can cause a CPU-wasting busy loop that could last for 
> quite a while (in CPU terms).

I didn't say the usage wasn't a bad example or couldn't cause problems
in certain cases.  I said "zero practical effect".  This is because the
two possible threads that enter these routines already have all user
signals blocked.

James

Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1

[Jeff Garzik]

James Bottomley wrote:
> On Sun, 2007-07-29 at 21:04 -0400, Jeff Garzik wrote:
>> James Bottomley wrote:
>>> msleep_interruptible -> ssleep is a
>>> change with zero practical impact for this driver,
>> eh, how do you figure?
>>
>> A signal can clearly cause the abort-related functions to delay far 
>> shorter than the driver wishes.
>>
>> The msleep_interruptible() in arcmsr_wait_msgint_ready() probably isn't 
>> fatal -- unless it's there to ensure the hardware isn't pounded -- but 
>> again, a signal can cause a CPU-wasting busy loop that could last for 
>> quite a while (in CPU terms).
> 
> I didn't say the usage wasn't a bad example or couldn't cause problems
> in certain cases.  I said "zero practical effect".  This is because the
> two possible threads that enter these routines already have all user
> signals blocked.

Ah!  Understood.

	Jeff