linux-toradex.git/block, branch v3.2.11-rt20

softirq: Check preemption after reenabling interrupts

2012-03-14T15:50:16+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-03-14T15:50:10+00:00

Signed-off-by: Thomas Gleixner

block: Shorten interrupt disabled regions

2012-03-14T15:49:41+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

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

block, cfq: fix empty queue crash caused by request merge

2011-12-16T13:04:23+00:00

All requests of a queue could be merged to other requests of other queue.
Such queue will not have request in it, but it's in service tree. This
will cause kernel oops.
I encounter a BUG_ON() in cfq_dispatch_request() with next patch, but the
issue should exist without the patch.

Signed-off-by: Shaohua Li 
Signed-off-by: Jens Axboe

block: don't kick empty queue in blk_drain_queue()

2011-12-15T19:03:04+00:00

While probing, fd sets up queue, probes hardware and tears down the
queue if probing fails.  In the process, blk_drain_queue() kicks the
queue which failed to finish initialization and fd is unhappy about
that.

  floppy0: no floppy controllers found
  ------------[ cut here ]------------
  WARNING: at drivers/block/floppy.c:2929 do_fd_request+0xbf/0xd0()
  Hardware name: To Be Filled By O.E.M.
  VFS: do_fd_request called on non-open device
  Modules linked in:
  Pid: 1, comm: swapper Not tainted 3.2.0-rc4-00077-g5983fe2 #2
  Call Trace:
   [] warn_slowpath_common+0x7a/0xb0
   [] warn_slowpath_fmt+0x41/0x50
   [] do_fd_request+0xbf/0xd0
   [] blk_drain_queue+0x65/0x80
   [] blk_cleanup_queue+0xe3/0x1a0
   [] floppy_init+0xdeb/0xe28
   [] ? daring+0x6b/0x6b
   [] do_one_initcall+0x3f/0x170
   [] kernel_init+0x9d/0x11e
   [] ? schedule_tail+0x22/0xa0
   [] kernel_thread_helper+0x4/0x10
   [] ? start_kernel+0x2be/0x2be
   [] ? gs_change+0xb/0xb

Avoid it by making blk_drain_queue() kick queue iff dispatch queue has
something on it.

Signed-off-by: Tejun Heo 
Reported-by: Ralf Hildebrandt 
Reported-by: Wu Fengguang 
Tested-by: Sergei Trofimovich 
Signed-off-by: Jens Axboe