linux-stable.git/block, branch v3.16.35

bio: return EINTR if copying to user space got interrupted

2016-03-04T10:26:40+00:00

commit 2d99b55d378c996b9692a0c93dd25f4ed5d58934 upstream.

Commit 35dc248383bbab0a7203fca4d722875bc81ef091 introduced a check for
current->mm to see if we have a user space context and only copies data
if we do. Now if an IO gets interrupted by a signal data isn't copied
into user space any more (as we don't have a user space context) but
user space isn't notified about it.

This patch modifies the behaviour to return -EINTR from bio_uncopy_user()
to notify userland that a signal has interrupted the syscall, otherwise
it could lead to a situation where the caller may get a buffer with
no data returned.

This can be reproduced by issuing SG_IO ioctl()s in one thread while
constantly sending signals to it.

Fixes: 35dc248 [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
Signed-off-by: Johannes Thumshirn 
Signed-off-by: Hannes Reinecke 
Signed-off-by: Jens Axboe 
[ luis: backported to 3.16: based on Johannes' backport to 3.14 ]
Signed-off-by: Luis Henriques

SCSI: Fix NULL pointer dereference in runtime PM

2016-01-11T10:50:18+00:00

commit 4fd41a8552afc01054d9d9fc7f1a63c324867d27 upstream.

The routines in scsi_pm.c assume that if a runtime-PM callback is
invoked for a SCSI device, it can only mean that the device's driver
has asked the block layer to handle the runtime power management (by
calling blk_pm_runtime_init(), which among other things sets q->dev).

However, this assumption turns out to be wrong for things like the ses
driver.  Normally ses devices are not allowed to do runtime PM, but
userspace can override this setting.  If this happens, the kernel gets
a NULL pointer dereference when blk_post_runtime_resume() tries to use
the uninitialized q->dev pointer.

This patch fixes the problem by checking q->dev in block layer before
handle runtime PM. Since ses doesn't define any PM callbacks and call
blk_pm_runtime_init(), the crash won't occur.

This fixes Bugzilla #101371.
https://bugzilla.kernel.org/show_bug.cgi?id=101371

More discussion can be found from below link.
http://marc.info/?l=linux-scsi&m=144163730531875&w=2

Signed-off-by: Ken Xue 
Acked-by: Alan Stern 
Cc: Xiangliang Yu 
Cc: James E.J. Bottomley 
Cc: Jens Axboe 
Cc: Michael Terry 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques

block: Always check queue limits for cloned requests

2016-01-05T11:22:20+00:00

commit bf4e6b4e757488dee1b6a581f49c7ac34cd217f8 upstream.

When a cloned request is retried on other queues it always needs
to be checked against the queue limits of that queue.
Otherwise the calculations for nr_phys_segments might be wrong,
leading to a crash in scsi_init_sgtable().

To clarify this the patch renames blk_rq_check_limits()
to blk_cloned_rq_check_limits() and removes the symbol
export, as the new function should only be used for
cloned requests and never exported.

Cc: Mike Snitzer 
Cc: Ewan Milne 
Cc: Jeff Moyer 
Signed-off-by: Hannes Reinecke 
Fixes: e2a60da74 ("block: Clean up special command handling logic")
Acked-by: Mike Snitzer 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques

mac: validate mac_partition is within sector

2015-12-18T16:06:30+00:00

commit 02e2a5bfebe99edcf9d694575a75032d53fe1b73 upstream.

If md->signature == MAC_DRIVER_MAGIC and md->block_size == 1023, a single
512 byte sector would be read (secsize / 512). However the partition
structure would be located past the end of the buffer (secsize % 512).

Signed-off-by: Kees Cook 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques

blk-mq: fix buffer overflow when reading sysfs file of 'pending'

2015-09-28T09:21:41+00:00

commit 596f5aad2a704b72934e5abec1b1b4114c16f45b upstream.

There may be lots of pending requests so that the buffer of PAGE_SIZE
can't hold them at all.

One typical example is scsi-mq, the queue depth(.can_queue) of
scsi_host and blk-mq is quite big but scsi_device's queue_depth
is a bit small(.cmd_per_lun), then it is quite easy to have lots
of pending requests in hw queue.

This patch fixes the following warning and the related memory
destruction.

[  359.025101] fill_read_buffer: blk_mq_hw_sysfs_show+0x0/0x7d returned bad count^M
[  359.055595] irq event stamp: 15537^M
[  359.055606] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
[  359.055614] Dumping ftrace buffer:^M
[  359.055660]    (ftrace buffer empty)^M
[  359.055672] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M
[  359.055678] CPU: 4 PID: 21631 Comm: stress-ng-sysfs Not tainted 4.2.0-rc5-next-20150805 #434^M
[  359.055679] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011^M
[  359.055682] task: ffff8802161cc000 ti: ffff88021b4a8000 task.ti: ffff88021b4a8000^M
[  359.055693] RIP: 0010:[]  [] __kmalloc+0xe8/0x152^M

Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques

block: Do a full clone when splitting discard bios

2015-08-11T08:57:45+00:00

commit f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc upstream.

This fixes a data corruption bug when using discard on top of MD linear,
raid0 and raid10 personalities.

Commit 20d0189b1012 "block: Introduce new bio_split()" permits sharing
the bio_vec between the two resulting bios. That is fine for read/write
requests where the bio_vec is immutable. For discards, however, we need
to be able to attach a payload and update the bio_vec so the page can
get mapped to a scatterlist entry. Therefore the bio_vec can not be
shared when splitting discards and we must do a full clone.

Signed-off-by: Martin K. Petersen 
Reported-by: Seunguk Shin 
Tested-by: Seunguk Shin 
Cc: Seunguk Shin 
Cc: Jens Axboe 
Cc: Kent Overstreet 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques

blkcg: fix gendisk reference leak in blkg_conf_prep()

2015-08-11T08:57:43+00:00

commit 5f6c2d2b7dbb541c1e922538c49fa04c494ae3d7 upstream.

When a blkcg configuration is targeted to a partition rather than a
whole device, blkg_conf_prep fails with -EINVAL; unfortunately, it
forgets to put the gendisk ref in that case.  Fix it.

Signed-off-by: Tejun Heo 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques

bio integrity: do not assume bio_integrity_pool exists if bioset exists

2015-08-10T08:54:14+00:00

commit bb8bd38b9a1685334b73e8c62e128cbedb875867 upstream.

bio_integrity_alloc() and bio_integrity_free() assume that if a bio was
allocated from a bioset that that bioset also had its bio_integrity_pool
allocated using bioset_integrity_create().  This is a very bad
assumption given that bioset_create() and bioset_integrity_create() are
completely disjoint.  Not all callers of bioset_create() have been
trained to also call bioset_integrity_create() -- and they may not care
to be.

Fix this by falling back to kmalloc'ing 'struct bio_integrity_payload'
rather than force all bioset consumers to (wastefully) preallocate a
bio_integrity_pool that they very likely won't actually need (given the
niche nature of the current block integrity support).

Otherwise, a NULL pointer "Kernel BUG" with a trace like the following
will be observed (as seen on s390x using zfcp storage) because dm-io
doesn't use bioset_integrity_create() when creating its bioset:

    [  791.643338] Call Trace:
    [  791.643339] ([<00000003df98b848>] 0x3df98b848)
    [  791.643341]  [<00000000002c5de8>] bio_integrity_alloc+0x48/0xf8
    [  791.643348]  [<00000000002c6486>] bio_integrity_prep+0xae/0x2f0
    [  791.643349]  [<0000000000371e38>] blk_queue_bio+0x1c8/0x3d8
    [  791.643355]  [<000000000036f8d0>] generic_make_request+0xc0/0x100
    [  791.643357]  [<000000000036f9b2>] submit_bio+0xa2/0x198
    [  791.643406]  [<000003ff801f9774>] dispatch_io+0x15c/0x3b0 [dm_mod]
    [  791.643419]  [<000003ff801f9b3e>] dm_io+0x176/0x2f0 [dm_mod]
    [  791.643423]  [<000003ff8074b28a>] do_reads+0x13a/0x1a8 [dm_mirror]
    [  791.643425]  [<000003ff8074b43a>] do_mirror+0x142/0x298 [dm_mirror]
    [  791.643428]  [<0000000000154fca>] process_one_work+0x18a/0x3f8
    [  791.643432]  [<000000000015598a>] worker_thread+0x132/0x3b0
    [  791.643435]  [<000000000015d49a>] kthread+0xd2/0xd8
    [  791.643438]  [<00000000005bc0ca>] kernel_thread_starter+0x6/0xc
    [  791.643446]  [<00000000005bc0c4>] kernel_thread_starter+0x0/0xc

Signed-off-by: Mike Snitzer 
Signed-off-by: Jens Axboe 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

block: fix ext_dev_lock lockdep report

2015-06-30T16:15:25+00:00

commit 4d66e5e9b6d720d8463e11d027bd4ad91c8b1318 upstream.

 =================================
 [ INFO: inconsistent lock state ]
 4.1.0-rc7+ #217 Tainted: G           O
 ---------------------------------
 inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
 swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (ext_devt_lock){+.?...}, at: [] blk_free_devt+0x3c/0x70
 {SOFTIRQ-ON-W} state was registered at:
   [] __lock_acquire+0x461/0x1e70
   [] lock_acquire+0xb7/0x290
   [] _raw_spin_lock+0x38/0x50
   [] blk_alloc_devt+0x6d/0xd0  <-- take the lock in process context
[..]
  [] __lock_acquire+0x3fe/0x1e70
  [] ? __lock_acquire+0xe5d/0x1e70
  [] lock_acquire+0xb7/0x290
  [] ? blk_free_devt+0x3c/0x70
  [] _raw_spin_lock+0x38/0x50
  [] ? blk_free_devt+0x3c/0x70
  [] blk_free_devt+0x3c/0x70    <-- take the lock in softirq
  [] part_release+0x1c/0x50
  [] device_release+0x36/0xb0
  [] kobject_cleanup+0x7b/0x1a0
  [] kobject_put+0x30/0x70
  [] put_device+0x17/0x20
  [] delete_partition_rcu_cb+0x16c/0x180
  [] ? read_dev_sector+0xa0/0xa0
  [] rcu_process_callbacks+0x2ff/0xa90
  [] ? rcu_process_callbacks+0x2bf/0xa90
  [] __do_softirq+0xde/0x600

Neil sees this in his tests and it also triggers on pmem driver unbind
for the libnvdimm tests.  This fix is on top of an initial fix by Keith
for incorrect usage of mutex_lock() in this path: 2da78092dda1 "block:
Fix dev_t minor allocation lifetime".  Both this and 2da78092dda1 are
candidates for -stable.

Fixes: 2da78092dda1 ("block: Fix dev_t minor allocation lifetime")
Cc: Keith Busch 
Reported-by: NeilBrown 
Signed-off-by: Dan Williams 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques

blk-mq: fix CPU hotplug handling

2015-05-20T12:25:56+00:00

commit 2a34c0872adf252f23a6fef2d051a169ac796cef upstream.

hctx->tags has to be set as NULL in case that it is to be unmapped
no matter if set->tags[hctx->queue_num] is NULL or not in blk_mq_map_swqueue()
because shared tags can be freed already from another request queue.

The same situation has to be considered during handling CPU online too.
Unmapped hw queue can be remapped after CPU topo is changed, so we need
to allocate tags for the hw queue in blk_mq_map_swqueue(). Then tags
allocation for hw queue can be removed in hctx cpu online notifier, and it
is reasonable to do that after mapping is updated.

Reported-by: Dongsu Park 
Tested-by: Dongsu Park 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Luis Henriques