linux-toradex.git/drivers/block, branch v4.9.88

loop: Fix lost writes caused by missing flag

2018-03-18T10:18:50+00:00

commit 1d037577c323e5090ce281e96bc313ab2eee5be2 upstream.

The following commit:

commit aa4d86163e4e ("block: loop: switch to VFS ITER_BVEC")

replaced __do_lo_send_write(), which used ITER_KVEC iterators, with
lo_write_bvec() which uses ITER_BVEC iterators.  In this change, though,
the WRITE flag was lost:

-       iov_iter_kvec(&from, ITER_KVEC | WRITE, &kvec, 1, len);
+       iov_iter_bvec(&i, ITER_BVEC, bvec, 1, bvec->bv_len);

This flag is necessary for the DAX case because we make decisions based on
whether or not the iterator is a READ or a WRITE in dax_iomap_actor() and
in dax_iomap_rw().

We end up going through this path in configurations where we combine a PMEM
device with 4k sectors, a loopback device and DAX.  The consequence of this
missed flag is that what we intend as a write actually turns into a read in
the DAX code, so no data is ever written.

The very simplest test case is to create a loopback device and try and
write a small string to it, then hexdump a few bytes of the device to see
if the write took.  Without this patch you read back all zeros, with this
you read back the string you wrote.

For XFS this causes us to fail or panic during the following xfstests:

	xfs/074 xfs/078 xfs/216 xfs/217 xfs/250

For ext4 we have a similar issue where writes never happen, but we don't
currently have any xfstests that use loopback and show this issue.

Fix this by restoring the WRITE flag argument to iov_iter_bvec().  This
causes the xfstests to all pass.

Cc: Al Viro 
Cc: stable@vger.kernel.org
Fixes: commit aa4d86163e4e ("block: loop: switch to VFS ITER_BVEC")
Reviewed-by: Christoph Hellwig 
Reviewed-by: Ming Lei 
Signed-off-by: Ross Zwisler 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

rbd: silence bogus -Wmaybe-uninitialized warning

2018-02-25T10:05:54+00:00

commit d4c2269b3d5d06a8ea434b1841fbcaec336ed396 upstream.

drivers/block/rbd.c: In function ‘rbd_watch_cb’:
drivers/block/rbd.c:3690:5: error: ‘struct_v’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/block/rbd.c:3759:5: note: ‘struct_v’ was declared here

Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

pktcdvd: Fix pkt_setup_dev() error path

2018-02-17T12:21:19+00:00

commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.

Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
modified add_disk() and disk_release() but did not update any of the
error paths that trigger a put_disk() call after disk->queue has been
assigned. That introduced the following behavior in the pktcdvd driver
if pkt_new_dev() fails:

Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]

Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
error path.

Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
Signed-off-by: Bart Van Assche 
Cc: Tejun Heo 
Cc: Maciej S. Szmigiero 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

loop: fix concurrent lo_open/lo_release

2018-02-03T16:05:33+00:00

commit ae6650163c66a7eff1acd6eb8b0f752dcfa8eba5 upstream.

范龙飞 reports that KASAN can report a use-after-free in __lock_acquire.
The reason is due to insufficient serialization in lo_release(), which
will continue to use the loop device even after it has decremented the
lo_refcnt to zero.

In the meantime, another process can come in, open the loop device
again as it is being shut down. Confusion ensues.

Reported-by: 范龙飞 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jens Axboe 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

rbd: set max_segments to USHRT_MAX

2018-01-17T08:38:54+00:00

commit 21acdf45f4958135940f0b4767185cf911d4b010 upstream.

Commit d3834fefcfe5 ("rbd: bump queue_max_segments") bumped
max_segments (unsigned short) to max_hw_sectors (unsigned int).
max_hw_sectors is set to the number of 512-byte sectors in an object
and overflows unsigned short for 32M (largest possible) objects, making
the block layer resort to handing us single segment (i.e. single page
or even smaller) bios in that case.

Fixes: d3834fefcfe5 ("rbd: bump queue_max_segments")
Signed-off-by: Ilya Dryomov 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

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

2018-01-10T08:29:52+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 
Signed-off-by: Greg Kroah-Hartman

nbd: set queue timeout properly

2017-12-25T13:23:41+00:00

[ Upstream commit f8586855031a1d6b243f013c3082631346fddfad ]

We can't just set the timeout on the tagset, we have to set it on the
queue as it would have been setup already at this point.

Signed-off-by: Josef Bacik 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

zram: set physical queue limits to avoid array out of bounds accesses

2017-12-14T08:28:21+00:00

[ Upstream commit 0bc315381fe9ed9fb91db8b0e82171b645ac008f ]

zram can handle at most SECTORS_PER_PAGE sectors in a bio's bvec. When using
the NVMe over Fabrics loopback target which potentially sends a huge bulk of
pages attached to the bio's bvec this results in a kernel panic because of
array out of bounds accesses in zram_decompress_page().

Signed-off-by: Johannes Thumshirn 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rbd: use GFP_NOIO for parent stat and data requests

2017-11-15T14:53:20+00:00

commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.

rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
the writeback path for cloned images -- we attempt a stat on the parent
object to see if it exists and potentially read it in to call copyup.
GFP_NOIO should be used instead of GFP_KERNEL here.

Link: http://tracker.ceph.com/issues/22014
Signed-off-by: Ilya Dryomov 
Reviewed-by: David Disseldorp 
Signed-off-by: Greg Kroah-Hartman

skd: Submit requests to firmware before triggering the doorbell

2017-09-27T12:39:21+00:00

commit 5fbd545cd3fd311ea1d6e8be4cedddd0ee5684c7 upstream.

Ensure that the members of struct skd_msg_buf have been transferred
to the PCIe adapter before the doorbell is triggered. This patch
avoids that I/O fails sporadically and that the following error
message is reported:

(skd0:STM000196603:[0000:00:09.0]): Completion mismatch comp_id=0x0000 skreq=0x0400 new=0x0000

Signed-off-by: Bart Van Assche 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman