linux-toradex.git/block, branch v3.2.15-rt24

softirq: Check preemption after reenabling interrupts

2012-04-10T21:37:37+00:00

raise_softirq_irqoff() disables interrupts and wakes the softirq
daemon, but after reenabling interrupts there is no preemption check,
so the execution of the softirq thread might be delayed arbitrarily.

In principle we could add that check to local_irq_enable/restore, but
that's overkill as the rasie_softirq_irqoff() sections are the only
ones which show this behaviour.

Reported-by: Carsten Emde 
Signed-off-by: Thomas Gleixner 
Cc: stable-rt@vger.kernel.org

fs-block-rt-support.patch

2012-04-10T21:37:24+00:00

Signed-off-by: Thomas Gleixner

block: Shorten interrupt disabled regions

2012-04-10T21:36:23+00:00

Moving the blk_sched_flush_plug() call out of the interrupt/preempt
disabled region in the scheduler allows us to replace
local_irq_save/restore(flags) by local_irq_disable/enable() in
blk_flush_plug().

Now instead of doing this we disable interrupts explicitely when we
lock the request_queue and reenable them when we drop the lock. That
allows interrupts to be handled when the plug list contains requests
for more than one queue.

Aside of that this change makes the scope of the irq disabled region
more obvious. The current code confused the hell out of me when
looking at:

 local_irq_save(flags);
   spin_lock(q->queue_lock);
   ...
   queue_unplugged(q...);
     scsi_request_fn();
       spin_unlock(q->queue_lock);
       spin_lock(shost->host_lock);
       spin_unlock_irq(shost->host_lock);

-------------------^^^ ????

       spin_lock_irq(q->queue_lock);
       spin_unlock(q->lock);
 local_irq_restore(flags);

Also add a comment to __blk_run_queue() documenting that
q->request_fn() can drop q->queue_lock and reenable interrupts, but
must return with q->queue_lock held and interrupts disabled.

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Tejun Heo 
Cc: Jens Axboe 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/20110622174919.025446432@linutronix.de
Signed-off-by: Thomas Gleixner

Block: use a freezable workqueue for disk-event polling

2012-03-19T16:02:34+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-19T16:02:34+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-12T19:31:36+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-26T00:13:42+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-26T00:13:42+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

block: fix blk_queue_end_tag()

2011-12-29T08:16:28+00:00

Commit 5e081591 "block: warn if tag is greater than real_max_depth"
cleaned up blk_queue_end_tag() to warn when the tag is truly invalid
(greater than real_max_depth).  However, it changed behavior in the tag <
max_depth case to not end the request.  Leading to triggering of
BUG_ON(blk_queued_rq(rq)) in the request completion path:

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

In order to allow blk_queue_resize_tags() to shrink the tag space
blk_queue_end_tag() must always complete tags with a value less than
real_max_depth regardless of the current max_depth.  The comment about
"handling the shrink case" seems to be what prompted changes in this
space, so remove it and BUG on all invalid tags (made even simpler by
Matthew's suggestion to use an unsigned compare).

Signed-off-by: Dan Williams 
Cc: Tao Ma 
Cc: Matthew Wilcox 
Reported-by: Meelis Roos 
Reported-by: Ed Nadolski 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Jens Axboe

block: re-use existing 'reading' variable instead of checking direction again

2011-12-21T14:27:24+00:00

Signed-off-by: majianpeng 
Signed-off-by: Jens Axboe