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

SCSI: sg: avoid blk_put_request/blk_rq_unmap_user in interrupt

2009-05-02T17:56:56+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 
Signed-off-by: Greg Kroah-Hartman

SCSI: sg: fix races with ioctl(SG_IO)

2009-05-02T17:56:55+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 
Signed-off-by: Greg Kroah-Hartman

SCSI: sg: fix races during device removal

2009-05-02T17:56:54+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 
Signed-off-by: Greg Kroah-Hartman

SCSI: libiscsi: fix iscsi pool error path again

2009-05-02T17:56:48+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:56:48+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:32:02+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:32:02+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:40:19+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

ibmvfc: Improve async event handling

2009-01-18T18:44:05+00:00

commit d2131b33c7e07c2905ee2f2321cc4dae1928c483 upstream.

While doing various error injection testing, such as cable
pulls and target moves, some issues were observed in handling
these events. This patch improves the way these events are handled
by increasing the delay waiting for the fabric to settle and also
changes the behavior of Link Up to break the CRQ to ensure everything
gets cleaned up properly on the VIOS.

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

ibmvfc: Delay NPIV login retry and add retries

2009-01-18T18:44:05+00:00

commit 1c41fa8288277e76785acb50f52bb2f39509f903 upstream.

Adds a delay prior to retrying a failed NPIV login. This fixes
a scenario if the backing fibre channel adapter is getting reset
due to an EEH event, NPIV login will fail. Currently, ibmvfc
retries three times very quickly, resets the CRQ and tries one
more time. If the adapter is getting reset due to EEH, this isn't
enough time. This adds a delay prior to retrying a failed NPIV
login and also increments the number of retries.

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