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

qla2xxx: Correct (again) overflow during dump-processing on large-memory ISP23xx parts.

2009-07-02T23:40:57+00:00

commit e18e963b7e533149676b5d387d0a56160df9f111 upstream.

Commit 7b867cf76fbcc8d77867cbec6f509f71dce8a98f ([SCSI] qla2xxx:
Refactor qla data structures) inadvertently reverted
e792121ec85672c1fa48f79d13986a3f4f56c590 ([SCSI] qla2xxx: Correct
overflow during dump-processing on large-memory ISP23xx parts.).

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

3w-xxxx: scsi_dma_unmap fix

2009-06-15T16:40:15+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: sg: fix q->queue_lock on scsi_error_handler path

2009-04-27T17:37:02+00:00

upstream commit: 015640edb1f346e0b2eda703587c4cd1c310ec1d

sg_rq_end_io() is called via rq->end_io. In some rare cases,
sg_rq_end_io calls blk_put_request/blk_rq_unmap_user (when a program
issuing a command has gone before the command completion; e.g. by
interrupting a program issuing a command before the command
completes).

We can't call blk_put_request/blk_rq_unmap_user in interrupt so the
commit c96952ed7031e7c576ecf90cf95b8ec099d5295a uses
execute_in_process_context().

The problem is that scsi_error_handler() calls rq->end_io too. We
can't call blk_put_request/blk_rq_unmap_user too in this path (we hold
q->queue_lock).

To avoid the above problem, in these rare cases, this patch always
uses schedule_work() instead of execute_in_process_context().

Signed-off-by: FUJITA Tomonori 
Acked-by: Douglas Gilbert 
Cc: Stable Tree 
Signed-off-by: James Bottomley 
Signed-off-by: Chris Wright

SCSI: sg: avoid blk_put_request/blk_rq_unmap_user in interrupt

2009-04-27T17:37:02+00:00

upstream commit: c96952ed7031e7c576ecf90cf95b8ec099d5295a

This fixes the following oops:

http://marc.info/?l=linux-kernel&m=123316111415677&w=2

You can reproduce this bug by interrupting a program before a sg
response completes. This leads to the special sg state (the orphan
state), then sg calls blk_put_request in interrupt (rq->end_io).

The above bug report shows the recursive lock problem because sg calls
blk_put_request in interrupt. We could call __blk_put_request here
instead however we also need to handle blk_rq_unmap_user here, which
can't be called in interrupt too.

In the orphan state, we don't need to care about the data transfer
(the program revoked the command) so adding 'just free the resource'
mode to blk_rq_unmap_user is a possible option.

I prefer to avoid complicating the blk mapping API when possible. I
change the orphan state to call sg_finish_rem_req via
execute_in_process_context. We hold sg_fd->kref so sg_fd doesn't go
away until keventd_wq finishes our work. copy_from_user/to_user fails
so blk_rq_unmap_user just frees the resource without the data
transfer.

Signed-off-by: FUJITA Tomonori 
Acked-by: Douglas Gilbert 
Signed-off-by: James Bottomley 
Signed-off-by: Chris Wright

SCSI: sg: fix races with ioctl(SG_IO)

2009-04-27T17:37:02+00:00

upstream commit: a2dd3b4cea335713b58996bb07b3abcde1175f47

sg_io_owned needs to be set before the command is sent to the midlevel;
otherwise, a quickly-completing command may cause a different CPU
to see "srp->done == 1 && !srp->sg_io_owned", which would lead to
incorrect behavior.

Check srp->done and set srp->orphan while holding rq_list_lock to
prevent races with sg_rq_end_io().

There is no need to check sfp->closed from read/write/ioctl/poll/etc.
since the kernel guarantees that this won't happen.

The usefulness of sg_srp_done() was questionable before; now it is
definitely not needed.

Signed-off-by: Tony Battersby 
Acked-by: Douglas Gilbert 
Signed-off-by: James Bottomley 
Signed-off-by: Chris Wright

SCSI: sg: fix races during device removal

2009-04-27T17:37:02+00:00

upstream commit: c6517b7942fad663cc1cf3235cbe4207cf769332

sg has the following problems related to device removal:

* opening a sg fd races with removing a device
* closing a sg fd races with removing a device
* /proc/scsi/sg/* access races with removing a device
* command completion races with removing a device
* command completion races with closing a sg fd
* can rmmod sg with active commands

These problems can cause kernel oopses, memory-use-after-free, or
double-free errors.  This patch fixes these problems by using krefs
to manage the lifetime of sg_device and sg_fd.

Each command submitted to the midlevel holds a reference to sg_fd
until the completion callback.  This ensures that sg_fd doesn't go
away if the fd is closed with commands still outstanding.

sg_fd gets the reference of sg_device (with scsi_device) and also
makes sure that the sg module doesn't go away.

/proc/scsi/sg/* functions don't play nicely with krefs because they
give information about sg_fds which have been closed but not yet
freed due to still having outstanding commands and sg_devices which
have been removed but not yet freed due to still being referenced
by one or more sg_fds.  To deal with this safely without removing
functionality, /proc functions now access sg_device and sg_fd while
holding a lock instead of using kref_get()/kref_put().

Signed-off-by: Tony Battersby 
Acked-by: Douglas Gilbert 
Signed-off-by: James Bottomley 
[chrisw: big for -stable, helps fix real bug, and made it through rc2 upstream]
Signed-off-by: Chris Wright

SCSI: libiscsi: fix iscsi pool error path

2009-04-27T17:36:59+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

SCSI: libiscsi: fix iscsi pool error path

2009-04-27T17:36:59+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

SCSI: sg: fix iovec bugs introduced by the block layer conversion

2009-04-27T17:36:53+00:00

upstream commit: 0fdf96b67ac2649cc1ddb29b316a0db11586c6a8

- needs to use copy_from_user for iovec before passing it to
blk_rq_map_user_iov().

- before the block layer conversion, if ->dxfer_len and sum of iovec
disagrees, the shorter one wins. However, currently sg returns
-EINVAL. This restores the old behavior.

Signed-off-by: FUJITA Tomonori 
Acked-by: Douglas Gilbert 
Cc: stable@kernel.org
Signed-off-by: James Bottomley 
Signed-off-by: Chris Wright

ARM: cumana: Fix a long standing bogon

2009-04-02T20:55:18+00:00

upstream commit: ecbf61e7357d5c7047c813edd6983902d158688c

Should be using strncmp as the data from user space may be unterminated

(Bug #8004)

Signed-off-by: Alan Cox 
Signed-off-by: Chris Wright