linux-toradex.git/block, branch imx-android-r13.2.1

Merge branch 'android-3.0' into imx_3.0.15_android

2012-02-02T08:58:05+00:00

Conflicts:
	drivers/misc/Kconfig
	drivers/misc/Makefile
	drivers/net/wireless/Makefile
	kernel/power/main.c
	sound/soc/soc-core.c

block: Always check length of all iov entries in blk_rq_map_user_iov()

2011-11-21T22:31:26+00:00

commit 6b76106d8ef31111d6fc469564b83b5f5542794f upstream.

Even after commit 5478755616ae2ef1ce144dded589b62b2a50d575
("block: check for proper length of iov entries earlier ...")
we still won't check for zero-length entries after an unaligned
entry.  Remove the break-statement, so all entries are checked.

Signed-off-by: Ben Hutchings 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: make gendisk hold a reference to its queue

2011-11-11T17:37:07+00:00

commit f992ae801a7dec34a4ed99a6598bbbbfb82af4fb upstream.

The following command sequence triggers an oops.

# mount /dev/sdb1 /mnt
# echo 1 > /sys/class/scsi_device/0\:0\:1\:0/device/delete
# umount /mnt

 general protection fault: 0000 [#1] PREEMPT SMP
 CPU 2
 Modules linked in:

 Pid: 791, comm: umount Not tainted 3.1.0-rc3-work+ #8 Bochs Bochs
 RIP: 0010:[]  [] __lock_acquire+0x389/0x1d60
...
 Call Trace:
  [] lock_acquire+0x95/0x140
  [] _raw_spin_lock+0x3b/0x50
  [] bdi_lock_two+0x5c/0x70
  [] bdev_inode_switch_bdi+0x4c/0xf0
  [] __blkdev_put+0x11b/0x1d0
  [] __blkdev_put+0x160/0x1d0
  [] blkdev_put+0x5f/0x190
  [] kill_block_super+0x4d/0x80
  [] deactivate_locked_super+0x45/0x70
  [] deactivate_super+0x4a/0x70
  [] mntput_no_expire+0xed/0x130
  [] sys_umount+0x7e/0x3a0
  [] system_call_fastpath+0x16/0x1b

This is because bdev holds on to disk but disk doesn't pin the
associated queue.  If a SCSI device is removed while the device is
still open, the sdev puts the base reference to the queue on release.
When the bdev is finally released, the associated queue is already
gone along with the bdi and bdev_inode_switch_bdi() ends up
dereferencing already freed bdi.

Even if it were not for this bug, disk not holding onto the associated
queue is very unusual and error-prone.

Fix it by making add_disk() take an extra reference to its queue and
put it on disk_release() and ensuring that disk and its fops owner are
put in that order after all accesses to the disk and queue are
complete.

Signed-off-by: Tejun Heo 
Cc: Jens Axboe 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

Merge commit 'v3.0.8' into android-3.0

2011-10-27T22:01:19+00:00

block: Free queue resources at blk_release_queue()

2011-10-03T18:41:13+00:00

commit 777eb1bf15b8532c396821774bf6451e563438f5 upstream.

A kernel crash is observed when a mounted ext3/ext4 filesystem is
physically removed. The problem is that blk_cleanup_queue() frees up
some resources eg by calling elevator_exit(), which are not checked for
in normal operation. So we should rather move these calls to the
destructor function blk_release_queue() as at that point all remaining
references are gone. However, in doing so we have to ensure that any
externally supplied queue_lock is disconnected as the driver might free
up the lock after the call of blk_cleanup_queue(),

Signed-off-by: Hannes Reinecke 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

blk-cgroup: be able to remove the record of unplugged device

2011-10-03T18:40:42+00:00

commit d11bb4462c4cc6ddd45c6927c617ad79fa6fb8fc upstream.

The bug is we're not able to remove the device from blkio cgroup's
per-device control files if it gets unplugged.

To reproduce the bug:

  # mount -t cgroup -o blkio xxx /cgroup
  # cd /cgroup
  # echo "8:0 1000" > blkio.throttle.read_bps_device
  # unplug the device
  # cat blkio.throttle.read_bps_device
  8:0	1000
  # echo "8:0 0" > blkio.throttle.read_bps_device
  -bash: echo: write error: No such device

After patching, the device removal will succeed.

Thanks for the comments of Paul, Zefan, and Vivek.

Signed-off-by: Wanlong Gao 
Cc: Li Zefan 
Cc: Paul Menage 
Acked-by: Vivek Goyal 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

Merge commit 'v3.0.1' into android-3.0

2011-08-11T01:07:59+00:00

fix crash in scsi_dispatch_cmd()

2011-08-05T04:58:36+00:00

commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 upstream.

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.

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

Merge commit 'v3.0-rc7' into android-3.0

2011-07-13T03:10:37+00:00

Merge commit 'v3.0-rc5' into android-3.0

2011-06-29T20:54:42+00:00