linux-toradex.git/drivers/scsi, branch v2.6.31.4

SCSI: libsrp: fix memory leak in srp_ring_free()

2009-09-24T15:43:50+00:00

commit afffd3dabe5209882c8cc59a373a4d33b5db304a upstream.

This patch fixes a memory leak in the libsrp function srp_ring_free().
It is not documented whether or not this function should free the ring
pointer itself. But the source code of the callers of this function
(srp_target_alloc() and srp_target_free()) makes it clear that
srp_ring_free() should deallocate the ring pointer itself. Furthermore,
the patch below makes srp_ring_free() deallocate all memory allocated by
srp_ring_alloc().

This patch affects the ibmvstgt driver, which is the only in-tree driver
that calls the srp_ring_free() function (indirectly).

Signed-off-by: Bart Van Assche 
Acked-by: FUJITA Tomonori 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: fix oops during scsi scanning

2009-09-24T15:43:50+00:00

commit ea038f63ac52439e7816295fa6064fe95e6c1f51 upstream.

Chris Webb reported:
  p0# uname -a
  Linux f7ea8425-d45b-490f-a738-d181d0df6963.host.elastichosts.com 2.6.30.4-elastic-lon-p #2 SMP PREEMPT Thu Aug 20 14:30:50 BST 2009 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux
  p0# zgrep SCAN_ASYNC /proc/config.gz
  # CONFIG_SCSI_SCAN_ASYNC is not set

  p0# cat /var/log/kern/2009-08-20
  [...]
  15:27:10.485 kernel: scsi9 : iSCSI Initiator over TCP/IP
  15:27:11.493 kernel: scsi 9:0:0:0: RAID              IET      Controller       0001 PQ: 0 ANSI: 5
  15:27:11.493 kernel: scsi 9:0:0:0: Attached scsi generic sg6 type 12
  15:27:11.495 kernel: scsi 9:0:0:1: Direct-Access     IET      VIRTUAL-DISK     0001 PQ: 0 ANSI: 5
  15:27:11.495 kernel: sd 9:0:0:1: Attached scsi generic sg7 type 0
  15:27:11.495 kernel: sd 9:0:0:1: [sdg] 4194304 512-byte hardware sectors: (2.14 GB/2.00 GiB)
  15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write Protect is off
  15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
  15:27:13.012 kernel: sdg:<6>scsi 9:0:0:1: [sdg] Unhandled error code
  15:27:13.012 kernel: scsi 9:0:0:1: [sdg] Result: hostbyte=0x07 driverbyte=0x00
  15:27:13.012 kernel: end_request: I/O error, dev sdg, sector 0
  15:27:13.012 kernel: Buffer I/O error on device sdg, logical block 0
  15:27:13.012 kernel: ldm_validate_partition_table(): Disk read failed.
  15:27:13.012 kernel: unable to read partition table
  15:27:13.014 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
  15:27:13.014 kernel: IP: [] disk_part_iter_next+0x74/0xfd
  15:27:13.014 kernel: PGD 82ad0b067 PUD 82cd7e067 PMD 0
  15:27:13.014 kernel: Oops: 0000 [#1] PREEMPT SMP
  15:27:13.014 kernel: last sysfs file: /sys/devices/platform/host9/session4/iscsi_session/session4/ifacename
  15:27:13.014 kernel: CPU 5
  15:27:13.014 kernel: Modules linked in:
  15:27:13.014 kernel: Pid: 13999, comm: async/0 Not tainted 2.6.30.4-elastic-lon-p #2 X7DBN
  15:27:13.014 kernel: RIP: 0010:[]  [] disk_part_iter_next+0x74/0xfd
  15:27:13.014 kernel: RSP: 0018:ffff88066afa3dd0  EFLAGS: 00010246
  15:27:13.014 kernel: RAX: ffff88082b58a000 RBX: ffff88066afa3e00 RCX: 0000000000000000
  15:27:13.014 kernel: RDX: 0000000000000000 RSI: ffff88082b58a000 RDI: 0000000000000000
  15:27:13.014 kernel: RBP: ffff88066afa3df0 R08: ffff88066afa2000 R09: ffff8806a204f000
  15:27:13.014 kernel: R10: 000000fb12c7d274 R11: ffff8806c2bf0628 R12: ffff88066afa3e00
  15:27:13.014 kernel: R13: ffff88082c829a00 R14: 0000000000000000 R15: ffff8806bc50c920
  15:27:13.014 kernel: FS:  0000000000000000(0000) GS:ffff88002818a000(0000) knlGS:0000000000000000
  15:27:13.014 kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
  15:27:13.014 kernel: CR2: 0000000000000010 CR3: 000000082ade3000 CR4: 00000000000426e0
  15:27:13.014 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  15:27:13.014 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  15:27:13.014 kernel: Process async/0 (pid: 13999, threadinfo ffff88066afa2000, task ffff8806c2bf05e0)
  15:27:13.014 kernel: Stack:
  15:27:13.014 kernel: 0000000000000000 ffff88066afa3e00 ffff88066afa3e00 ffff88082c829a00
  15:27:13.014 kernel: ffff88066afa3e40 ffffffff80306feb ffff88082b58a000 0000000000000000
  15:27:13.014 kernel: 0000000000000001 ffff8806bc50c920 ffff88066afa3e40 ffff88082b58a000
  15:27:13.014 kernel: Call Trace:
  15:27:13.014 kernel: [] register_disk+0x122/0x13a
  15:27:13.014 kernel: [] add_disk+0xaa/0x106
  15:27:13.014 kernel: [] sd_probe_async+0x198/0x25b
  15:27:13.014 kernel: [] async_thread+0x10c/0x20d
  15:27:13.014 kernel: [] ? default_wake_function+0x0/0xf
  15:27:13.014 kernel: [] ? async_thread+0x0/0x20d
  15:27:13.014 kernel: [] kthread+0x55/0x80
  15:27:13.014 kernel: [] child_rip+0xa/0x20
  15:27:13.014 kernel: [] ? kthread+0x0/0x80
  15:27:13.014 kernel: [] ? child_rip+0x0/0x20
  15:27:13.014 kernel: Code: c8 ff 80 e1 0c b9 00 00 00 00 0f 44 c1 41 83 cd ff 48 8d 7a 20 48 be ff ff ff ff 08 00 00 00 48 b9 00 00 00 00 08 00 00 00 eb 50 <8b> 42 10 41 bd 01 00 00 00 eb db 4c 63 c2 4e 8d 04 c7 4d 8b 20
  15:27:13.015 kernel: RIP  [] disk_part_iter_next+0x74/0xfd
  15:27:13.015 kernel: RSP 
  15:27:13.015 kernel: CR2: 0000000000000010
  15:27:13.015 kernel: ---[ end trace 6104b56ef5590e25 ]---

The problem is caused because the async scanning split in sd.c doesn't hold
any reference to the device when it kicks off the async piece.  What's
happening is that an iSCSI disconnect is destorying the device again *before*
the async sd scanning thread even starts.  Fix this by taking a reference
before starting the thread and dropping it again when the thread completes.

Reported-by: Chris Webb 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

mpt2sas: Raid 10 Volume is showing as Raid 1E in dmesg

2009-09-24T15:43:49+00:00

commit ed79f1280d1bc54f168abcffc8c3e0bf8ffb1873 upstream.

This patch modifies the slave_configure callback so the messages that get sent
to system log for RAID1E volumes contain the string "RAID10" instead of
"RAID1E". These messages contain information regarding what kind of scsi device
is being added. Certain OEMS can enable displaying the RAID10 string instead of
RAID1E via manufacturing page 10.   The driver will read this config page at
driver load time, then determine from the GenericFlags0 bits whether display
the RAID10 or RAID1E string, also even drive count is taken into consideration.

Signed-off-by: Kashyap Desai 
Reviewed-by: Eric Moore 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

mpt2sas: setting SDEV into RUNNING state from Interrupt context

2009-09-24T15:43:48+00:00

commit 34a03bef2202d0c9983a8da0a8abaee37d285847 upstream.

Changing SDEV Running state from interrupt context. Previously It was
handle in work queue thread. With this change It will not wait for work
queue thread to execute scsih_ublock_io_device to put SDEV into Running
state. This will reduce delay for Device becoming RUNNING.

Modified this patch considering James comment "Not to change SDEV state
using  scsi_device_set_state API, instead use scsi_internal_device_unblock
scsi_internal_device_block API"

Signed-off-by: Kashyap Desai 
Reviewed-by: Eric Moore 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

mpt2sas: Prevent sending command to FW while Host Reset

2009-09-24T15:43:48+00:00

commit 155dd4c763694222c125e65438d823f58ea653bc upstream.

This patch renames the flag for indicating host reset from
ioc_reset_in_progress to shost_recovery. It also removes the spin locks
surrounding the setting of this flag, which are unnecessary.   Sanity checks on
the shost_recovery flag were added thru out the code so as to prevent sending
firmware commands during host reset.  Also, the setting of the shost state to
SHOST_RECOVERY was removed to prevent deadlocks, this is actually better
handled by the shost_recovery flag.

Signed-off-by: Kashyap Desai 
Reviewed-by: Eric Moore 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

mpt2sas : Rescan topology from Interrupt context instead of work thread

2009-09-24T15:43:48+00:00

commit cd4e12e8ad246ec5bc23ab04d0da0e6985025620 upstream.

Following host reset its possible that the controller firmware could
assign new handles for devices, as well as adding or deleting devices. There is
code in the driver that will rescan the topology folowing host reset; updating
device handles, and remove devices that are no longer responding. This patch
will improve the responsivness by moving this rescaning from the delayed hotplug
worker thread to immediately following the host reset.

Signed-off-by: Kashyap Desai 
Reviewed-by: Eric Moore 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

sg: fix oops in the error path in sg_build_indirect()

2009-09-24T15:43:47+00:00

commit e71044ee2efa4792e21d243b03d49006db66aec9 upstream.

When the allocation fails in sg_build_indirect(), an oops happens in
the error path. It's caused by an obvious typo.

Signed-off-by: Michal Schmidt 
Reported-by: Bob Tracy 
Acked-by: Douglas Gilbert 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

[SCSI] mpt2sas: fix config request and diag reset deadlock

2009-08-14T14:16:05+00:00

Moving the setting and clearing of the mutex's to
_config_request. There was a mutex deadlock when diag reset is called from
inside _config_request, so diag reset was moved to outside the mutexs.

Signed-off-by: James Bottomley

[SCSI] mpt2sas: Bump driver version 01.100.04.00

2009-08-13T21:31:41+00:00

Bump version to 01.100.04.00

Signed-off-by: Kashyap Desai 
Signed-off-by: James Bottomley

[SCSI] mpt2sas: fix oops because drv data points to NULL on resume from hibernate

2009-08-13T21:31:32+00:00

Fix another ocurring when the system resumes.  This oops was due to driver
setting the pci drvdata to NULL on the prior hibernation.  Becuase it was
set to NULL, upon resmume we assume the pci drvdata is non-zero, and we oops.
To fix the ooops, we don't set pci drvdata to NULL at hibernation time.

Signed-off-by: Kashyap Desai 
Signed-off-by: James Bottomley