linux-toradex.git/block, branch v3.0.79

block: avoid using uninitialized value in from queue_var_store

2013-04-12T16:18:09+00:00

commit c678ef5286ddb5cf70384ad5af286b0afc9b73e1 upstream.

As found by gcc-4.8, the QUEUE_SYSFS_BIT_FNS macro creates functions
that use a value generated by queue_var_store independent of whether
that value was set or not.

block/blk-sysfs.c: In function 'queue_store_nonrot':
block/blk-sysfs.c:244:385: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]

Unlike most other such warnings, this one is not a false positive,
writing any non-number string into the sysfs files indeed has
an undefined result, rather than returning an error.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

scsi: Silence unnecessary warnings about ioctl to partition

2012-12-10T18:45:08+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.

Acked-by: Paolo Bonzini 
CC: James Bottomley 
CC: linux-scsi@vger.kernel.org
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Cc: Satoru Takeuchi 
Signed-off-by: Greg Kroah-Hartman

Revert "block: fix request_queue->flags initialization"

2012-10-22T15:33:26+00:00

This reverts commit 2101aa5bb084931f22fa08cacd6d69c80afade7f which is
commit 60ea8226cbd5c8301f9a39edc574ddabcb8150e0 upstream.

To quote Ben:
	This is not needed, as there is no QUEUE_FLAG_BYPASS in 3.0.y.

To quote Tejun:
	I don't think it will break anything as it simply changes
	assignment to |= to avoid overwriting existing flags.  That
	said, any patch can break anything, so if possible it would be
	better to drop for 3.0.y.

So I'll revert this to be safe.

Cc: Tejun Heo 
Cc: Vivek Goyal 
Cc: Jens Axboe 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

block: fix request_queue->flags initialization

2012-10-21T16:17:10+00:00

commit 60ea8226cbd5c8301f9a39edc574ddabcb8150e0 upstream.

A queue newly allocated with blk_alloc_queue_node() has only
QUEUE_FLAG_BYPASS set.  For request-based drivers,
blk_init_allocated_queue() is called and q->queue_flags is overwritten
with QUEUE_FLAG_DEFAULT which doesn't include BYPASS even though the
initial bypass is still in effect.

In blk_init_allocated_queue(), or QUEUE_FLAG_DEFAULT to q->queue_flags
instead of overwriting.

Signed-off-by: Tejun Heo 
Acked-by: Vivek Goyal 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: fix buffer overflow when printing partition UUIDs

2012-06-01T07:12:52+00:00

commit 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 upstream.

6d1d8050b4bc8 "block, partition: add partition_meta_info to hd_struct"
added part_unpack_uuid() which assumes that the passed in buffer has
enough space for sprintfing "%pU" - 37 characters including '\0'.

Unfortunately, b5af921ec0233 "init: add support for root devices
specified by partition UUID" supplied 33 bytes buffer to the function
leading to the following panic with stackprotector enabled.

  Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e

  [] panic+0xba/0x1c6
  [] ? printk_all_partitions+0x259/0x26xb
  [] __stack_chk_fail+0x1b/0x20
  [] printk_all_paritions+0x259/0x26xb
  [] mount_block_root+0x1bc/0x27f
  [] mount_root+0x57/0x5b
  [] prepare_namespace+0x13d/0x176
  [] ? release_tgcred.isra.4+0x330/0x30
  [] kernel_init+0x155/0x15a
  [] ? schedule_tail+0x27/0xb0
  [] kernel_thread_helper+0x5/0x10
  [] ? start_kernel+0x3c5/0x3c5
  [] ? gs_change+0x13/0x13

Increase the buffer size, remove the dangerous part_unpack_uuid() and
use snprintf() directly from printk_all_partitions().

Signed-off-by: Tejun Heo 
Reported-by: Szymon Gruszczynski 
Cc: Will Drewry 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

Block: use a freezable workqueue for disk-event polling

2012-03-19T15:57:59+00:00

commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 upstream.

This patch (as1519) fixes a bug in the block layer's disk-events
polling.  The polling is done by a work routine queued on the
system_nrt_wq workqueue.  Since that workqueue isn't freezable, the
polling continues even in the middle of a system sleep transition.

Obviously, polling a suspended drive for media changes and such isn't
a good thing to do; in the case of USB mass-storage devices it can
lead to real problems requiring device resets and even re-enumeration.

The patch fixes things by creating a new system-wide, non-reentrant,
freezable workqueue and using it for disk-events polling.

Signed-off-by: Alan Stern 
Acked-by: Tejun Heo 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: fix __blkdev_get and add_disk race condition

2012-03-19T15:57:58+00:00

commit 9f53d2fe815b4011ff930a7b6db98385d45faa68 upstream.

The following situation might occur:

__blkdev_get:			add_disk:

				register_disk()
get_gendisk()

disk_block_events()
	disk->ev == NULL

				disk_add_events()

__disk_unblock_events()
	disk->ev != NULL
	--ev->block

Then we unblock events, when they are suppose to be blocked. This can
trigger events related block/genhd.c warnings, but also can crash in
sd_check_events() or other places.

I'm able to reproduce crashes with the following scripts (with
connected usb dongle as sdb disk).


DEV=/dev/sdb
ENABLE=/sys/bus/usb/devices/1-2/bConfigurationValue

function stop_me()
{
	for i in `jobs -p` ; do kill $i 2> /dev/null ; done
	exit
}

trap stop_me SIGHUP SIGINT SIGTERM

for ((i = 0; i < 10; i++)) ; do
	while true; do fdisk -l $DEV  2>&1 > /dev/null ; done &
done

while true ; do
echo 1 > $ENABLE
sleep 1
echo 0 > $ENABLE
done


I use the script to verify patch fixing oops in sd_revalidate_disk
http://marc.info/?l=linux-scsi&m=132935572512352&w=2
Without Jun'ichi Nomura patch titled "Fix NULL pointer dereference in
sd_revalidate_disk" or this one, script easily crash kernel within
a few seconds. With both patches applied I do not observe crash.
Unfortunately after some time (dozen of minutes), script will hung in:

[ 1563.906432]  [] schedule_timeout_uninterruptible+0x15/0x20
[ 1563.906437]  [] msleep+0x15/0x20
[ 1563.906443]  [] blk_drain_queue+0x32/0xd0
[ 1563.906447]  [] blk_cleanup_queue+0xd0/0x170
[ 1563.906454]  [] scsi_free_queue+0x3f/0x60
[ 1563.906459]  [] __scsi_remove_device+0x6e/0xb0
[ 1563.906463]  [] scsi_forget_host+0x4f/0x60
[ 1563.906468]  [] scsi_remove_host+0x5a/0xf0
[ 1563.906482]  [] quiesce_and_remove_host+0x5b/0xa0 [usb_storage]
[ 1563.906490]  [] usb_stor_disconnect+0x13/0x20 [usb_storage]

Anyway I think this patch is some step forward.

As drawback, I do not teardown on sysfs file create error, because I do
not know how to nullify disk->ev (since it can be used). However add_disk
error handling practically does not exist too, and things will work
without this sysfs file, except events will not be exported to user
space.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

bsg: fix sysfs link remove warning

2012-03-12T17:32:57+00:00

commit 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3 upstream.

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 
Signed-off-by: Tim Gardner 
Signed-off-by: Greg Kroah-Hartman

block: fail SCSI passthrough ioctls on partition devices

2012-01-26T01:24:54+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 
Signed-off-by: Greg Kroah-Hartman

block: add and use scsi_blk_cmd_ioctl

2012-01-26T01:24:54+00:00

commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.

Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman