linux-stable.git/drivers/block, branch v3.16.46

xen-blkback: don't leak stack data via response ring

2017-07-18T17:40:40+00:00

commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341 upstream.

Rather than constructing a local structure instance on the stack, fill
the fields directly on the shared ring, just like other backends do.
Build on the fact that all response structure flavors are actually
identical (the old code did make this assumption too).

This is XSA-216.


Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

zram: do not use copy_page with non-page aligned address

2017-07-18T17:40:35+00:00

commit d72e9a7a93e4f8e9e52491921d99e0c8aa89eb4e upstream.

The copy_page is optimized memcpy for page-alinged address.  If it is
used with non-page aligned address, it can corrupt memory which means
system corruption.  With zram, it can happen with

1. 64K architecture
2. partial IO
3. slub debug

Partial IO need to allocate a page and zram allocates it via kmalloc.
With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
address.  And finally, copy_page(mem, cmem) corrupts memory.

So, this patch changes it to memcpy.

Actuaully, we don't need to change zram_bvec_write part because zsmalloc
returns page-aligned address in case of PAGE_SIZE class but it's not
good to rely on the internal of zsmalloc.

Note:
 When this patch is merged to stable, clear_page should be fixed, too.
 Unfortunately, recent zram removes it by "same page merge" feature so
 it's hard to backport this patch to -stable tree.

I will handle it when I receive the mail from stable tree maintainer to
merge this patch to backport.

Fixes: 42e99bd ("zram: optimize memory operations with clear_page()/copy_page()")
Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim 
Cc: Sergey Senozhatsky 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16, replacing clear_page() as advised]
Signed-off-by: Ben Hutchings

nbd: only set MSG_MORE when we have more to send

2017-03-16T02:27:03+00:00

commit d61b7f972dab2a7d187c38254845546dfc8eed85 upstream.

A user noticed that write performance was horrible over loopback and we
traced it to an inversion of when we need to set MSG_MORE.  It should be
set when we have more bvec's to send, not when we are on the last bvec.
This patch made the test go from 20 iops to 78k iops.

Signed-off-by: Josef Bacik 
Fixes: 429a787be679 ("nbd: fix use-after-free of rq/bio in the xmit path")
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

nbd: fix use-after-free of rq/bio in the xmit path

2017-03-16T02:27:02+00:00

commit 429a787be6793554ee02aacc7e1f11ebcecc4453 upstream.

For writes, we can get a completion in while we're still iterating
the request and bio chain. If that happens, we're reading freed
memory and we can crash.

Break out after the last segment and avoid having the iterator
read freed memory.

Reviewed-by: Josef Bacik 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

nvme/pci: Don't free queues on error

2017-02-23T03:54:35+00:00

commit d48756228ee9161ac8836b346589a43fabdc9f3c upstream.

The nvme_remove function tears down all allocated resources in the correct
order, so no need to free queues on error during initialization. This
fixes possible use-after-free errors when queues are still associated
with a blk-mq hctx.

Reported-by: Scott Bauer 
Tested-by: Scott Bauer 
Signed-off-by: Keith Busch 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.16:
 - Adjust filename, context
 - Only nvme_setup_io_queues() needs to be fixed]
Signed-off-by: Ben Hutchings

rbd: fix rbd map vs notify races

2016-06-15T20:29:28+00:00

commit 811c6688774613a78bfa020f64b570b73f6974c8 upstream.

A while ago, commit 9875201e1049 ("rbd: fix use-after free of
rbd_dev->disk") fixed rbd unmap vs notify race by introducing
an exported wrapper for flushing notifies and sticking it into
do_rbd_remove().

A similar problem exists on the rbd map path, though: the watch is
registered in rbd_dev_image_probe(), while the disk is set up quite
a few steps later, in rbd_dev_device_setup().  Nothing prevents
a notify from coming in and crashing on a NULL rbd_dev->disk:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
    Call Trace:
     [] rbd_watch_cb+0x34/0x180 [rbd]
     [] do_event_work+0x40/0xb0 [libceph]
     [] process_one_work+0x17b/0x470
     [] worker_thread+0x11b/0x400
     [] ? rescuer_thread+0x400/0x400
     [] kthread+0xcf/0xe0
     [] ? finish_task_switch+0x53/0x170
     [] ? kthread_create_on_node+0x140/0x140
     [] ret_from_fork+0x58/0x90
     [] ? kthread_create_on_node+0x140/0x140
    RIP  [] rbd_dev_refresh+0xfa/0x180 [rbd]

If an error occurs during rbd map, we have to error out, potentially
tearing down a watch.  Just like on rbd unmap, notifies have to be
flushed, otherwise rbd_watch_cb() may end up trying to read in the
image header after rbd_dev_image_release() has run:

    Assertion failure in rbd_dev_header_info() at line 4722:

     rbd_assert(rbd_image_format_valid(rbd_dev->image_format));

    Call Trace:
     [] ? rbd_parent_request_create+0x150/0x150
     [] rbd_dev_refresh+0x59/0x390
     [] rbd_watch_cb+0x69/0x290
     [] do_event_work+0x10f/0x1c0
     [] process_one_work+0x689/0x1a80
     [] ? process_one_work+0x5e7/0x1a80
     [] ? finish_task_switch+0x225/0x640
     [] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
     [] worker_thread+0xd9/0x1320
     [] ? process_one_work+0x1a80/0x1a80
     [] kthread+0x21d/0x2e0
     [] ? kthread_stop+0x550/0x550
     [] ret_from_fork+0x22/0x40
     [] ? kthread_stop+0x550/0x550
    RIP  [] rbd_dev_header_info+0xa19/0x1e30

To fix this, a) check if RBD_DEV_FLAG_EXISTS is set before calling
revalidate_disk(), b) move ceph_osdc_flush_notifies() call into
rbd_dev_header_unwatch_sync() to cover rbd map error paths and c) turn
header read-in into a critical section.  The latter also happens to
take care of rbd map foo@bar vs rbd snap rm foo@bar race.

Fixes: http://tracker.ceph.com/issues/15490

Signed-off-by: Ilya Dryomov 
Reviewed-by: Josh Durgin 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

paride: make 'verbose' parameter an 'int' again

2016-04-30T22:06:00+00:00

commit dec63a4dec2d6d01346fd5d96062e67c0636852b upstream.

gcc-6.0 found an ancient bug in the paride driver, which had a
"module_param(verbose, bool, 0);" since before 2.6.12, but actually uses
it to accept '0', '1' or '2' as arguments:

  drivers/block/paride/pd.c: In function 'pd_init_dev_parms':
  drivers/block/paride/pd.c:298:29: warning: comparison of constant '1' with boolean expression is always false [-Wbool-compare]
   #define DBMSG(msg) ((verbose>1)?(msg):NULL)

In 2012, Rusty did a cleanup patch that also changed the type of the
variable to 'bool', which introduced what is now a gcc warning.

This changes the type back to 'int' and adapts the module_param() line
instead, so it should work as documented in case anyone ever cares about
running the ancient driver with debugging.

Fixes: 90ab5ee94171 ("module_param: make bool parameters really bool (drivers & misc)")
Signed-off-by: Arnd Bergmann 
Rusty Russell 
Cc: Tim Waugh 
Cc: Sudip Mukherjee 
Cc: Jens Axboe 
Cc: Greg Kroah-Hartman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild

2016-04-30T22:05:53+00:00

commit d8a18d2d8f5de55666c6011ed175939d22c8e3d8 upstream.

Prevent standby immediate command from being issued in remove,
suspend and shutdown paths, while drive is in FTL rebuild process.

Signed-off-by: Selvan Mani 
Signed-off-by: Vignesh Gunasekaran 
Signed-off-by: Asai Thambi S P 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

mtip32xx: Remove unwanted code from taskfile error handler

2016-04-30T22:05:53+00:00

commit e35b94738a2f7caa12017f69ef385cb6b8028965 upstream.

Remove setting and clearing MTIP_PF_EH_ACTIVE_BIT flag in
mtip_handle_tfe() as they are redundant. Also avoid waking
up service thread from mtip_handle_tfe() because it is
already woken up in case of taskfile error.

Signed-off-by: Selvan Mani 
Signed-off-by: Rajesh Kumar Sambandam 
Signed-off-by: Asai Thambi S P 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mtip32xx: Fix broken service thread handling

2016-04-30T22:05:52+00:00

commit cfc05bd31384c4898bf2437a4de5557f3cf9803a upstream.

Service thread does not detect the need for taskfile error hanlding. Fixed the
flag condition to process taskfile error.

Signed-off-by: Selvan Mani 
Signed-off-by: Asai Thambi S P 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings