linux-stable.git/drivers/scsi, branch linux-2.6.20.y

[PATCH] 3w-9xxx: Fix dma mask setting

2007-10-17T19:30:31+00:00

[SCSI] 3w-9xxx: Fix dma mask setting

Extracted from commit 0e78d158b67fba3977f577f293c323359d80dd0e

The attached patch updates the 3ware 9000 driver:

- Fix dma mask setting to fallback to 32-bit if 64-bit fails.

Signed-off-by: Adam Radford 
Signed-off-by: James Bottomley 
Signed-off-by: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

[PATCH] aacraid: fix security hole

2007-08-25T15:24:03+00:00

On the SCSI layer ioctl path there is no implicit permissions check for
ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
however allows all sorts of very admin only things to be done so should
check.

Signed-off-by: Alan Cox 
Acked-by: Mark Salyzyn 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

3w-xxxx: fix oops caused by incorrect REQUEST_SENSE handling

2007-05-02T00:06:00+00:00

3w-xxxx emulates a REQUEST_SENSE response by simply returning nothing.
Unfortunately, it's assuming that the REQUEST_SENSE command is
implemented with use_sg == 0, which is no longer the case.  The oops
occurs because it's clearing the scatterlist in request_buffer instead
of the memory region.

This is fixed by using tw_transfer_internal() to transfer correctly to
the scatterlist.

Acked-by: adam radford 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

Fix qlogicpti DMA unmapping

2007-05-02T00:05:57+00:00

[SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something.

We only map DMA when cmd->request_bufflen is non-zero for non-sg
buffers, we thus should make the same check when unmapping.

Based upon a report from Pasi Pirhonen.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix scsi sense handling

2007-04-13T20:47:04+00:00

[SCSI]: Fix scsi_send_eh_cmnd scatterlist handling

This fixes a regression caused by commit:

2dc611de5a3fd955cd0298c50691d4c05046db97

The sense buffer code in scsi_send_eh_cmnd was changed to use
alloc_page() and a scatter list, but the sense data copy was not
updated to match so what we actually get in the sense buffer is total
grabage starting with the kernel address of the struct page we got.
Basically the stack frame of scsi_send_eh_cmd() is what ends up
in the sense buffer.

Depending upon how pointers look on a given platform, you can
end up getting sr_ioctl.c errors when you mount a cdrom.  If
the CDROM gives a check condition for GPCMD_GET_CONFIGURATION issued
by drivers/cdrom/cdrom.c:cdrom_mmc_profile(), sr_ioctl will
spit out this error message in sr_do_ioctl() with the way pointers
are on sparc64:

		default:
			printk(KERN_ERR "%s: CDROM (ioctl) error, command: ", cd->cdi.name);
			__scsi_print_command(cgc->cmd);
			scsi_print_sense_hdr("sr", &sshdr);
			err = -EIO;

This is the error Tom Callaway reported in:

http://marc.info/?l=linux-sparc&m=117407453208101&w=2

Anyways, fix this by using page_address(sgl.page) which is OK
because we know this is low-mem due to GFP_ATOMIC.

Signed-off-by: David S. Miller 
Acked-by: Christoph Hellwig 
Signed-off-by: Greg Kroah-Hartman

st: fix Tape dies if wrong block size used, bug 7919

2007-03-23T19:49:27+00:00

[SCSI] st: fix Tape dies if wrong block size used, bug 7919

On Thu, 1 Feb 2007, Andrew Morton wrote:
> On Thu, 1 Feb 2007 15:34:29 -0800
> bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=7919
> >
> >            Summary: Tape dies if wrong block size used
> >     Kernel Version: 2.6.20-rc5
> >             Status: NEW
> >           Severity: normal
> >              Owner: scsi_drivers-other@kernel-bugs.osdl.org
> >          Submitter: dmartin@sccd.ctc.edu
> >
> >
> > Most recent kernel where this bug did *NOT* occur: 2.6.17.14
> >
> > Other Kernels Tested and Results:
> >
> >     OK 2.6.15.7
> >     OK 2.6.16.37
> >     OK 2.6.17.14
> >     BAD 2.6.18.6
> >     BAD 2.6.18-1.2869.fc6
> >     BAD 2.6.19.2 +
> >     BAD 2.6.20-rc5
> >
> > NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are from kernel.org
> >
...
> > Steps to reproduce:
> > Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive,
> > install a recent kernel
> > set the tape block size - mt setblk 4096
> > read from or write to tape using wrong block size - tar -b 7 -cvf /dev/tape foo
> >
Write does not trigger this bug because the driver refuses in fixed block
mode writes that are not a multiple of the block size. Read does trigger
it in my system.

The bug is not associated with any specific HBA. st tries to do direct i/o
in fixed block mode with reads that are not a multiple of tape block size.

The patch in this message fixes the st problem by switching to using the
driver buffer up to the next close of the device file in fixed block mode
if the user asks for a read like this.

I don't know why the bug has surfaced only after 2.6.17 although the st
problem is old. There may be another bug in the block subsystem and this
patch works around it. However, the patch fixes a problem in st and in
this way it is a valid fix.

This patch may also fix the bug 7900.

The patch compiles and is lightly tested.

Signed-off-by: Kai Makisara 
Cc: Andrew Morton 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

gdth: fix oops in gdth_copy_cmd()

2007-03-23T19:49:21+00:00

Recent alterations to the gdth_fill_raw_cmd() path no longer set the
sg_ranz field for zero transfer commands. However, this field is used
lower down in the function to initialise ha->cmd_len to the size of
the firmware packet.  If this uninitialised field contains a bogus
value, ha->cmd_len can become much larger than the actual firmware
packet and end up oopsing in gdth_copy_cmd() as it tries to copy this
huge packet to the device (usually because it runs into an unallocated
page).

The fix is to initialise the sg_ranz field to zero at the start of
gdth_fill_raw_cmd().

Signed-off-by: Joerg Dorchain 
Acked-by: "Achim Leubner" 
Signed-off-by: Andrew Morton 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

Fix bug 7994 sleeping function called from invalid context

2007-03-13T18:26:46+00:00

  - addresses the reported bug (with GFP_KERNEL -> GFP_ATOMIC)
  - improves error checking, and
  - is a subset of the changes to scsi_debug in lk 2.6.21-rc*

Compiled and lightly tested (in lk 2.6.21-rc2 environment).

Signed-off-by: Douglas Gilbert 
Signed-off-by: Greg Kroah-Hartman

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

2007-02-03T19:26:39+00:00

* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] sd: udev accessing an uninitialized scsi_disk field results in a crash
  [SCSI] st: A MTIOCTOP/MTWEOF within the early warning will cause the file number to be incorrect
  [SCSI] qla4xxx: bug fixes
  [SCSI] Fix scsi_add_device() for async scanning

[SCSI] sd: udev accessing an uninitialized scsi_disk field results in a crash

2007-02-03T01:45:41+00:00

	sd_probe() calls class_device_add() even before initializing the
sdkp->device variable. class_device_add() eventually results in the user mode
udev program to be called. udev program can read the the allow_restart
attribute of the newly created scsi device. This is resulting in a crash as
the show function for allow_restart (i.e sd_show_allow_restart) returns the
attribute value by reading the sdkp->device->allow_restart variable. As the
sdkp->device is not initialized before calling the user mode hotplug helper,
this results in a crash.
	The patch below solves it by calling class_device_add() only after the
necessary fields in the scsi_disk structure are initialized properly.

Signed-off-by: Nagendra Singh Tomar 
Signed-off-by: James Bottomley