linux-stable.git/block, branch linux-2.6.32.y

scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND

2015-05-24T08:10:54+00:00

commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.

When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.

CC: Jens Axboe 
CC: linux-scsi@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara 

Fixed up the, now unused, out label.

Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings 
(cherry picked from commit d73b032b63e8967462e1cf5763858ed89e97880f)

Signed-off-by: Willy Tarreau

block: Fix blk_execute_rq_nowait() dead queue handling

2014-12-13T14:16:19+00:00

commit e81ca6fe85b77109a32489a5db82f575d51dfc98 upstream.

If the queue is dead blk_execute_rq_nowait() doesn't invoke the done()
callback function. That will result in blk_execute_rq() being stuck
in wait_for_completion(). Avoid this by initializing rq->end_io to the
done() callback before we check the queue state. Also, make sure the
queue lock is held around the invocation of the done() callback. Found
this through source code review.

Signed-off-by: Muthukumar Ratty 
Signed-off-by: Bart Van Assche 
Reviewed-by: Tejun Heo 
Acked-by: Jens Axboe 
Signed-off-by: James Bottomley 
[bwh: Backported to 2.6.32: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

block: add missing blk_queue_dead() checks

2014-12-13T14:16:19+00:00

commit 8ba61435d73f2274e12d4d823fde06735e8f6a54 upstream.

blk_insert_cloned_request(), blk_execute_rq_nowait() and
blk_flush_plug_list() either didn't check whether the queue was dead
or did it without holding queue_lock.  Update them so that dead state
is checked while holding queue_lock.

AFAICS, this plugs all holes (requeue doesn't matter as the request is
transitioning atomically from in_flight to queued).

Signed-off-by: Tejun Heo 
Signed-off-by: Jens Axboe 
[bwh: Backported to 2.6.32:
 - Drop inapplicable changes to queue_unplugged() and
   blk_flush_plug_list()
 - We don't have blk_queue_dead() so open-code it
 - Adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

fix crash in scsi_dispatch_cmd()

2013-06-10T09:42:49+00:00

USB surprise removal of sr is triggering an oops in
scsi_dispatch_command().  What seems to be happening is that USB is
hanging on to a queue reference until the last close of the upper
device, so the crash is caused by surprise remove of a mounted CD
followed by attempted unmount.

The problem is that USB doesn't issue its final commands as part of
the SCSI teardown path, but on last close when the block queue is long
gone.  The long term fix is probably to make sr do the teardown in the
same way as sd (so remove all the lower bits on ejection, but keep the
upper disk alive until last close of user space).  However, the
current oops can be simply fixed by not allowing any commands to be
sent to a dead queue.

Cc: stable@kernel.org
Signed-off-by: James Bottomley 
(cherry picked from commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1)
Cc: Thomas Bork 
Signed-off-by: Willy Tarreau

scsi: Silence unnecessary warnings about ioctl to partition

2013-06-10T09:42:48+00:00

commit 6d9359280753d2955f86d6411047516a9431eb51 upstream.

Sometimes, warnings about ioctls to partition happen often enough that they
form majority of the warnings in the kernel log and users complain. In some
cases warnings are about ioctls such as SG_IO so it's not good to get rid of
the warnings completely as they can ease debugging of userspace problems
when ioctl is refused.

Since I have seen warnings from lots of commands, including some proprietary
userspace applications, I don't think disallowing the ioctls for processes
with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.

CC: Paolo Bonzini 
CC: James Bottomley 
CC: linux-scsi@vger.kernel.org
Acked-by: Paolo Bonzini 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.2: use ENOTTY, not ENOIOCTLCMD]
Signed-off-by: Ben Hutchings 
(cherry picked from commit f45c9a6eec20cd712421c442785e7a4e9215a230)
Cc: Thomas Bork 
Signed-off-by: Willy Tarreau

Revert "block: improve queue_should_plug() by looking at IO depths"

2013-06-10T09:42:11+00:00

This reverts commit fb1e75389bd06fd5987e9cda1b4e0305c782f854.

"Benjamin S."  reports that the patch in question
causes a big drop in sequential throughput for him, dropping from
200MB/sec down to only 70MB/sec.

Needs to be investigated more fully, for now lets just revert the
offending commit.

Conflicts:

	include/linux/blkdev.h

Signed-off-by: Jens Axboe 
(cherry picked from commit 79da0644a8e0838522828f106e4049639eea6baf)
Cc: Thomas Bork 
Signed-off-by: Willy Tarreau

block: Fix io_context leak after failure of clone with CLONE_IO

2012-10-07T21:37:22+00:00

commit b69f2292063d2caf37ca9aec7d63ded203701bf3 upstream

With CLONE_IO, parent's io_context->nr_tasks is incremented, but never
decremented whenever copy_process() fails afterwards, which prevents
exit_io_context() from calling IO schedulers exit functions.

Give a task_struct to exit_io_context(), and call exit_io_context() instead of
put_io_context() in copy_process() cleanup path.

Signed-off-by: Louis Rilling 
Signed-off-by: Jens Axboe 
Signed-off-by: Willy Tarreau

block: Fix io_context leak after clone with CLONE_IO

2012-10-07T21:37:22+00:00

commit 61cc74fbb87af6aa551a06a370590c9bc07e29d9 upstream

With CLONE_IO, copy_io() increments both ioc->refcount and ioc->nr_tasks.
However exit_io_context() only decrements ioc->refcount if ioc->nr_tasks
reaches 0.

Always call put_io_context() in exit_io_context().

Signed-off-by: Louis Rilling 
Signed-off-by: Jens Axboe 
Signed-off-by: Willy Tarreau

bsg: fix sysfs link remove warning

2012-03-17T10:14:48+00:00

BugLink: http://bugs.launchpad.net/bugs/946928

We create "bsg" link if q->kobj.sd is not NULL, so remove it only
when the same condition is true.

Fixes:

WARNING: at fs/sysfs/inode.c:323 sysfs_hash_and_remove+0x2b/0x77()
sysfs: can not remove 'bsg', no directory
Call Trace:
  [] warn_slowpath_common+0x6a/0x7f
  [] ? sysfs_hash_and_remove+0x2b/0x77
  [] warn_slowpath_fmt+0x2b/0x2f
  [] sysfs_hash_and_remove+0x2b/0x77
  [] sysfs_remove_link+0x20/0x23
  [] bsg_unregister_queue+0x40/0x6d
  [] __scsi_remove_device+0x31/0x9d
  [] scsi_forget_host+0x41/0x52
  [] scsi_remove_host+0x71/0xe0
  [] quiesce_and_remove_host+0x51/0x83 [usb_storage]
  [] usb_stor_disconnect+0x18/0x22 [usb_storage]
  [] usb_unbind_interface+0x4e/0x109
  [] __device_release_driver+0x6b/0xa6
  [] device_release_driver+0x17/0x22
  [] bus_remove_device+0xd6/0xe6
  [] device_del+0xf2/0x137
  [] usb_disable_device+0x94/0x1a0

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: Jens Axboe 
(cherry picked from commit 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3)

Signed-off-by: Tim Gardner 
Signed-off-by: Willy Tarreau

block: fail SCSI passthrough ioctls on partition devices

2012-02-03T17:26:52+00:00

commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
  and -ENOIOCTLCMD from sd_compat_ioctl. ]

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds 
[bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
 ENOTTY, so we must return ENOTTY directly]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman