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

SCSI: Fix protection scsi_data_buffer leak

2009-10-22T04:51:10+00:00

commit b4c2554d40ceac130a8d062eaa8838ed22158c45 upstream.

We would leak a scsi_data_buffer if the free_list command was of the
protected variety.

Reported-by: Boaz Harrosh 
Signed-off-by: Martin K. Petersen 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: sr: report more accurate drive status after closing the tray.

2009-09-09T03:17:50+00:00

commit 96bcc722c47d07b6fd05c9d0cb3ab8ea5574c5b1 upstream

[SCSI] sr: report more accurate drive status after closing the tray.

So, what's happening here is that the drive is reporting a sense of
2/4/1 ("logical unit is becoming ready") from sr_test_unit_ready(), and
then we ask for the media event notification before checking that result
at all.  The check_media_event_descriptor() call isn't getting a check
condition, but it's also reporting that the tray is closed and that
there's no media.  In actuality it doesn't yet know if there's media or
not, but there's no way to express that in the media event status field.

My current thought is that if it told us the device isn't yet ready, we
should return that immediately, since there's nothing that'll tell us
any more data than that reliably:

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

SCSI: libsas: reuse the original port when hotplugging phys in wide ports

2009-08-16T21:26:30+00:00

commit 5381837f125cc62ad703fbcdfcd7566fc81fd404 upstream.

There's a hotplug problem in the way libsas allocates ports: it loops over the
available ports first trying to add to an existing for a wide port and
otherwise allocating the next free port.  This scheme only works if the port
array is packed from zero, which fails if a port gets hot unplugged and the
array becomes sparse.  In that case, a new port is formed even if there's a
wide port it should be part of.  Fix this by creating two loops over all the
ports:  the first to see if the phy should be part of a wide port and the
second to form a new port in an empty port slot.

Signed-off-by: Tom Peng 
Signed-off-by: Jack Wang 
Signed-off-by: Lindar Liu 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: zalon: fix oops on attach failure

2009-07-30T23:05:59+00:00

commit d3a263a8168f78874254ea9da9595cfb0f3e96d7 upstream.

I recently discovered on my zalon that if the attachment fails because
of a bus misconfiguration (I scrapped my HVD array, so the card is now
unterminated) then the system oopses.  The reason is that if
ncr_attach() returns NULL (signalling failure) that NULL is passed by
the goto failed straight into ncr_detach() which oopses.

The fix is just to return -ENODEV in this case.

Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

3w-xxxx: scsi_dma_unmap fix

2009-06-12T03:01:19+00:00

commit 7b14f58ad65f9d74e4273fb45360cfea824495aa upstream.

This patch fixes the following regression that occurred during the
scsi_dma_map()/unmap()
changes when compiling with CONFIG_DMA_API_DEBUG=y :

WARNING: at lib/dma-debug.c:496 check_unmap+0x142/0x542()
Hardware name:
3w-xxxx 0000:02:02.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x0000000000000000] [size=36
bytes]

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

SCSI: libiscsi: fix iscsi pool error path again

2009-05-02T17:24:15+00:00

upstream commit: fd6e1c14b73dbab89cb76af895d5612e4a8b5522

Le lundi 30 mars 2009, Chris Wright a écrit :
> q->queue could be ERR_PTR(-ENOMEM) which will break unwinding
> on error.  Make iscsi_pool_free more defensive.
>

Making the freeing of q->queue dependent on q->pool being set looks
really weird (although it is correct at the moment. But this seems
to be fixable in a much simpler way.

With the benefit that only the error case is slowed down. In both
cases we have a problem if q->queue contains an error value but it's
not -ENOMEM. Apparently this can't happen today, but it doesn't feel
right to assume this will always be true. Maybe it's the right time
to fix this as well.

Signed-off-by: Mike Christie 
Signed-off-by: James Bottomley 
[chrisw: this is a fixlet to f474a37b, also in -stable]
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

SCSI: libiscsi: fix iscsi pool error path

2009-05-02T17:24:13+00:00

upstream commit: f474a37bc48667595b5653a983b635c95ed82a3b

Memory freeing in iscsi_pool_free() looks wrong to me. Either q->pool
can be NULL and this should be tested before dereferencing it, or it
can't be NULL and it shouldn't be tested at all. As far as I can see,
the only case where q->pool is NULL is on early error in
iscsi_pool_init(). One possible way to fix the bug is thus to not
call iscsi_pool_free() in this case (nothing needs to be freed anyway)
and then we can get rid of the q->pool check.

Signed-off-by: Jean Delvare 
Signed-off-by: Mike Christie 
Signed-off-by: James Bottomley 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

SCSI: sd: revive sd_index_lock

2009-03-17T00:52:47+00:00

commit 4034cc68157bfa0b6622efe368488d3d3e20f4e6 upstream.

Commit f27bac2761cab5a2e212dea602d22457a9aa6943 which converted sd to
use ida instead of idr incorrectly removed sd_index_lock around id
allocation and free.  idr/ida do have internal locks but they protect
their free object lists not the allocation itself.  The caller is
responsible for that.  This missing synchronization led to the same id
being assigned to multiple devices leading to oops.

Reported and tracked down by Stuart Hayes of Dell.

Signed-off-by: Tejun Heo 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: hptiop: Add new PCI device ID

2009-03-17T00:52:47+00:00

commit b73a77494292b930642fbf87de3e3196593f7593 upstream.

Signed-off-by: HighPoint Linux Team 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: libiscsi: fix iscsi pool leak

2009-02-20T22:36:57+00:00

commit 2f5899a39dcffb404c9a3d06ad438aff3e03bf04 upstream.

I am not sure what happened. It looks like we have always leaked
the q->queue that is allocated from the kfifo_init call. nab finally
noticed that we were leaking and this patch fixes it by adding a
kfree call to iscsi_pool_free. kfifo_free is not used per kfifo_init's
instructions to use kfree.

Signed-off-by: Mike Christie 
Signed-off-by: James Bottomley 
Cc: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman