--- /dev/null
+From 669e859b5ea7c6f4fce0149d3907c64e550c294b Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Mon, 11 Feb 2019 21:32:10 +0300
+Subject: btrfs: drop the lock on error in btrfs_dev_replace_cancel
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 669e859b5ea7c6f4fce0149d3907c64e550c294b upstream.
+
+We should drop the lock on this error path. This has been found by a
+static tool.
+
+The lock needs to be released, it's there to protect access to the
+dev_replace members and is not supposed to be left locked. The value of
+state that's being switched would need to be artifically changed to an
+invalid value so the default: branch is taken.
+
+Fixes: d189dd70e255 ("btrfs: fix use-after-free due to race between replace start and cancel")
+CC: stable@vger.kernel.org # 5.0+
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/dev-replace.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/btrfs/dev-replace.c
++++ b/fs/btrfs/dev-replace.c
+@@ -862,6 +862,7 @@ int btrfs_dev_replace_cancel(struct btrf
+ btrfs_destroy_dev_replace_tgtdev(tgt_device);
+ break;
+ default:
++ up_write(&dev_replace->rwsem);
+ result = -EINVAL;
+ }
+
--- /dev/null
+From 349ae63f40638a28c6fce52e8447c2d14b84cc0c Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <jthumshirn@suse.de>
+Date: Mon, 18 Feb 2019 11:28:37 +0100
+Subject: btrfs: ensure that a DUP or RAID1 block group has exactly two stripes
+
+From: Johannes Thumshirn <jthumshirn@suse.de>
+
+commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream.
+
+We recently had a customer issue with a corrupted filesystem. When
+trying to mount this image btrfs panicked with a division by zero in
+calc_stripe_length().
+
+The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length()
+takes this value and divides it by the number of copies the RAID profile
+is expected to have to calculate the amount of data stripes. As a DUP
+profile is expected to have 2 copies this division resulted in 1/2 = 0.
+Later then the 'data_stripes' variable is used as a divisor in the
+stripe length calculation which results in a division by 0 and thus a
+kernel panic.
+
+When encountering a filesystem with a DUP block group and a
+'num_stripes' value unequal to 2, refuse mounting as the image is
+corrupted and will lead to unexpected behaviour.
+
+Code inspection showed a RAID1 block group has the same issues.
+
+Fixes: e06cd3dd7cea ("Btrfs: add validadtion checks for chunk loading")
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/volumes.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -6782,10 +6782,10 @@ static int btrfs_check_chunk_valid(struc
+ }
+
+ if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) ||
+- (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) ||
++ (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes != 2) ||
+ (type & BTRFS_BLOCK_GROUP_RAID5 && num_stripes < 2) ||
+ (type & BTRFS_BLOCK_GROUP_RAID6 && num_stripes < 3) ||
+- (type & BTRFS_BLOCK_GROUP_DUP && num_stripes > 2) ||
++ (type & BTRFS_BLOCK_GROUP_DUP && num_stripes != 2) ||
+ ((type & BTRFS_BLOCK_GROUP_PROFILE_MASK) == 0 &&
+ num_stripes != 1)) {
+ btrfs_err(fs_info,
--- /dev/null
+From 8e928218780e2f1cf2f5891c7575e8f0b284fcce Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 14 Feb 2019 15:17:20 +0000
+Subject: Btrfs: fix corruption reading shared and compressed extents after hole punching
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
+
+In the past we had data corruption when reading compressed extents that
+are shared within the same file and they are consecutive, this got fixed
+by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and
+shared extents") and by commit 808f80b46790f ("Btrfs: update fix for read
+corruption of compressed and shared extents"). However there was a case
+that was missing in those fixes, which is when the shared and compressed
+extents are referenced with a non-zero offset. The following shell script
+creates a reproducer for this issue:
+
+ #!/bin/bash
+
+ mkfs.btrfs -f /dev/sdc &> /dev/null
+ mount -o compress /dev/sdc /mnt/sdc
+
+ # Create a file with 3 consecutive compressed extents, each has an
+ # uncompressed size of 128Kb and a compressed size of 4Kb.
+ for ((i = 1; i <= 3; i++)); do
+ head -c 4096 /dev/zero
+ for ((j = 1; j <= 31; j++)); do
+ head -c 4096 /dev/zero | tr '\0' "\377"
+ done
+ done > /mnt/sdc/foobar
+ sync
+
+ echo "Digest after file creation: $(md5sum /mnt/sdc/foobar)"
+
+ # Clone the first extent into offsets 128K and 256K.
+ xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar
+ xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar
+ sync
+
+ echo "Digest after cloning: $(md5sum /mnt/sdc/foobar)"
+
+ # Punch holes into the regions that are already full of zeroes.
+ xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar
+ xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar
+ xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar
+ sync
+
+ echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)"
+
+ echo "Dropping page cache..."
+ sysctl -q vm.drop_caches=1
+ echo "Digest after hole punching: $(md5sum /mnt/sdc/foobar)"
+
+ umount /dev/sdc
+
+When running the script we get the following output:
+
+ Digest after file creation: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
+ linked 131072/131072 bytes at offset 131072
+ 128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec)
+ linked 131072/131072 bytes at offset 262144
+ 128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec)
+ Digest after cloning: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
+ Digest after hole punching: 5a0888d80d7ab1fd31c229f83a3bbcc8 /mnt/sdc/foobar
+ Dropping page cache...
+ Digest after hole punching: fba694ae8664ed0c2e9ff8937e7f1484 /mnt/sdc/foobar
+
+This happens because after reading all the pages of the extent in the
+range from 128K to 256K for example, we read the hole at offset 256K
+and then when reading the page at offset 260K we don't submit the
+existing bio, which is responsible for filling all the page in the
+range 128K to 256K only, therefore adding the pages from range 260K
+to 384K to the existing bio and submitting it after iterating over the
+entire range. Once the bio completes, the uncompressed data fills only
+the pages in the range 128K to 256K because there's no more data read
+from disk, leaving the pages in the range 260K to 384K unfilled. It is
+just a slightly different variant of what was solved by commit
+005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared
+extents").
+
+Fix this by forcing a bio submit, during readpages(), whenever we find a
+compressed extent map for a page that is different from the extent map
+for the previous page or has a different starting offset (in case it's
+the same compressed extent), instead of the extent map's original start
+offset.
+
+A test case for fstests follows soon.
+
+Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
+Fixes: 808f80b46790f ("Btrfs: update fix for read corruption of compressed and shared extents")
+Fixes: 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents")
+Cc: stable@vger.kernel.org # 4.3+
+Tested-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent_io.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/extent_io.c
++++ b/fs/btrfs/extent_io.c
+@@ -2985,11 +2985,11 @@ static int __do_readpage(struct extent_i
+ */
+ if (test_bit(EXTENT_FLAG_COMPRESSED, &em->flags) &&
+ prev_em_start && *prev_em_start != (u64)-1 &&
+- *prev_em_start != em->orig_start)
++ *prev_em_start != em->start)
+ force_bio_submit = true;
+
+ if (prev_em_start)
+- *prev_em_start = em->orig_start;
++ *prev_em_start = em->start;
+
+ free_extent_map(em);
+ em = NULL;
--- /dev/null
+From 4ea748e1d2c9f8a27332b949e8210dbbf392987e Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Tue, 26 Feb 2019 12:06:09 +0000
+Subject: Btrfs: fix deadlock between clone/dedupe and rename
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 4ea748e1d2c9f8a27332b949e8210dbbf392987e upstream.
+
+Reflinking (clone/dedupe) and rename are operations that operate on two
+inodes and therefore need to lock them in the same order to avoid ABBA
+deadlocks. It happens that Btrfs' reflink implementation always locked
+them in a different order from VFS's lock_two_nondirectories() helper,
+which is used by the rename code in VFS, resulting in ABBA type deadlocks.
+
+Btrfs' locking order:
+
+ static void btrfs_double_inode_lock(struct inode *inode1, struct inode *inode2)
+ {
+ if (inode1 < inode2)
+ swap(inode1, inode2);
+
+ inode_lock_nested(inode1, I_MUTEX_PARENT);
+ inode_lock_nested(inode2, I_MUTEX_CHILD);
+ }
+
+VFS's locking order:
+
+ void lock_two_nondirectories(struct inode *inode1, struct inode *inode2)
+ {
+ if (inode1 > inode2)
+ swap(inode1, inode2);
+
+ if (inode1 && !S_ISDIR(inode1->i_mode))
+ inode_lock(inode1);
+ if (inode2 && !S_ISDIR(inode2->i_mode) && inode2 != inode1)
+ inode_lock_nested(inode2, I_MUTEX_NONDIR2);
+}
+
+Fix this by killing the btrfs helper function that does the double inode
+locking and replace it with VFS's helper lock_two_nondirectories().
+
+Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
+Fixes: 416161db9b63e3 ("btrfs: offline dedupe")
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ioctl.c | 21 +++------------------
+ 1 file changed, 3 insertions(+), 18 deletions(-)
+
+--- a/fs/btrfs/ioctl.c
++++ b/fs/btrfs/ioctl.c
+@@ -3206,21 +3206,6 @@ out:
+ return ret;
+ }
+
+-static void btrfs_double_inode_unlock(struct inode *inode1, struct inode *inode2)
+-{
+- inode_unlock(inode1);
+- inode_unlock(inode2);
+-}
+-
+-static void btrfs_double_inode_lock(struct inode *inode1, struct inode *inode2)
+-{
+- if (inode1 < inode2)
+- swap(inode1, inode2);
+-
+- inode_lock_nested(inode1, I_MUTEX_PARENT);
+- inode_lock_nested(inode2, I_MUTEX_CHILD);
+-}
+-
+ static void btrfs_double_extent_unlock(struct inode *inode1, u64 loff1,
+ struct inode *inode2, u64 loff2, u64 len)
+ {
+@@ -3989,7 +3974,7 @@ static int btrfs_remap_file_range_prep(s
+ if (same_inode)
+ inode_lock(inode_in);
+ else
+- btrfs_double_inode_lock(inode_in, inode_out);
++ lock_two_nondirectories(inode_in, inode_out);
+
+ /*
+ * Now that the inodes are locked, we need to start writeback ourselves
+@@ -4039,7 +4024,7 @@ static int btrfs_remap_file_range_prep(s
+ if (same_inode)
+ inode_unlock(inode_in);
+ else
+- btrfs_double_inode_unlock(inode_in, inode_out);
++ unlock_two_nondirectories(inode_in, inode_out);
+
+ return ret;
+ }
+@@ -4069,7 +4054,7 @@ loff_t btrfs_remap_file_range(struct fil
+ if (same_inode)
+ inode_unlock(src_inode);
+ else
+- btrfs_double_inode_unlock(src_inode, dst_inode);
++ unlock_two_nondirectories(src_inode, dst_inode);
+
+ return ret < 0 ? ret : len;
+ }
--- /dev/null
+From e49be14b8d80e23bb7c53d78c21717a474ade76b Mon Sep 17 00:00:00 2001
+From: Dan Robertson <dan@dlrobertson.com>
+Date: Tue, 19 Feb 2019 02:56:43 +0000
+Subject: btrfs: init csum_list before possible free
+
+From: Dan Robertson <dan@dlrobertson.com>
+
+commit e49be14b8d80e23bb7c53d78c21717a474ade76b upstream.
+
+The scrub_ctx csum_list member must be initialized before scrub_free_ctx
+is called. If the csum_list is not initialized beforehand, the
+list_empty call in scrub_free_csums will result in a null deref if the
+allocation fails in the for loop.
+
+Fixes: a2de733c78fa ("btrfs: scrub")
+CC: stable@vger.kernel.org # 3.0+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Dan Robertson <dan@dlrobertson.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/scrub.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/scrub.c
++++ b/fs/btrfs/scrub.c
+@@ -584,6 +584,7 @@ static noinline_for_stack struct scrub_c
+ sctx->pages_per_rd_bio = SCRUB_PAGES_PER_RD_BIO;
+ sctx->curr = -1;
+ sctx->fs_info = fs_info;
++ INIT_LIST_HEAD(&sctx->csum_list);
+ for (i = 0; i < SCRUB_BIOS_PER_SCTX; ++i) {
+ struct scrub_bio *sbio;
+
+@@ -608,7 +609,6 @@ static noinline_for_stack struct scrub_c
+ atomic_set(&sctx->workers_pending, 0);
+ atomic_set(&sctx->cancel_req, 0);
+ sctx->csum_size = btrfs_super_csum_size(fs_info->super_copy);
+- INIT_LIST_HEAD(&sctx->csum_list);
+
+ spin_lock_init(&sctx->list_lock);
+ spin_lock_init(&sctx->stat_lock);
--- /dev/null
+From 1cec3f27168d7835ff3d23ab371cd548440131bb Mon Sep 17 00:00:00 2001
+From: Anand Jain <anand.jain@oracle.com>
+Date: Wed, 30 Jan 2019 14:45:00 +0800
+Subject: btrfs: scrub: fix circular locking dependency warning
+
+From: Anand Jain <anand.jain@oracle.com>
+
+commit 1cec3f27168d7835ff3d23ab371cd548440131bb upstream.
+
+This fixes a longstanding lockdep warning triggered by
+fstests/btrfs/011.
+
+Circular locking dependency check reports warning[1], that's because the
+btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock
+held. The test case leading to this warning:
+
+ $ mkfs.btrfs -f /dev/sdb
+ $ mount /dev/sdb /btrfs
+ $ btrfs scrub start -B /btrfs
+
+In fact we have fs_info::scrub_workers_refcnt to track if the init and destroy
+of the scrub workers are needed. So once we have incremented and decremented
+the fs_info::scrub_workers_refcnt value in the thread, its ok to drop the
+scrub_lock, and then actually do the btrfs_destroy_workqueue() part. So this
+patch drops the scrub_lock before calling btrfs_destroy_workqueue().
+
+ [359.258534] ======================================================
+ [359.260305] WARNING: possible circular locking dependency detected
+ [359.261938] 5.0.0-rc6-default #461 Not tainted
+ [359.263135] ------------------------------------------------------
+ [359.264672] btrfs/20975 is trying to acquire lock:
+ [359.265927] 00000000d4d32bea ((wq_completion)"%s-%s""btrfs", name){+.+.}, at: flush_workqueue+0x87/0x540
+ [359.268416]
+ [359.268416] but task is already holding lock:
+ [359.270061] 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
+ [359.272418]
+ [359.272418] which lock already depends on the new lock.
+ [359.272418]
+ [359.274692]
+ [359.274692] the existing dependency chain (in reverse order) is:
+ [359.276671]
+ [359.276671] -> #3 (&fs_info->scrub_lock){+.+.}:
+ [359.278187] __mutex_lock+0x86/0x9c0
+ [359.279086] btrfs_scrub_pause+0x31/0x100 [btrfs]
+ [359.280421] btrfs_commit_transaction+0x1e4/0x9e0 [btrfs]
+ [359.281931] close_ctree+0x30b/0x350 [btrfs]
+ [359.283208] generic_shutdown_super+0x64/0x100
+ [359.284516] kill_anon_super+0x14/0x30
+ [359.285658] btrfs_kill_super+0x12/0xa0 [btrfs]
+ [359.286964] deactivate_locked_super+0x29/0x60
+ [359.288242] cleanup_mnt+0x3b/0x70
+ [359.289310] task_work_run+0x98/0xc0
+ [359.290428] exit_to_usermode_loop+0x83/0x90
+ [359.291445] do_syscall_64+0x15b/0x180
+ [359.292598] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+ [359.294011]
+ [359.294011] -> #2 (sb_internal#2){.+.+}:
+ [359.295432] __sb_start_write+0x113/0x1d0
+ [359.296394] start_transaction+0x369/0x500 [btrfs]
+ [359.297471] btrfs_finish_ordered_io+0x2aa/0x7c0 [btrfs]
+ [359.298629] normal_work_helper+0xcd/0x530 [btrfs]
+ [359.299698] process_one_work+0x246/0x610
+ [359.300898] worker_thread+0x3c/0x390
+ [359.302020] kthread+0x116/0x130
+ [359.303053] ret_from_fork+0x24/0x30
+ [359.304152]
+ [359.304152] -> #1 ((work_completion)(&work->normal_work)){+.+.}:
+ [359.306100] process_one_work+0x21f/0x610
+ [359.307302] worker_thread+0x3c/0x390
+ [359.308465] kthread+0x116/0x130
+ [359.309357] ret_from_fork+0x24/0x30
+ [359.310229]
+ [359.310229] -> #0 ((wq_completion)"%s-%s""btrfs", name){+.+.}:
+ [359.311812] lock_acquire+0x90/0x180
+ [359.312929] flush_workqueue+0xaa/0x540
+ [359.313845] drain_workqueue+0xa1/0x180
+ [359.314761] destroy_workqueue+0x17/0x240
+ [359.315754] btrfs_destroy_workqueue+0x57/0x200 [btrfs]
+ [359.317245] scrub_workers_put+0x2c/0x60 [btrfs]
+ [359.318585] btrfs_scrub_dev+0x336/0x590 [btrfs]
+ [359.319944] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
+ [359.321622] btrfs_ioctl+0x28a4/0x2e40 [btrfs]
+ [359.322908] do_vfs_ioctl+0xa2/0x6d0
+ [359.324021] ksys_ioctl+0x3a/0x70
+ [359.325066] __x64_sys_ioctl+0x16/0x20
+ [359.326236] do_syscall_64+0x54/0x180
+ [359.327379] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+ [359.328772]
+ [359.328772] other info that might help us debug this:
+ [359.328772]
+ [359.330990] Chain exists of:
+ [359.330990] (wq_completion)"%s-%s""btrfs", name --> sb_internal#2 --> &fs_info->scrub_lock
+ [359.330990]
+ [359.334376] Possible unsafe locking scenario:
+ [359.334376]
+ [359.336020] CPU0 CPU1
+ [359.337070] ---- ----
+ [359.337821] lock(&fs_info->scrub_lock);
+ [359.338506] lock(sb_internal#2);
+ [359.339506] lock(&fs_info->scrub_lock);
+ [359.341461] lock((wq_completion)"%s-%s""btrfs", name);
+ [359.342437]
+ [359.342437] *** DEADLOCK ***
+ [359.342437]
+ [359.343745] 1 lock held by btrfs/20975:
+ [359.344788] #0: 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
+ [359.346778]
+ [359.346778] stack backtrace:
+ [359.347897] CPU: 0 PID: 20975 Comm: btrfs Not tainted 5.0.0-rc6-default #461
+ [359.348983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014
+ [359.350501] Call Trace:
+ [359.350931] dump_stack+0x67/0x90
+ [359.351676] print_circular_bug.isra.37.cold.56+0x15c/0x195
+ [359.353569] check_prev_add.constprop.44+0x4f9/0x750
+ [359.354849] ? check_prev_add.constprop.44+0x286/0x750
+ [359.356505] __lock_acquire+0xb84/0xf10
+ [359.357505] lock_acquire+0x90/0x180
+ [359.358271] ? flush_workqueue+0x87/0x540
+ [359.359098] flush_workqueue+0xaa/0x540
+ [359.359912] ? flush_workqueue+0x87/0x540
+ [359.360740] ? drain_workqueue+0x1e/0x180
+ [359.361565] ? drain_workqueue+0xa1/0x180
+ [359.362391] drain_workqueue+0xa1/0x180
+ [359.363193] destroy_workqueue+0x17/0x240
+ [359.364539] btrfs_destroy_workqueue+0x57/0x200 [btrfs]
+ [359.365673] scrub_workers_put+0x2c/0x60 [btrfs]
+ [359.366618] btrfs_scrub_dev+0x336/0x590 [btrfs]
+ [359.367594] ? start_transaction+0xa1/0x500 [btrfs]
+ [359.368679] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
+ [359.369545] btrfs_ioctl+0x28a4/0x2e40 [btrfs]
+ [359.370186] ? __lock_acquire+0x263/0xf10
+ [359.370777] ? kvm_clock_read+0x14/0x30
+ [359.371392] ? kvm_sched_clock_read+0x5/0x10
+ [359.372248] ? sched_clock+0x5/0x10
+ [359.372786] ? sched_clock_cpu+0xc/0xc0
+ [359.373662] ? do_vfs_ioctl+0xa2/0x6d0
+ [359.374552] do_vfs_ioctl+0xa2/0x6d0
+ [359.375378] ? do_sigaction+0xff/0x250
+ [359.376233] ksys_ioctl+0x3a/0x70
+ [359.376954] __x64_sys_ioctl+0x16/0x20
+ [359.377772] do_syscall_64+0x54/0x180
+ [359.378841] entry_SYSCALL_64_after_hwframe+0x49/0xbe
+ [359.380422] RIP: 0033:0x7f5429296a97
+
+Backporting to older kernels: scrub_nocow_workers must be freed the same
+way as the others.
+
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: Anand Jain <anand.jain@oracle.com>
+[ update changelog ]
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/scrub.c | 22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/fs/btrfs/scrub.c
++++ b/fs/btrfs/scrub.c
+@@ -3770,16 +3770,6 @@ fail_scrub_workers:
+ return -ENOMEM;
+ }
+
+-static noinline_for_stack void scrub_workers_put(struct btrfs_fs_info *fs_info)
+-{
+- if (--fs_info->scrub_workers_refcnt == 0) {
+- btrfs_destroy_workqueue(fs_info->scrub_workers);
+- btrfs_destroy_workqueue(fs_info->scrub_wr_completion_workers);
+- btrfs_destroy_workqueue(fs_info->scrub_parity_workers);
+- }
+- WARN_ON(fs_info->scrub_workers_refcnt < 0);
+-}
+-
+ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,
+ u64 end, struct btrfs_scrub_progress *progress,
+ int readonly, int is_dev_replace)
+@@ -3788,6 +3778,9 @@ int btrfs_scrub_dev(struct btrfs_fs_info
+ int ret;
+ struct btrfs_device *dev;
+ unsigned int nofs_flag;
++ struct btrfs_workqueue *scrub_workers = NULL;
++ struct btrfs_workqueue *scrub_wr_comp = NULL;
++ struct btrfs_workqueue *scrub_parity = NULL;
+
+ if (btrfs_fs_closing(fs_info))
+ return -EINVAL;
+@@ -3927,9 +3920,16 @@ int btrfs_scrub_dev(struct btrfs_fs_info
+
+ mutex_lock(&fs_info->scrub_lock);
+ dev->scrub_ctx = NULL;
+- scrub_workers_put(fs_info);
++ if (--fs_info->scrub_workers_refcnt == 0) {
++ scrub_workers = fs_info->scrub_workers;
++ scrub_wr_comp = fs_info->scrub_wr_completion_workers;
++ scrub_parity = fs_info->scrub_parity_workers;
++ }
+ mutex_unlock(&fs_info->scrub_lock);
+
++ btrfs_destroy_workqueue(scrub_workers);
++ btrfs_destroy_workqueue(scrub_wr_comp);
++ btrfs_destroy_workqueue(scrub_parity);
+ scrub_put_ctx(sctx);
+
+ return ret;
--- /dev/null
+From a0873490660246db587849a9e172f2b7b21fa88a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 13 Dec 2018 21:16:56 +0000
+Subject: Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit a0873490660246db587849a9e172f2b7b21fa88a upstream.
+
+We are holding a transaction handle when setting an acl, therefore we can
+not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock
+if reclaim is triggered by the allocation, therefore setup a nofs context.
+
+Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl allocations")
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/acl.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/btrfs/acl.c
++++ b/fs/btrfs/acl.c
+@@ -9,6 +9,7 @@
+ #include <linux/posix_acl_xattr.h>
+ #include <linux/posix_acl.h>
+ #include <linux/sched.h>
++#include <linux/sched/mm.h>
+ #include <linux/slab.h>
+
+ #include "ctree.h"
+@@ -72,8 +73,16 @@ static int __btrfs_set_acl(struct btrfs_
+ }
+
+ if (acl) {
++ unsigned int nofs_flag;
++
+ size = posix_acl_xattr_size(acl->a_count);
++ /*
++ * We're holding a transaction handle, so use a NOFS memory
++ * allocation context to avoid deadlock if reclaim happens.
++ */
++ nofs_flag = memalloc_nofs_save();
+ value = kmalloc(size, GFP_KERNEL);
++ memalloc_nofs_restore(nofs_flag);
+ if (!value) {
+ ret = -ENOMEM;
+ goto out;
--- /dev/null
+From b89f6d1fcb30a8cbdc18ce00c7d93792076af453 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 13 Dec 2018 21:16:45 +0000
+Subject: Btrfs: setup a nofs context for memory allocation at btrfs_create_tree()
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit b89f6d1fcb30a8cbdc18ce00c7d93792076af453 upstream.
+
+We are holding a transaction handle when creating a tree, therefore we can
+not allocate the root using GFP_KERNEL, as we could deadlock if reclaim is
+triggered by the allocation, therefore setup a nofs context.
+
+Fixes: 74e4d82757f74 ("btrfs: let callers of btrfs_alloc_root pass gfp flags")
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/disk-io.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -17,6 +17,7 @@
+ #include <linux/semaphore.h>
+ #include <linux/error-injection.h>
+ #include <linux/crc32c.h>
++#include <linux/sched/mm.h>
+ #include <asm/unaligned.h>
+ #include "ctree.h"
+ #include "disk-io.h"
+@@ -1258,10 +1259,17 @@ struct btrfs_root *btrfs_create_tree(str
+ struct btrfs_root *tree_root = fs_info->tree_root;
+ struct btrfs_root *root;
+ struct btrfs_key key;
++ unsigned int nofs_flag;
+ int ret = 0;
+ uuid_le uuid = NULL_UUID_LE;
+
++ /*
++ * We're holding a transaction handle, so use a NOFS memory allocation
++ * context to avoid deadlock if reclaim happens.
++ */
++ nofs_flag = memalloc_nofs_save();
+ root = btrfs_alloc_root(fs_info, GFP_KERNEL);
++ memalloc_nofs_restore(nofs_flag);
+ if (!root)
+ return ERR_PTR(-ENOMEM);
+
--- /dev/null
+From c950ca8c35eeb32224a63adc47e12f9e226da241 Mon Sep 17 00:00:00 2001
+From: Samuel Holland <samuel@sholland.org>
+Date: Sat, 12 Jan 2019 20:17:18 -0600
+Subject: clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Samuel Holland <samuel@sholland.org>
+
+commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream.
+
+The Allwinner A64 SoC is known[1] to have an unstable architectural
+timer, which manifests itself most obviously in the time jumping forward
+a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
+timer frequency of 24 MHz, implying that the time went slightly backward
+(and this was interpreted by the kernel as it jumping forward and
+wrapping around past the epoch).
+
+Investigation revealed instability in the low bits of CNTVCT at the
+point a high bit rolls over. This leads to power-of-two cycle forward
+and backward jumps. (Testing shows that forward jumps are about twice as
+likely as backward jumps.) Since the counter value returns to normal
+after an indeterminate read, each "jump" really consists of both a
+forward and backward jump from the software perspective.
+
+Unless the kernel is trapping CNTVCT reads, a userspace program is able
+to read the register in a loop faster than it changes. A test program
+running on all 4 CPU cores that reported jumps larger than 100 ms was
+run for 13.6 hours and reported the following:
+
+ Count | Event
+-------+---------------------------
+ 9940 | jumped backward 699ms
+ 268 | jumped backward 1398ms
+ 1 | jumped backward 2097ms
+ 16020 | jumped forward 175ms
+ 6443 | jumped forward 699ms
+ 2976 | jumped forward 1398ms
+ 9 | jumped forward 356516ms
+ 9 | jumped forward 357215ms
+ 4 | jumped forward 714430ms
+ 1 | jumped forward 3578440ms
+
+This works out to a jump larger than 100 ms about every 5.5 seconds on
+each CPU core.
+
+The largest jump (almost an hour!) was the following sequence of reads:
+ 0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
+
+Note that the middle bits don't necessarily all read as all zeroes or
+all ones during the anomalous behavior; however the low 10 bits checked
+by the function in this patch have never been observed with any other
+value.
+
+Also note that smaller jumps are much more common, with backward jumps
+of 2048 (2^11) cycles observed over 400 times per second on each core.
+(Of course, this is partially explained by lower bits rolling over more
+frequently.) Any one of these could have caused the 95 year time skip.
+
+Similar anomalies were observed while reading CNTPCT (after patching the
+kernel to allow reads from userspace). However, the CNTPCT jumps are
+much less frequent, and only small jumps were observed. The same program
+as before (except now reading CNTPCT) observed after 72 hours:
+
+ Count | Event
+-------+---------------------------
+ 17 | jumped backward 699ms
+ 52 | jumped forward 175ms
+ 2831 | jumped forward 699ms
+ 5 | jumped forward 1398ms
+
+Further investigation showed that the instability in CNTPCT/CNTVCT also
+affected the respective timer's TVAL register. The following values were
+observed immediately after writing CNVT_TVAL to 0x10000000:
+
+ CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
+--------------------+------------+--------------------+-----------------
+ 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
+ 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
+ 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
+ 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
+
+The pattern of errors in CNTV_TVAL seemed to depend on exactly which
+value was written to it. For example, after writing 0x10101010:
+
+ CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
+--------------------+------------+--------------------+-----------------
+ 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
+ 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
+ 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
+ 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
+ 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
+ 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
+
+I was also twice able to reproduce the issue covered by Allwinner's
+workaround[4], that writing to TVAL sometimes fails, and both CVAL and
+TVAL are left with entirely bogus values. One was the following values:
+
+ CNTVCT | CNTV_TVAL | CNTV_CVAL
+--------------------+------------+--------------------------------------
+ 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
+Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
+
+========================================================================
+
+Because the CPU can read the CNTPCT/CNTVCT registers faster than they
+change, performing two reads of the register and comparing the high bits
+(like other workarounds) is not a workable solution. And because the
+timer can jump both forward and backward, no pair of reads can
+distinguish a good value from a bad one. The only way to guarantee a
+good value from consecutive reads would be to read _three_ times, and
+take the middle value only if the three values are 1) each unique and
+2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
+if an anomaly is detected.
+
+However, since there is a distinct pattern to the bad values, we can
+optimize the common case (1022/1024 of the time) to a single read by
+simply ignoring values that match the error pattern. This still takes no
+more than 3 cycles in the worst case, and requires much less code. As an
+additional safety check, we still limit the loop iteration to the number
+of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
+
+For the TVAL registers, the simple solution is to not use them. Instead,
+read or write the CVAL and calculate the TVAL value in software.
+
+Although the manufacturer is aware of at least part of the erratum[4],
+there is no official name for it. For now, use the kernel-internal name
+"UNKNOWN1".
+
+[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
+[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
+[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
+[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272
+
+Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Tested-by: Andre Przywara <andre.przywara@arm.com>
+Signed-off-by: Samuel Holland <samuel@sholland.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/arm64/silicon-errata.txt | 2 +
+ drivers/clocksource/Kconfig | 10 ++++++
+ drivers/clocksource/arm_arch_timer.c | 55 +++++++++++++++++++++++++++++++++
+ 3 files changed, 67 insertions(+)
+
+--- a/Documentation/arm64/silicon-errata.txt
++++ b/Documentation/arm64/silicon-errata.txt
+@@ -44,6 +44,8 @@ stable kernels.
+
+ | Implementor | Component | Erratum ID | Kconfig |
+ +----------------+-----------------+-----------------+-----------------------------+
++| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
++| | | | |
+ | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+ | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+ | ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+--- a/drivers/clocksource/Kconfig
++++ b/drivers/clocksource/Kconfig
+@@ -360,6 +360,16 @@ config ARM64_ERRATUM_858921
+ The workaround will be dynamically enabled when an affected
+ core is detected.
+
++config SUN50I_ERRATUM_UNKNOWN1
++ bool "Workaround for Allwinner A64 erratum UNKNOWN1"
++ default y
++ depends on ARM_ARCH_TIMER && ARM64 && ARCH_SUNXI
++ select ARM_ARCH_TIMER_OOL_WORKAROUND
++ help
++ This option enables a workaround for instability in the timer on
++ the Allwinner A64 SoC. The workaround will only be active if the
++ allwinner,erratum-unknown1 property is found in the timer node.
++
+ config ARM_GLOBAL_TIMER
+ bool "Support for the ARM global timer" if COMPILE_TEST
+ select TIMER_OF if OF
+--- a/drivers/clocksource/arm_arch_timer.c
++++ b/drivers/clocksource/arm_arch_timer.c
+@@ -326,6 +326,48 @@ static u64 notrace arm64_1188873_read_cn
+ }
+ #endif
+
++#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1
++/*
++ * The low bits of the counter registers are indeterminate while bit 10 or
++ * greater is rolling over. Since the counter value can jump both backward
++ * (7ff -> 000 -> 800) and forward (7ff -> fff -> 800), ignore register values
++ * with all ones or all zeros in the low bits. Bound the loop by the maximum
++ * number of CPU cycles in 3 consecutive 24 MHz counter periods.
++ */
++#define __sun50i_a64_read_reg(reg) ({ \
++ u64 _val; \
++ int _retries = 150; \
++ \
++ do { \
++ _val = read_sysreg(reg); \
++ _retries--; \
++ } while (((_val + 1) & GENMASK(9, 0)) <= 1 && _retries); \
++ \
++ WARN_ON_ONCE(!_retries); \
++ _val; \
++})
++
++static u64 notrace sun50i_a64_read_cntpct_el0(void)
++{
++ return __sun50i_a64_read_reg(cntpct_el0);
++}
++
++static u64 notrace sun50i_a64_read_cntvct_el0(void)
++{
++ return __sun50i_a64_read_reg(cntvct_el0);
++}
++
++static u32 notrace sun50i_a64_read_cntp_tval_el0(void)
++{
++ return read_sysreg(cntp_cval_el0) - sun50i_a64_read_cntpct_el0();
++}
++
++static u32 notrace sun50i_a64_read_cntv_tval_el0(void)
++{
++ return read_sysreg(cntv_cval_el0) - sun50i_a64_read_cntvct_el0();
++}
++#endif
++
+ #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
+ DEFINE_PER_CPU(const struct arch_timer_erratum_workaround *, timer_unstable_counter_workaround);
+ EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
+@@ -423,6 +465,19 @@ static const struct arch_timer_erratum_w
+ .read_cntvct_el0 = arm64_1188873_read_cntvct_el0,
+ },
+ #endif
++#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1
++ {
++ .match_type = ate_match_dt,
++ .id = "allwinner,erratum-unknown1",
++ .desc = "Allwinner erratum UNKNOWN1",
++ .read_cntp_tval_el0 = sun50i_a64_read_cntp_tval_el0,
++ .read_cntv_tval_el0 = sun50i_a64_read_cntv_tval_el0,
++ .read_cntpct_el0 = sun50i_a64_read_cntpct_el0,
++ .read_cntvct_el0 = sun50i_a64_read_cntvct_el0,
++ .set_next_event_phys = erratum_set_next_event_tval_phys,
++ .set_next_event_virt = erratum_set_next_event_tval_virt,
++ },
++#endif
+ };
+
+ typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,
--- /dev/null
+From d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Sun, 10 Feb 2019 22:51:14 +0000
+Subject: clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c upstream.
+
+When shutting down the timer, ensure that after we have stopped the
+timer any pending interrupts are cleared. This fixes a problem when
+suspending, as interrupts are disabled before the timer is stopped,
+so the timer interrupt may still be asserted, preventing the system
+entering a low power state when the wfi is executed.
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: <stable@vger.kernel.org> # v4.3+
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/exynos_mct.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/clocksource/exynos_mct.c
++++ b/drivers/clocksource/exynos_mct.c
+@@ -411,6 +411,7 @@ static int set_state_shutdown(struct clo
+
+ mevt = container_of(evt, struct mct_clock_event_device, evt);
+ exynos4_mct_tick_stop(mevt);
++ exynos4_mct_tick_clear(mevt);
+ return 0;
+ }
+
--- /dev/null
+From a5719a40aef956ba704f2aa1c7b977224d60fa96 Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Sun, 10 Feb 2019 22:51:13 +0000
+Subject: clocksource/drivers/exynos_mct: Move one-shot check from tick clear to ISR
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit a5719a40aef956ba704f2aa1c7b977224d60fa96 upstream.
+
+When a timer tick occurs and the clock is in one-shot mode, the timer
+needs to be stopped to prevent it triggering subsequent interrupts.
+Currently this code is in exynos4_mct_tick_clear(), but as it is
+only needed when an ISR occurs move it into exynos4_mct_tick_isr(),
+leaving exynos4_mct_tick_clear() just doing what its name suggests it
+should.
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: stable@vger.kernel.org # v4.3+
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/exynos_mct.c | 22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/drivers/clocksource/exynos_mct.c
++++ b/drivers/clocksource/exynos_mct.c
+@@ -388,6 +388,13 @@ static void exynos4_mct_tick_start(unsig
+ exynos4_mct_write(tmp, mevt->base + MCT_L_TCON_OFFSET);
+ }
+
++static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
++{
++ /* Clear the MCT tick interrupt */
++ if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
++ exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
++}
++
+ static int exynos4_tick_set_next_event(unsigned long cycles,
+ struct clock_event_device *evt)
+ {
+@@ -420,8 +427,11 @@ static int set_state_periodic(struct clo
+ return 0;
+ }
+
+-static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
++static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
+ {
++ struct mct_clock_event_device *mevt = dev_id;
++ struct clock_event_device *evt = &mevt->evt;
++
+ /*
+ * This is for supporting oneshot mode.
+ * Mct would generate interrupt periodically
+@@ -430,16 +440,6 @@ static void exynos4_mct_tick_clear(struc
+ if (!clockevent_state_periodic(&mevt->evt))
+ exynos4_mct_tick_stop(mevt);
+
+- /* Clear the MCT tick interrupt */
+- if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
+- exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
+-}
+-
+-static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
+-{
+- struct mct_clock_event_device *mevt = dev_id;
+- struct clock_event_device *evt = &mevt->evt;
+-
+ exynos4_mct_tick_clear(mevt);
+
+ evt->event_handler(evt);
--- /dev/null
+From 73052b0daee0b750b39af18460dfec683e4f5887 Mon Sep 17 00:00:00 2001
+From: Varad Gautam <vrd@amazon.de>
+Date: Thu, 24 Jan 2019 14:03:06 +0100
+Subject: fs/devpts: always delete dcache dentry-s in dput()
+
+From: Varad Gautam <vrd@amazon.de>
+
+commit 73052b0daee0b750b39af18460dfec683e4f5887 upstream.
+
+d_delete only unhashes an entry if it is reached with
+dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts:
+more pty driver interface cleanups"), d_delete was called on a dentry
+from devpts_pty_kill with two references held, which would trigger the
+unhashing, and the subsequent dputs would release it.
+
+Commit 8ead9dd54716 reworked devpts_pty_kill to stop acquiring the second
+reference from d_find_alias, and the d_delete call left the dentries
+still on the hashed list without actually ever being dropped from dcache
+before explicit cleanup. This causes the number of negative dentries for
+devpts to pile up, and an `ls /dev/pts` invocation can take seconds to
+return.
+
+Provide always_delete_dentry() from simple_dentry_operations
+as .d_delete for devpts, to make the dentry be dropped from dcache.
+
+Without this cleanup, the number of dentries in /dev/pts/ can be grown
+arbitrarily as:
+
+`python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'`
+
+A systemtap probe on dcache_readdir to count d_subdirs shows this count
+to increase with each pty spawn invocation above:
+
+probe kernel.function("dcache_readdir") {
+ subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs;
+ p = subdirs;
+ p = @cast(p, "list_head")->next;
+ i = 0
+ while (p != subdirs) {
+ p = @cast(p, "list_head")->next;
+ i = i+1;
+ }
+ printf("number of dentries: %d\n", i);
+}
+
+Fixes: 8ead9dd54716 ("devpts: more pty driver interface cleanups")
+Signed-off-by: Varad Gautam <vrd@amazon.de>
+Reported-by: Zheng Wang <wanz@amazon.de>
+Reported-by: Brandon Schwartz <bsschwar@amazon.de>
+Root-caused-by: Maximilian Heyne <mheyne@amazon.de>
+Root-caused-by: Nicolas Pernas Maradei <npernas@amazon.de>
+CC: David Woodhouse <dwmw@amazon.co.uk>
+CC: Maximilian Heyne <mheyne@amazon.de>
+CC: Stefan Nuernberger <snu@amazon.de>
+CC: Amit Shah <aams@amazon.de>
+CC: Linus Torvalds <torvalds@linux-foundation.org>
+CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+CC: Al Viro <viro@ZenIV.linux.org.uk>
+CC: Christian Brauner <christian.brauner@ubuntu.com>
+CC: Eric W. Biederman <ebiederm@xmission.com>
+CC: Matthew Wilcox <willy@infradead.org>
+CC: Eric Biggers <ebiggers@google.com>
+CC: <stable@vger.kernel.org> # 4.9+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/devpts/inode.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/devpts/inode.c
++++ b/fs/devpts/inode.c
+@@ -455,6 +455,7 @@ devpts_fill_super(struct super_block *s,
+ s->s_blocksize_bits = 10;
+ s->s_magic = DEVPTS_SUPER_MAGIC;
+ s->s_op = &devpts_sops;
++ s->s_d_op = &simple_dentry_operations;
+ s->s_time_gran = 1;
+
+ error = -ENOMEM;
--- /dev/null
+From 28713169d879b67be2ef2f84dcf54905de238294 Mon Sep 17 00:00:00 2001
+From: Finn Thain <fthain@telegraphics.com.au>
+Date: Wed, 16 Jan 2019 16:23:24 +1100
+Subject: m68k: Add -ffreestanding to CFLAGS
+
+From: Finn Thain <fthain@telegraphics.com.au>
+
+commit 28713169d879b67be2ef2f84dcf54905de238294 upstream.
+
+This patch fixes a build failure when using GCC 8.1:
+
+/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock':
+block/partitions/ldm.c:153: undefined reference to `strcmp'
+
+This is caused by a new optimization which effectively replaces a
+strncmp() call with a strcmp() call. This affects a number of strncmp()
+call sites in the kernel.
+
+The entire class of optimizations is avoided with -fno-builtin, which
+gets enabled by -ffreestanding. This may avoid possible future build
+failures in case new optimizations appear in future compilers.
+
+I haven't done any performance measurements with this patch but I did
+count the function calls in a defconfig build. For example, there are now
+23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the
+other libc functions is smaller.
+
+If this harms performance we can tackle that regression by optimizing
+the call sites, ideally using semantic patches. That way, clang and ICC
+builds might benfit too.
+
+Cc: stable@vger.kernel.org
+Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2
+Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/m68k/Makefile | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/m68k/Makefile
++++ b/arch/m68k/Makefile
+@@ -58,7 +58,10 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-o
+ cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200)
+
+ KBUILD_AFLAGS += $(cpuflags-y)
+-KBUILD_CFLAGS += $(cpuflags-y) -pipe
++KBUILD_CFLAGS += $(cpuflags-y)
++
++KBUILD_CFLAGS += -pipe -ffreestanding
++
+ ifdef CONFIG_MMU
+ # without -fno-strength-reduce the 53c7xx.c driver fails ;-(
+ KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2
--- /dev/null
+From d4721339dcca7def04909a8e60da43c19a24d8bf Mon Sep 17 00:00:00 2001
+From: Jiong Wu <lohengrin1024@gmail.com>
+Date: Fri, 1 Mar 2019 00:18:33 +0800
+Subject: mmc:fix a bug when max_discard is 0
+
+From: Jiong Wu <lohengrin1024@gmail.com>
+
+commit d4721339dcca7def04909a8e60da43c19a24d8bf upstream.
+
+The original purpose of the code I fix is to replace max_discard with
+max_trim if max_trim is less than max_discard. When max_discard is 0
+we should replace max_discard with max_trim as well, because
+max_discard equals 0 happens only when the max_do_calc_max_discard
+process is overflowed, so if mmc_can_trim(card) is true, max_discard
+should be replaced by an available max_trim.
+However, in the original code, there are two lines of code interfere
+the right process.
+1) if (max_discard && mmc_can_trim(card))
+when max_discard is 0, it skips the process checking if max_discard
+needs to be replaced with max_trim.
+2) if (max_trim < max_discard)
+the condition is false when max_discard is 0. it also skips the process
+that replaces max_discard with max_trim, in fact, we should replace the
+0-valued max_discard with max_trim.
+
+Signed-off-by: Jiong Wu <Lohengrin1024@gmail.com>
+Fixes: b305882fbc87 (mmc: core: optimize mmc_calc_max_discard)
+Cc: stable@vger.kernel.org # v4.17+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/core/core.c
++++ b/drivers/mmc/core/core.c
+@@ -2381,9 +2381,9 @@ unsigned int mmc_calc_max_discard(struct
+ return card->pref_erase;
+
+ max_discard = mmc_do_calc_max_discard(card, MMC_ERASE_ARG);
+- if (max_discard && mmc_can_trim(card)) {
++ if (mmc_can_trim(card)) {
+ max_trim = mmc_do_calc_max_discard(card, MMC_TRIM_ARG);
+- if (max_trim < max_discard)
++ if (max_trim < max_discard || max_discard == 0)
+ max_discard = max_trim;
+ } else if (max_discard < card->erase_size) {
+ max_discard = 0;
--- /dev/null
+From d30ae056adb81e1d2b8b953efa74735a020b8e3b Mon Sep 17 00:00:00 2001
+From: Takeshi Saito <takeshi.saito.xv@renesas.com>
+Date: Tue, 29 Jan 2019 06:40:39 +0100
+Subject: mmc: renesas_sdhi: Fix card initialization failure in high speed mode
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Takeshi Saito <takeshi.saito.xv@renesas.com>
+
+commit d30ae056adb81e1d2b8b953efa74735a020b8e3b upstream.
+
+This fixes card initialization failure in high speed mode.
+
+If U-Boot uses SDR or HS200/400 mode before starting Linux and Linux
+DT does not enable SDR/HS200/HS400 mode, card initialization fails in
+high speed mode.
+
+It is necessary to initialize SCC registers during card initialization
+phase. HW reset function is registered only for a port with either of
+SDR/HS200/HS400 properties in device tree. If SDR/HS200/HS400 properties
+are not present in device tree, SCC registers will not be reset. In SoC
+that support SCC registers, HW reset function should be registered
+regardless of the configuration of device tree.
+
+Reproduction procedure:
+- Use U-Boot that support MMC HS200/400 mode.
+- Delete HS200/HS400 properties in device tree.
+ (Delete mmc-hs200-1_8v and mmc-hs400-1_8v)
+- MMC port works high speed mode and all commands fail.
+
+Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
+Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
+Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
+Cc: Simon Horman <horms+renesas@verge.net.au>
+Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/renesas_sdhi_core.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/host/renesas_sdhi_core.c
++++ b/drivers/mmc/host/renesas_sdhi_core.c
+@@ -723,6 +723,13 @@ int renesas_sdhi_probe(struct platform_d
+ host->ops.start_signal_voltage_switch =
+ renesas_sdhi_start_signal_voltage_switch;
+ host->sdcard_irq_setbit_mask = TMIO_STAT_ALWAYS_SET_27;
++
++ /* SDR and HS200/400 registers requires HW reset */
++ if (of_data && of_data->scc_offset) {
++ priv->scc_ctl = host->ctl + of_data->scc_offset;
++ host->mmc->caps |= MMC_CAP_HW_RESET;
++ host->hw_reset = renesas_sdhi_hw_reset;
++ }
+ }
+
+ /* Orginally registers were 16 bit apart, could be 32 or 64 nowadays */
+@@ -775,8 +782,6 @@ int renesas_sdhi_probe(struct platform_d
+ const struct renesas_sdhi_scc *taps = of_data->taps;
+ bool hit = false;
+
+- host->mmc->caps |= MMC_CAP_HW_RESET;
+-
+ for (i = 0; i < of_data->taps_num; i++) {
+ if (taps[i].clk_rate == 0 ||
+ taps[i].clk_rate == host->mmc->f_max) {
+@@ -789,12 +794,10 @@ int renesas_sdhi_probe(struct platform_d
+ if (!hit)
+ dev_warn(&host->pdev->dev, "Unknown clock rate for SDR104\n");
+
+- priv->scc_ctl = host->ctl + of_data->scc_offset;
+ host->init_tuning = renesas_sdhi_init_tuning;
+ host->prepare_tuning = renesas_sdhi_prepare_tuning;
+ host->select_tuning = renesas_sdhi_select_tuning;
+ host->check_scc_error = renesas_sdhi_check_scc_error;
+- host->hw_reset = renesas_sdhi_hw_reset;
+ host->prepare_hs400_tuning =
+ renesas_sdhi_prepare_hs400_tuning;
+ host->hs400_downgrade = renesas_sdhi_disable_scc;
--- /dev/null
+From de0a0decf2edfc5b0c782915f4120cf990a9bd13 Mon Sep 17 00:00:00 2001
+From: BOUGH CHEN <haibo.chen@nxp.com>
+Date: Thu, 27 Dec 2018 11:20:24 +0000
+Subject: mmc: sdhci-esdhc-imx: fix HS400 timing issue
+
+From: BOUGH CHEN <haibo.chen@nxp.com>
+
+commit de0a0decf2edfc5b0c782915f4120cf990a9bd13 upstream.
+
+Now tuning reset will be done when the timing is MMC_TIMING_LEGACY/
+MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. But for timing MMC_TIMING_MMC_HS,
+we can not do tuning reset, otherwise HS400 timing is not right.
+
+Here is the process of init HS400, first finish tuning in HS200 mode,
+then switch to HS mode and 8 bit DDR mode, finally switch to HS400
+mode. If we do tuning reset in HS mode, this will cause HS400 mode
+lost the tuning setting, which will cause CRC error.
+
+Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
+Cc: stable@vger.kernel.org # v4.12+
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card")
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -979,6 +979,7 @@ static void esdhc_set_uhs_signaling(stru
+ case MMC_TIMING_UHS_SDR25:
+ case MMC_TIMING_UHS_SDR50:
+ case MMC_TIMING_UHS_SDR104:
++ case MMC_TIMING_MMC_HS:
+ case MMC_TIMING_MMC_HS200:
+ writel(m, host->ioaddr + ESDHC_MIX_CTRL);
+ break;
--- /dev/null
+From 906d2d3f874a54183df5a609fda180adf0462428 Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Fri, 25 Jan 2019 17:59:06 +0100
+Subject: mt76: fix corrupted software generated tx CCMP PN
+
+From: Felix Fietkau <nbd@nbd.name>
+
+commit 906d2d3f874a54183df5a609fda180adf0462428 upstream.
+
+Since ccmp_pn is u8 *, the second half needs to start at array index 4
+instead of 0. Fixes a connection stall after a certain amount of traffic
+
+Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management frames")
+Cc: stable@vger.kernel.org
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
++++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+@@ -309,7 +309,7 @@ void mt76x02_mac_write_txwi(struct mt76x
+ ccmp_pn[6] = pn >> 32;
+ ccmp_pn[7] = pn >> 40;
+ txwi->iv = *((__le32 *)&ccmp_pn[0]);
+- txwi->eiv = *((__le32 *)&ccmp_pn[1]);
++ txwi->eiv = *((__le32 *)&ccmp_pn[4]);
+ }
+
+ spin_lock_bh(&dev->mt76.lock);
--- /dev/null
+From 993a0b2aec52754f0897b1dab4c453be8217cae5 Mon Sep 17 00:00:00 2001
+From: Vivek Goyal <vgoyal@redhat.com>
+Date: Wed, 30 Jan 2019 14:01:57 -0500
+Subject: ovl: Do not lose security.capability xattr over metadata file copy-up
+
+From: Vivek Goyal <vgoyal@redhat.com>
+
+commit 993a0b2aec52754f0897b1dab4c453be8217cae5 upstream.
+
+If a file has been copied up metadata only, and later data is copied up,
+upper loses any security.capability xattr it has (underlying filesystem
+clears it as upon file write).
+
+From a user's point of view, this is just a file copy-up and that should
+not result in losing security.capability xattr. Hence, before data copy
+up, save security.capability xattr (if any) and restore it on upper after
+data copy up is complete.
+
+Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
+Reviewed-by: Amir Goldstein <amir73il@gmail.com>
+Fixes: 0c2888749363 ("ovl: A new xattr OVL_XATTR_METACOPY for file on upper")
+Cc: <stable@vger.kernel.org> # v4.19+
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/overlayfs/copy_up.c | 28 ++++++++++++++++++++++-
+ fs/overlayfs/overlayfs.h | 2 +
+ fs/overlayfs/util.c | 55 +++++++++++++++++++++++++++++------------------
+ 3 files changed, 63 insertions(+), 22 deletions(-)
+
+--- a/fs/overlayfs/copy_up.c
++++ b/fs/overlayfs/copy_up.c
+@@ -742,6 +742,8 @@ static int ovl_copy_up_meta_inode_data(s
+ {
+ struct path upperpath, datapath;
+ int err;
++ char *capability = NULL;
++ ssize_t uninitialized_var(cap_size);
+
+ ovl_path_upper(c->dentry, &upperpath);
+ if (WARN_ON(upperpath.dentry == NULL))
+@@ -751,15 +753,37 @@ static int ovl_copy_up_meta_inode_data(s
+ if (WARN_ON(datapath.dentry == NULL))
+ return -EIO;
+
++ if (c->stat.size) {
++ err = cap_size = ovl_getxattr(upperpath.dentry, XATTR_NAME_CAPS,
++ &capability, 0);
++ if (err < 0 && err != -ENODATA)
++ goto out;
++ }
++
+ err = ovl_copy_up_data(&datapath, &upperpath, c->stat.size);
+ if (err)
+- return err;
++ goto out_free;
++
++ /*
++ * Writing to upper file will clear security.capability xattr. We
++ * don't want that to happen for normal copy-up operation.
++ */
++ if (capability) {
++ err = ovl_do_setxattr(upperpath.dentry, XATTR_NAME_CAPS,
++ capability, cap_size, 0);
++ if (err)
++ goto out_free;
++ }
++
+
+ err = vfs_removexattr(upperpath.dentry, OVL_XATTR_METACOPY);
+ if (err)
+- return err;
++ goto out_free;
+
+ ovl_set_upperdata(d_inode(c->dentry));
++out_free:
++ kfree(capability);
++out:
+ return err;
+ }
+
+--- a/fs/overlayfs/overlayfs.h
++++ b/fs/overlayfs/overlayfs.h
+@@ -277,6 +277,8 @@ int ovl_lock_rename_workdir(struct dentr
+ int ovl_check_metacopy_xattr(struct dentry *dentry);
+ bool ovl_is_metacopy_dentry(struct dentry *dentry);
+ char *ovl_get_redirect_xattr(struct dentry *dentry, int padding);
++ssize_t ovl_getxattr(struct dentry *dentry, char *name, char **value,
++ size_t padding);
+
+ static inline bool ovl_is_impuredir(struct dentry *dentry)
+ {
+--- a/fs/overlayfs/util.c
++++ b/fs/overlayfs/util.c
+@@ -863,28 +863,49 @@ bool ovl_is_metacopy_dentry(struct dentr
+ return (oe->numlower > 1);
+ }
+
+-char *ovl_get_redirect_xattr(struct dentry *dentry, int padding)
++ssize_t ovl_getxattr(struct dentry *dentry, char *name, char **value,
++ size_t padding)
+ {
+- int res;
+- char *s, *next, *buf = NULL;
++ ssize_t res;
++ char *buf = NULL;
+
+- res = vfs_getxattr(dentry, OVL_XATTR_REDIRECT, NULL, 0);
++ res = vfs_getxattr(dentry, name, NULL, 0);
+ if (res < 0) {
+ if (res == -ENODATA || res == -EOPNOTSUPP)
+- return NULL;
++ return -ENODATA;
+ goto fail;
+ }
+
+- buf = kzalloc(res + padding + 1, GFP_KERNEL);
+- if (!buf)
+- return ERR_PTR(-ENOMEM);
++ if (res != 0) {
++ buf = kzalloc(res + padding, GFP_KERNEL);
++ if (!buf)
++ return -ENOMEM;
++
++ res = vfs_getxattr(dentry, name, buf, res);
++ if (res < 0)
++ goto fail;
++ }
++ *value = buf;
+
+- if (res == 0)
+- goto invalid;
++ return res;
++
++fail:
++ pr_warn_ratelimited("overlayfs: failed to get xattr %s: err=%zi)\n",
++ name, res);
++ kfree(buf);
++ return res;
++}
++
++char *ovl_get_redirect_xattr(struct dentry *dentry, int padding)
++{
++ int res;
++ char *s, *next, *buf = NULL;
+
+- res = vfs_getxattr(dentry, OVL_XATTR_REDIRECT, buf, res);
++ res = ovl_getxattr(dentry, OVL_XATTR_REDIRECT, &buf, padding + 1);
++ if (res == -ENODATA)
++ return NULL;
+ if (res < 0)
+- goto fail;
++ return ERR_PTR(res);
+ if (res == 0)
+ goto invalid;
+
+@@ -900,15 +921,9 @@ char *ovl_get_redirect_xattr(struct dent
+ }
+
+ return buf;
+-
+-err_free:
+- kfree(buf);
+- return ERR_PTR(res);
+-fail:
+- pr_warn_ratelimited("overlayfs: failed to get redirect (%i)\n", res);
+- goto err_free;
+ invalid:
+ pr_warn_ratelimited("overlayfs: invalid redirect (%s)\n", buf);
+ res = -EINVAL;
+- goto err_free;
++ kfree(buf);
++ return ERR_PTR(res);
+ }
--- /dev/null
+From 5f32879ea35523b9842bdbdc0065e13635caada2 Mon Sep 17 00:00:00 2001
+From: Vivek Goyal <vgoyal@redhat.com>
+Date: Fri, 11 Jan 2019 19:37:00 +0100
+Subject: ovl: During copy up, first copy up data and then xattrs
+
+From: Vivek Goyal <vgoyal@redhat.com>
+
+commit 5f32879ea35523b9842bdbdc0065e13635caada2 upstream.
+
+If a file with capability set (and hence security.capability xattr) is
+written kernel clears security.capability xattr. For overlay, during file
+copy up if xattrs are copied up first and then data is, copied up. This
+means data copy up will result in clearing of security.capability xattr
+file on lower has. And this can result into surprises. If a lower file has
+CAP_SETUID, then it should not be cleared over copy up (if nothing was
+actually written to file).
+
+This also creates problems with chown logic where it first copies up file
+and then tries to clear setuid bit. But by that time security.capability
+xattr is already gone (due to data copy up), and caller gets -ENODATA.
+This has been reported by Giuseppe here.
+
+https://github.com/containers/libpod/issues/2015#issuecomment-447824842
+
+Fix this by copying up data first and then metadta. This is a regression
+which has been introduced by my commit as part of metadata only copy up
+patches.
+
+TODO: There will be some corner cases where a file is copied up metadata
+only and later data copy up happens and that will clear security.capability
+xattr. Something needs to be done about that too.
+
+Fixes: bd64e57586d3 ("ovl: During copy up, first copy up metadata and then data")
+Cc: <stable@vger.kernel.org> # v4.19+
+Reported-by: Giuseppe Scrivano <gscrivan@redhat.com>
+Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/overlayfs/copy_up.c | 31 ++++++++++++++++++-------------
+ 1 file changed, 18 insertions(+), 13 deletions(-)
+
+--- a/fs/overlayfs/copy_up.c
++++ b/fs/overlayfs/copy_up.c
+@@ -443,6 +443,24 @@ static int ovl_copy_up_inode(struct ovl_
+ {
+ int err;
+
++ /*
++ * Copy up data first and then xattrs. Writing data after
++ * xattrs will remove security.capability xattr automatically.
++ */
++ if (S_ISREG(c->stat.mode) && !c->metacopy) {
++ struct path upperpath, datapath;
++
++ ovl_path_upper(c->dentry, &upperpath);
++ if (WARN_ON(upperpath.dentry != NULL))
++ return -EIO;
++ upperpath.dentry = temp;
++
++ ovl_path_lowerdata(c->dentry, &datapath);
++ err = ovl_copy_up_data(&datapath, &upperpath, c->stat.size);
++ if (err)
++ return err;
++ }
++
+ err = ovl_copy_xattr(c->lowerpath.dentry, temp);
+ if (err)
+ return err;
+@@ -459,19 +477,6 @@ static int ovl_copy_up_inode(struct ovl_
+ if (err)
+ return err;
+ }
+-
+- if (S_ISREG(c->stat.mode) && !c->metacopy) {
+- struct path upperpath, datapath;
+-
+- ovl_path_upper(c->dentry, &upperpath);
+- BUG_ON(upperpath.dentry != NULL);
+- upperpath.dentry = temp;
+-
+- ovl_path_lowerdata(c->dentry, &datapath);
+- err = ovl_copy_up_data(&datapath, &upperpath, c->stat.size);
+- if (err)
+- return err;
+- }
+
+ if (c->metacopy) {
+ err = ovl_check_setxattr(c->dentry, temp, OVL_XATTR_METACOPY,
--- /dev/null
+From 0ab66b3c326ef8f77dae9f528118966365757c0c Mon Sep 17 00:00:00 2001
+From: Mark Zhang <markz@nvidia.com>
+Date: Thu, 10 Jan 2019 12:11:16 +0800
+Subject: regulator: max77620: Initialize values for DT properties
+
+From: Mark Zhang <markz@nvidia.com>
+
+commit 0ab66b3c326ef8f77dae9f528118966365757c0c upstream.
+
+If regulator DT node doesn't exist, its of_parse_cb callback
+function isn't called. Then all values for DT properties are
+filled with zero. This leads to wrong register update for
+FPS and POK settings.
+
+Signed-off-by: Jinyoung Park <jinyoungp@nvidia.com>
+Signed-off-by: Mark Zhang <markz@nvidia.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/max77620-regulator.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/regulator/max77620-regulator.c
++++ b/drivers/regulator/max77620-regulator.c
+@@ -1,7 +1,7 @@
+ /*
+ * Maxim MAX77620 Regulator driver
+ *
+- * Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
++ * Copyright (c) 2016-2018, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Author: Mallikarjun Kasoju <mkasoju@nvidia.com>
+ * Laxman Dewangan <ldewangan@nvidia.com>
+@@ -803,6 +803,14 @@ static int max77620_regulator_probe(stru
+ rdesc = &rinfo[id].desc;
+ pmic->rinfo[id] = &max77620_regs_info[id];
+ pmic->enable_power_mode[id] = MAX77620_POWER_MODE_NORMAL;
++ pmic->reg_pdata[id].active_fps_src = -1;
++ pmic->reg_pdata[id].active_fps_pd_slot = -1;
++ pmic->reg_pdata[id].active_fps_pu_slot = -1;
++ pmic->reg_pdata[id].suspend_fps_src = -1;
++ pmic->reg_pdata[id].suspend_fps_pd_slot = -1;
++ pmic->reg_pdata[id].suspend_fps_pu_slot = -1;
++ pmic->reg_pdata[id].power_ok = -1;
++ pmic->reg_pdata[id].ramp_rate_setting = -1;
+
+ ret = max77620_read_slew_rate(pmic, id);
+ if (ret < 0)
--- /dev/null
+From 28c4f730d2a44f2591cb104091da29a38dac49fe Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Tue, 12 Feb 2019 21:51:18 +0000
+Subject: regulator: s2mpa01: Fix step values for some LDOs
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream.
+
+The step values for some of the LDOs appears to be incorrect, resulting
+in incorrect voltages (or at least, ones which are different from the
+Samsung 3.4 vendor kernel).
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/s2mpa01.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/regulator/s2mpa01.c
++++ b/drivers/regulator/s2mpa01.c
+@@ -298,13 +298,13 @@ static const struct regulator_desc regul
+ regulator_desc_ldo(2, STEP_50_MV),
+ regulator_desc_ldo(3, STEP_50_MV),
+ regulator_desc_ldo(4, STEP_50_MV),
+- regulator_desc_ldo(5, STEP_50_MV),
++ regulator_desc_ldo(5, STEP_25_MV),
+ regulator_desc_ldo(6, STEP_25_MV),
+ regulator_desc_ldo(7, STEP_50_MV),
+ regulator_desc_ldo(8, STEP_50_MV),
+ regulator_desc_ldo(9, STEP_50_MV),
+ regulator_desc_ldo(10, STEP_50_MV),
+- regulator_desc_ldo(11, STEP_25_MV),
++ regulator_desc_ldo(11, STEP_50_MV),
+ regulator_desc_ldo(12, STEP_50_MV),
+ regulator_desc_ldo(13, STEP_50_MV),
+ regulator_desc_ldo(14, STEP_50_MV),
+@@ -315,11 +315,11 @@ static const struct regulator_desc regul
+ regulator_desc_ldo(19, STEP_50_MV),
+ regulator_desc_ldo(20, STEP_50_MV),
+ regulator_desc_ldo(21, STEP_50_MV),
+- regulator_desc_ldo(22, STEP_25_MV),
+- regulator_desc_ldo(23, STEP_25_MV),
++ regulator_desc_ldo(22, STEP_50_MV),
++ regulator_desc_ldo(23, STEP_50_MV),
+ regulator_desc_ldo(24, STEP_50_MV),
+ regulator_desc_ldo(25, STEP_50_MV),
+- regulator_desc_ldo(26, STEP_50_MV),
++ regulator_desc_ldo(26, STEP_25_MV),
+ regulator_desc_buck1_4(1),
+ regulator_desc_buck1_4(2),
+ regulator_desc_buck1_4(3),
--- /dev/null
+From 56b5d4ea778c1b0989c5cdb5406d4a488144c416 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzk@kernel.org>
+Date: Sat, 9 Feb 2019 18:14:14 +0100
+Subject: regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
+
+From: Krzysztof Kozlowski <krzk@kernel.org>
+
+commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream.
+
+LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step
+instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or
+under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420
+Arndale Octa board).
+
+Cc: <stable@vger.kernel.org>
+Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver")
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/s2mps11.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/regulator/s2mps11.c
++++ b/drivers/regulator/s2mps11.c
+@@ -362,7 +362,7 @@ static const struct regulator_desc s2mps
+ regulator_desc_s2mps11_ldo(32, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(33, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(34, STEP_50_MV),
+- regulator_desc_s2mps11_ldo(35, STEP_50_MV),
++ regulator_desc_s2mps11_ldo(35, STEP_25_MV),
+ regulator_desc_s2mps11_ldo(36, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(37, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(38, STEP_50_MV),
+@@ -372,8 +372,8 @@ static const struct regulator_desc s2mps
+ regulator_desc_s2mps11_buck1_4(4),
+ regulator_desc_s2mps11_buck5,
+ regulator_desc_s2mps11_buck67810(6, MIN_600_MV, STEP_6_25_MV),
+- regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_6_25_MV),
+- regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_6_25_MV),
++ regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_12_5_MV),
++ regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_12_5_MV),
+ regulator_desc_s2mps11_buck9,
+ regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV),
+ };
--- /dev/null
+From 8727638426b0aea59d7f904ad8ddf483f9234f88 Mon Sep 17 00:00:00 2001
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Date: Thu, 14 Feb 2019 15:40:56 +0100
+Subject: s390/setup: fix early warning messages
+
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+
+commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream.
+
+The setup_lowcore() function creates a new prefix page for the boot CPU.
+The PSW mask for the system_call, external interrupt, i/o interrupt and
+the program check handler have the DAT bit set in this new prefix page.
+
+At the time setup_lowcore is called the system still runs without virtual
+address translation, the paging_init() function creates the kernel page
+table and loads the CR13 with the kernel ASCE.
+
+Any code between setup_lowcore() and the end of paging_init() that has
+a BUG or WARN statement will create a program check that can not be
+handled correctly as there is no kernel page table yet.
+
+To allow early WARN statements initially setup the lowcore with DAT off
+and set the DAT bit only after paging_init() has completed.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/setup.c | 32 +++++++++++++++++++++++---------
+ 1 file changed, 23 insertions(+), 9 deletions(-)
+
+--- a/arch/s390/kernel/setup.c
++++ b/arch/s390/kernel/setup.c
+@@ -369,7 +369,7 @@ void __init arch_call_rest_init(void)
+ : : [_frame] "a" (frame));
+ }
+
+-static void __init setup_lowcore(void)
++static void __init setup_lowcore_dat_off(void)
+ {
+ struct lowcore *lc;
+
+@@ -380,19 +380,16 @@ static void __init setup_lowcore(void)
+ lc = memblock_alloc_low(sizeof(*lc), sizeof(*lc));
+ lc->restart_psw.mask = PSW_KERNEL_BITS;
+ lc->restart_psw.addr = (unsigned long) restart_int_handler;
+- lc->external_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_MCHECK;
++ lc->external_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK;
+ lc->external_new_psw.addr = (unsigned long) ext_int_handler;
+ lc->svc_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK;
++ PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK;
+ lc->svc_new_psw.addr = (unsigned long) system_call;
+- lc->program_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_MCHECK;
++ lc->program_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK;
+ lc->program_new_psw.addr = (unsigned long) pgm_check_handler;
+ lc->mcck_new_psw.mask = PSW_KERNEL_BITS;
+ lc->mcck_new_psw.addr = (unsigned long) mcck_int_handler;
+- lc->io_new_psw.mask = PSW_KERNEL_BITS |
+- PSW_MASK_DAT | PSW_MASK_MCHECK;
++ lc->io_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK;
+ lc->io_new_psw.addr = (unsigned long) io_int_handler;
+ lc->clock_comparator = clock_comparator_max;
+ lc->nodat_stack = ((unsigned long) &init_thread_union)
+@@ -452,6 +449,17 @@ static void __init setup_lowcore(void)
+ lowcore_ptr[0] = lc;
+ }
+
++static void __init setup_lowcore_dat_on(void)
++{
++ struct lowcore *lc;
++
++ lc = lowcore_ptr[0];
++ lc->external_new_psw.mask |= PSW_MASK_DAT;
++ lc->svc_new_psw.mask |= PSW_MASK_DAT;
++ lc->program_new_psw.mask |= PSW_MASK_DAT;
++ lc->io_new_psw.mask |= PSW_MASK_DAT;
++}
++
+ static struct resource code_resource = {
+ .name = "Kernel code",
+ .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+@@ -1072,7 +1080,7 @@ void __init setup_arch(char **cmdline_p)
+ #endif
+
+ setup_resources();
+- setup_lowcore();
++ setup_lowcore_dat_off();
+ smp_fill_possible_mask();
+ cpu_detect_mhz_feature();
+ cpu_init();
+@@ -1085,6 +1093,12 @@ void __init setup_arch(char **cmdline_p)
+ */
+ paging_init();
+
++ /*
++ * After paging_init created the kernel page table, the new PSWs
++ * in lowcore can now run with DAT enabled.
++ */
++ setup_lowcore_dat_on();
++
+ /* Setup default console */
+ conmode_default();
+ set_preferred_console();
--- /dev/null
+From 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 Mon Sep 17 00:00:00 2001
+From: Pierre Morel <pmorel@linux.ibm.com>
+Date: Tue, 12 Feb 2019 16:53:45 +0100
+Subject: s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
+
+From: Pierre Morel <pmorel@linux.ibm.com>
+
+commit 36360658eb5a6cf04bb9f2704d1e4ce54037ec99 upstream.
+
+Libudev relies on having a subsystem link for non-root devices. To
+avoid libudev (and potentially other userspace tools) choking on the
+matrix device let us introduce a matrix bus and with it the matrix
+bus subsytem. Also make the matrix device reside within the matrix
+bus.
+
+Doing this we remove the forced link from the matrix device to the
+vfio_ap driver and the device_type we do not need anymore.
+
+Since the associated matrix driver is not the vfio_ap driver any more,
+we have to change the search for the devices on the vfio_ap driver in
+the function vfio_ap_verify_queue_reserved.
+Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver")
+Cc: stable@vger.kernel.org
+
+Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
+Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
+Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Reviewed-by: Cornelia Huck <cohuck@redhat.com>
+Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>
+Acked-by: Halil Pasic <pasic@linux.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/crypto/vfio_ap_drv.c | 44 +++++++++++++++++++++++++++-------
+ drivers/s390/crypto/vfio_ap_ops.c | 4 +--
+ drivers/s390/crypto/vfio_ap_private.h | 1
+ 3 files changed, 38 insertions(+), 11 deletions(-)
+
+--- a/drivers/s390/crypto/vfio_ap_drv.c
++++ b/drivers/s390/crypto/vfio_ap_drv.c
+@@ -15,7 +15,6 @@
+ #include "vfio_ap_private.h"
+
+ #define VFIO_AP_ROOT_NAME "vfio_ap"
+-#define VFIO_AP_DEV_TYPE_NAME "ap_matrix"
+ #define VFIO_AP_DEV_NAME "matrix"
+
+ MODULE_AUTHOR("IBM Corporation");
+@@ -24,10 +23,6 @@ MODULE_LICENSE("GPL v2");
+
+ static struct ap_driver vfio_ap_drv;
+
+-static struct device_type vfio_ap_dev_type = {
+- .name = VFIO_AP_DEV_TYPE_NAME,
+-};
+-
+ struct ap_matrix_dev *matrix_dev;
+
+ /* Only type 10 adapters (CEX4 and later) are supported
+@@ -62,6 +57,22 @@ static void vfio_ap_matrix_dev_release(s
+ kfree(matrix_dev);
+ }
+
++static int matrix_bus_match(struct device *dev, struct device_driver *drv)
++{
++ return 1;
++}
++
++static struct bus_type matrix_bus = {
++ .name = "matrix",
++ .match = &matrix_bus_match,
++};
++
++static struct device_driver matrix_driver = {
++ .name = "vfio_ap",
++ .bus = &matrix_bus,
++ .suppress_bind_attrs = true,
++};
++
+ static int vfio_ap_matrix_dev_create(void)
+ {
+ int ret;
+@@ -71,6 +82,10 @@ static int vfio_ap_matrix_dev_create(voi
+ if (IS_ERR(root_device))
+ return PTR_ERR(root_device);
+
++ ret = bus_register(&matrix_bus);
++ if (ret)
++ goto bus_register_err;
++
+ matrix_dev = kzalloc(sizeof(*matrix_dev), GFP_KERNEL);
+ if (!matrix_dev) {
+ ret = -ENOMEM;
+@@ -87,30 +102,41 @@ static int vfio_ap_matrix_dev_create(voi
+ mutex_init(&matrix_dev->lock);
+ INIT_LIST_HEAD(&matrix_dev->mdev_list);
+
+- matrix_dev->device.type = &vfio_ap_dev_type;
+ dev_set_name(&matrix_dev->device, "%s", VFIO_AP_DEV_NAME);
+ matrix_dev->device.parent = root_device;
++ matrix_dev->device.bus = &matrix_bus;
+ matrix_dev->device.release = vfio_ap_matrix_dev_release;
+- matrix_dev->device.driver = &vfio_ap_drv.driver;
++ matrix_dev->vfio_ap_drv = &vfio_ap_drv;
+
+ ret = device_register(&matrix_dev->device);
+ if (ret)
+ goto matrix_reg_err;
+
++ ret = driver_register(&matrix_driver);
++ if (ret)
++ goto matrix_drv_err;
++
+ return 0;
+
++matrix_drv_err:
++ device_unregister(&matrix_dev->device);
+ matrix_reg_err:
+ put_device(&matrix_dev->device);
+ matrix_alloc_err:
++ bus_unregister(&matrix_bus);
++bus_register_err:
+ root_device_unregister(root_device);
+-
+ return ret;
+ }
+
+ static void vfio_ap_matrix_dev_destroy(void)
+ {
++ struct device *root_device = matrix_dev->device.parent;
++
++ driver_unregister(&matrix_driver);
+ device_unregister(&matrix_dev->device);
+- root_device_unregister(matrix_dev->device.parent);
++ bus_unregister(&matrix_bus);
++ root_device_unregister(root_device);
+ }
+
+ static int __init vfio_ap_init(void)
+--- a/drivers/s390/crypto/vfio_ap_ops.c
++++ b/drivers/s390/crypto/vfio_ap_ops.c
+@@ -198,8 +198,8 @@ static int vfio_ap_verify_queue_reserved
+ qres.apqi = apqi;
+ qres.reserved = false;
+
+- ret = driver_for_each_device(matrix_dev->device.driver, NULL, &qres,
+- vfio_ap_has_queue);
++ ret = driver_for_each_device(&matrix_dev->vfio_ap_drv->driver, NULL,
++ &qres, vfio_ap_has_queue);
+ if (ret)
+ return ret;
+
+--- a/drivers/s390/crypto/vfio_ap_private.h
++++ b/drivers/s390/crypto/vfio_ap_private.h
+@@ -40,6 +40,7 @@ struct ap_matrix_dev {
+ struct ap_config_info info;
+ struct list_head mdev_list;
+ struct mutex lock;
++ struct ap_driver *vfio_ap_drv;
+ };
+
+ extern struct ap_matrix_dev *matrix_dev;
--- /dev/null
+From 3438b2c039b4bf26881786a1f3450f016d66ad11 Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Mon, 21 Jan 2019 13:19:43 +0100
+Subject: s390/virtio: handle find on invalid queue gracefully
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit 3438b2c039b4bf26881786a1f3450f016d66ad11 upstream.
+
+A queue with a capacity of zero is clearly not a valid virtio queue.
+Some emulators report zero queue size if queried with an invalid queue
+index. Instead of crashing in this case let us just return -ENOENT. To
+make that work properly, let us fix the notifier cleanup logic as well.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Signed-off-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/virtio/virtio_ccw.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/s390/virtio/virtio_ccw.c
++++ b/drivers/s390/virtio/virtio_ccw.c
+@@ -272,6 +272,8 @@ static void virtio_ccw_drop_indicators(s
+ {
+ struct virtio_ccw_vq_info *info;
+
++ if (!vcdev->airq_info)
++ return;
+ list_for_each_entry(info, &vcdev->virtqueues, node)
+ drop_airq_indicator(info->vq, vcdev->airq_info);
+ }
+@@ -413,7 +415,7 @@ static int virtio_ccw_read_vq_conf(struc
+ ret = ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_READ_VQ_CONF);
+ if (ret)
+ return ret;
+- return vcdev->config_block->num;
++ return vcdev->config_block->num ?: -ENOENT;
+ }
+
+ static void virtio_ccw_del_vq(struct virtqueue *vq, struct ccw1 *ccw)
--- /dev/null
+From 0015437cc046e5ec2b57b00ff8312b8d432eac7c Mon Sep 17 00:00:00 2001
+From: Sagar Biradar <sagar.biradar@microchip.com>
+Date: Thu, 7 Mar 2019 23:26:41 -0800
+Subject: scsi: aacraid: Fix performance issue on logical drives
+
+From: Sagar Biradar <sagar.biradar@microchip.com>
+
+commit 0015437cc046e5ec2b57b00ff8312b8d432eac7c upstream.
+
+Fix performance issue where the queue depth for SmartIOC logical volumes is
+set to 1, and allow the usual logical volume code to be executed
+
+Fixes: a052865fe287 (aacraid: Set correct Queue Depth for HBA1000 RAW disks)
+Cc: stable@vger.kernel.org
+Signed-off-by: Sagar Biradar <Sagar.Biradar@microchip.com>
+Reviewed-by: Dave Carroll <david.carroll@microsemi.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/aacraid/linit.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/scsi/aacraid/linit.c
++++ b/drivers/scsi/aacraid/linit.c
+@@ -413,13 +413,16 @@ static int aac_slave_configure(struct sc
+ if (chn < AAC_MAX_BUSES && tid < AAC_MAX_TARGETS && aac->sa_firmware) {
+ devtype = aac->hba_map[chn][tid].devtype;
+
+- if (devtype == AAC_DEVTYPE_NATIVE_RAW)
++ if (devtype == AAC_DEVTYPE_NATIVE_RAW) {
+ depth = aac->hba_map[chn][tid].qd_limit;
+- else if (devtype == AAC_DEVTYPE_ARC_RAW)
++ set_timeout = 1;
++ goto common_config;
++ }
++ if (devtype == AAC_DEVTYPE_ARC_RAW) {
+ set_qd_dev_type = true;
+-
+- set_timeout = 1;
+- goto common_config;
++ set_timeout = 1;
++ goto common_config;
++ }
+ }
+
+ if (aac->jbod && (sdev->type == TYPE_DISK))
--- /dev/null
+From f3e026951771bceb17319a4d0d6121ca58746c88 Mon Sep 17 00:00:00 2001
+From: Giridhar Malavali <gmalavali@marvell.com>
+Date: Fri, 15 Feb 2019 16:42:55 -0800
+Subject: scsi: qla2xxx: Avoid PCI IRQ affinity mapping when multiqueue is not supported
+
+From: Giridhar Malavali <gmalavali@marvell.com>
+
+commit f3e026951771bceb17319a4d0d6121ca58746c88 upstream.
+
+This patch fixes warning seen when BLK-MQ is enabled and hardware does not
+support MQ. This will result into driver requesting MSIx vectors which are
+equal or less than pre_desc via PCI IRQ Affinity infrastructure.
+
+ [ 19.746300] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00.12-k.
+ [ 19.746599] qla2xxx [0000:02:00.0]-001d: : Found an ISP2432 irq 18 iobase 0x(____ptrval____).
+ [ 20.203186] ------------[ cut here ]------------
+ [ 20.203306] WARNING: CPU: 8 PID: 268 at drivers/pci/msi.c:1273 pci_irq_get_affinity+0xf4/0x120
+ [ 20.203481] Modules linked in: tg3 ptp qla2xxx(+) pps_core sg libphy scsi_transport_fc flash loop autofs4
+ [ 20.203700] CPU: 8 PID: 268 Comm: systemd-udevd Not tainted 5.0.0-rc5-00358-gdf3865f #113
+ [ 20.203830] Call Trace:
+ [ 20.203933] [0000000000461bb0] __warn+0xb0/0xe0
+ [ 20.204090] [00000000006c8f34] pci_irq_get_affinity+0xf4/0x120
+ [ 20.204219] [000000000068c764] blk_mq_pci_map_queues+0x24/0x120
+ [ 20.204396] [00000000007162f4] scsi_map_queues+0x14/0x40
+ [ 20.204626] [0000000000673654] blk_mq_update_queue_map+0x94/0xe0
+ [ 20.204698] [0000000000676ce0] blk_mq_alloc_tag_set+0x120/0x300
+ [ 20.204869] [000000000071077c] scsi_add_host_with_dma+0x7c/0x300
+ [ 20.205419] [00000000100ead54] qla2x00_probe_one+0x19d4/0x2640 [qla2xxx]
+ [ 20.205621] [00000000006b3c88] pci_device_probe+0xc8/0x160
+ [ 20.205697] [0000000000701c0c] really_probe+0x1ac/0x2e0
+ [ 20.205770] [0000000000701f90] driver_probe_device+0x50/0x100
+ [ 20.205843] [0000000000702134] __driver_attach+0xf4/0x120
+ [ 20.205913] [0000000000700644] bus_for_each_dev+0x44/0x80
+ [ 20.206081] [0000000000700c98] bus_add_driver+0x198/0x220
+ [ 20.206300] [0000000000702950] driver_register+0x70/0x120
+ [ 20.206582] [0000000010248224] qla2x00_module_init+0x224/0x284 [qla2xxx]
+ [ 20.206857] ---[ end trace b1de7a3f79fab2c2 ]---
+
+The fix is to check if the hardware does not have Multi Queue capabiltiy,
+use pci_alloc_irq_vectors() call instead of pci_alloc_irq_affinity().
+
+Fixes: f664a3cc17b7d ("scsi: kill off the legacy IO path")
+Cc: stable@vger.kernel.org #4.19
+Signed-off-by: Giridhar Malavali <gmalavali@marvell.com>
+Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/qla2xxx/qla_isr.c | 2 +-
+ drivers/scsi/qla2xxx/qla_os.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_isr.c
++++ b/drivers/scsi/qla2xxx/qla_isr.c
+@@ -3410,7 +3410,7 @@ qla24xx_enable_msix(struct qla_hw_data *
+ min_vecs++;
+ }
+
+- if (USER_CTRL_IRQ(ha)) {
++ if (USER_CTRL_IRQ(ha) || !ha->mqiobase) {
+ /* user wants to control IRQ setting for target mode */
+ ret = pci_alloc_irq_vectors(ha->pdev, min_vecs,
+ ha->msix_count, PCI_IRQ_MSIX);
+--- a/drivers/scsi/qla2xxx/qla_os.c
++++ b/drivers/scsi/qla2xxx/qla_os.c
+@@ -6936,7 +6936,7 @@ static int qla2xxx_map_queues(struct Scs
+ scsi_qla_host_t *vha = (scsi_qla_host_t *)shost->hostdata;
+ struct blk_mq_queue_map *qmap = &shost->tag_set.map[0];
+
+- if (USER_CTRL_IRQ(vha->hw))
++ if (USER_CTRL_IRQ(vha->hw) || !vha->hw->mqiobase)
+ rc = blk_mq_map_queues(qmap);
+ else
+ rc = blk_mq_pci_map_queues(qmap, vha->hw->pdev, vha->irq_offset);
--- /dev/null
+From ec322937a7f152d68755dc8316523bf6f831b48f Mon Sep 17 00:00:00 2001
+From: Himanshu Madhani <hmadhani@marvell.com>
+Date: Fri, 15 Feb 2019 14:37:12 -0800
+Subject: scsi: qla2xxx: Fix LUN discovery if loop id is not assigned yet by firmware
+
+From: Himanshu Madhani <hmadhani@marvell.com>
+
+commit ec322937a7f152d68755dc8316523bf6f831b48f upstream.
+
+This patch fixes LUN discovery when loop ID is not yet assigned by the
+firmware during driver load/sg_reset operations. Driver will now search for
+new loop id before retrying login.
+
+Fixes: 48acad099074 ("scsi: qla2xxx: Fix N2N link re-connect")
+Cc: stable@vger.kernel.org #4.19
+Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/qla2xxx/qla_init.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_init.c
++++ b/drivers/scsi/qla2xxx/qla_init.c
+@@ -644,11 +644,14 @@ static void qla24xx_handle_gnl_done_even
+ break;
+ case DSC_LS_PORT_UNAVAIL:
+ default:
+- if (fcport->loop_id != FC_NO_LOOP_ID)
+- qla2x00_clear_loop_id(fcport);
+-
+- fcport->loop_id = loop_id;
+- fcport->fw_login_state = DSC_LS_PORT_UNAVAIL;
++ if (fcport->loop_id == FC_NO_LOOP_ID) {
++ qla2x00_find_new_loop_id(vha, fcport);
++ fcport->fw_login_state =
++ DSC_LS_PORT_UNAVAIL;
++ }
++ ql_dbg(ql_dbg_disc, vha, 0x20e5,
++ "%s %d %8phC\n", __func__, __LINE__,
++ fcport->port_name);
+ qla24xx_fcport_handle_login(vha, fcport);
+ break;
+ }
--- /dev/null
+From 1560bafdff9ed54857ac3a03c4c8d8f10d791ba6 Mon Sep 17 00:00:00 2001
+From: Quinn Tran <qtran@marvell.com>
+Date: Thu, 24 Jan 2019 23:23:50 -0800
+Subject: scsi: qla2xxx: Use complete switch scan for RSCN events
+
+From: Quinn Tran <qtran@marvell.com>
+
+commit 1560bafdff9ed54857ac3a03c4c8d8f10d791ba6 upstream.
+
+This patch removes unnecessary code to handle RSCN, instead performs full
+scan everytime driver receives RSCN
+
+Fixes: d4f7a16aeca6f ("scsi: qla2xxx: Remove ASYNC GIDPN switch command")
+Cc: stable@vger.kernel.org #4.19
+Signed-off-by: Quinn Tran <qtran@marvell.com>
+Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/qla2xxx/qla_init.c | 86 ----------------------------------------
+ 1 file changed, 86 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_init.c
++++ b/drivers/scsi/qla2xxx/qla_init.c
+@@ -1474,29 +1474,6 @@ int qla24xx_fcport_handle_login(struct s
+ return 0;
+ }
+
+-static
+-void qla24xx_handle_rscn_event(fc_port_t *fcport, struct event_arg *ea)
+-{
+- fcport->rscn_gen++;
+-
+- ql_dbg(ql_dbg_disc, fcport->vha, 0x210c,
+- "%s %8phC DS %d LS %d\n",
+- __func__, fcport->port_name, fcport->disc_state,
+- fcport->fw_login_state);
+-
+- if (fcport->flags & FCF_ASYNC_SENT)
+- return;
+-
+- switch (fcport->disc_state) {
+- case DSC_DELETED:
+- case DSC_LOGIN_COMPLETE:
+- qla24xx_post_gpnid_work(fcport->vha, &ea->id);
+- break;
+- default:
+- break;
+- }
+-}
+-
+ int qla24xx_post_newsess_work(struct scsi_qla_host *vha, port_id_t *id,
+ u8 *port_name, u8 *node_name, void *pla, u8 fc4_type)
+ {
+@@ -1563,8 +1540,6 @@ static void qla_handle_els_plogi_done(sc
+
+ void qla2x00_fcport_event_handler(scsi_qla_host_t *vha, struct event_arg *ea)
+ {
+- fc_port_t *f, *tf;
+- uint32_t id = 0, mask, rid;
+ fc_port_t *fcport;
+
+ switch (ea->event) {
+@@ -1577,10 +1552,6 @@ void qla2x00_fcport_event_handler(scsi_q
+ case FCME_RSCN:
+ if (test_bit(UNLOADING, &vha->dpc_flags))
+ return;
+- switch (ea->id.b.rsvd_1) {
+- case RSCN_PORT_ADDR:
+-#define BIGSCAN 1
+-#if defined BIGSCAN & BIGSCAN > 0
+ {
+ unsigned long flags;
+ fcport = qla2x00_find_fcport_by_nportid
+@@ -1599,59 +1570,6 @@ void qla2x00_fcport_event_handler(scsi_q
+ }
+ spin_unlock_irqrestore(&vha->work_lock, flags);
+ }
+-#else
+- {
+- int rc;
+- fcport = qla2x00_find_fcport_by_nportid(vha, &ea->id, 1);
+- if (!fcport) {
+- /* cable moved */
+- rc = qla24xx_post_gpnid_work(vha, &ea->id);
+- if (rc) {
+- ql_log(ql_log_warn, vha, 0xd044,
+- "RSCN GPNID work failed %06x\n",
+- ea->id.b24);
+- }
+- } else {
+- ea->fcport = fcport;
+- fcport->scan_needed = 1;
+- qla24xx_handle_rscn_event(fcport, ea);
+- }
+- }
+-#endif
+- break;
+- case RSCN_AREA_ADDR:
+- case RSCN_DOM_ADDR:
+- if (ea->id.b.rsvd_1 == RSCN_AREA_ADDR) {
+- mask = 0xffff00;
+- ql_dbg(ql_dbg_async, vha, 0x5044,
+- "RSCN: Area 0x%06x was affected\n",
+- ea->id.b24);
+- } else {
+- mask = 0xff0000;
+- ql_dbg(ql_dbg_async, vha, 0x507a,
+- "RSCN: Domain 0x%06x was affected\n",
+- ea->id.b24);
+- }
+-
+- rid = ea->id.b24 & mask;
+- list_for_each_entry_safe(f, tf, &vha->vp_fcports,
+- list) {
+- id = f->d_id.b24 & mask;
+- if (rid == id) {
+- ea->fcport = f;
+- qla24xx_handle_rscn_event(f, ea);
+- }
+- }
+- break;
+- case RSCN_FAB_ADDR:
+- default:
+- ql_log(ql_log_warn, vha, 0xd045,
+- "RSCN: Fabric was affected. Addr format %d\n",
+- ea->id.b.rsvd_1);
+- qla2x00_mark_all_devices_lost(vha, 1);
+- set_bit(LOOP_RESYNC_NEEDED, &vha->dpc_flags);
+- set_bit(LOCAL_LOOP_UPDATE, &vha->dpc_flags);
+- }
+ break;
+ case FCME_GNL_DONE:
+ qla24xx_handle_gnl_done_event(vha, ea);
+@@ -1712,11 +1630,7 @@ void qla_rscn_replay(fc_port_t *fcport)
+ ea.event = FCME_RSCN;
+ ea.id = fcport->d_id;
+ ea.id.b.rsvd_1 = RSCN_PORT_ADDR;
+-#if defined BIGSCAN & BIGSCAN > 0
+ qla2x00_fcport_event_handler(fcport->vha, &ea);
+-#else
+- qla24xx_post_gpnid_work(fcport->vha, &ea.id);
+-#endif
+ }
+ }
+
--- /dev/null
+From a83da8a4509d3ebfe03bb7fffce022e4d5d4764f Mon Sep 17 00:00:00 2001
+From: "Martin K. Petersen" <martin.petersen@oracle.com>
+Date: Tue, 12 Feb 2019 16:21:05 -0500
+Subject: scsi: sd: Optimal I/O size should be a multiple of physical block size
+
+From: Martin K. Petersen <martin.petersen@oracle.com>
+
+commit a83da8a4509d3ebfe03bb7fffce022e4d5d4764f upstream.
+
+It was reported that some devices report an OPTIMAL TRANSFER LENGTH of
+0xFFFF blocks. That looks bogus, especially for a device with a
+4096-byte physical block size.
+
+Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's
+reported physical block size.
+
+To make the sanity checking conditionals more readable--and to
+facilitate printing warnings--relocate the checking to a helper
+function. No functional change aside from the printks.
+
+Cc: <stable@vger.kernel.org>
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759
+Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sd.c | 59 +++++++++++++++++++++++++++++++++++++++++++++---------
+ 1 file changed, 50 insertions(+), 9 deletions(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -3047,6 +3047,55 @@ static void sd_read_security(struct scsi
+ sdkp->security = 1;
+ }
+
++/*
++ * Determine the device's preferred I/O size for reads and writes
++ * unless the reported value is unreasonably small, large, not a
++ * multiple of the physical block size, or simply garbage.
++ */
++static bool sd_validate_opt_xfer_size(struct scsi_disk *sdkp,
++ unsigned int dev_max)
++{
++ struct scsi_device *sdp = sdkp->device;
++ unsigned int opt_xfer_bytes =
++ logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
++
++ if (sdkp->opt_xfer_blocks > dev_max) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u logical blocks " \
++ "> dev_max (%u logical blocks)\n",
++ sdkp->opt_xfer_blocks, dev_max);
++ return false;
++ }
++
++ if (sdkp->opt_xfer_blocks > SD_DEF_XFER_BLOCKS) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u logical blocks " \
++ "> sd driver limit (%u logical blocks)\n",
++ sdkp->opt_xfer_blocks, SD_DEF_XFER_BLOCKS);
++ return false;
++ }
++
++ if (opt_xfer_bytes < PAGE_SIZE) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u bytes < " \
++ "PAGE_SIZE (%u bytes)\n",
++ opt_xfer_bytes, (unsigned int)PAGE_SIZE);
++ return false;
++ }
++
++ if (opt_xfer_bytes & (sdkp->physical_block_size - 1)) {
++ sd_first_printk(KERN_WARNING, sdkp,
++ "Optimal transfer size %u bytes not a " \
++ "multiple of physical block size (%u bytes)\n",
++ opt_xfer_bytes, sdkp->physical_block_size);
++ return false;
++ }
++
++ sd_first_printk(KERN_INFO, sdkp, "Optimal transfer size %u bytes\n",
++ opt_xfer_bytes);
++ return true;
++}
++
+ /**
+ * sd_revalidate_disk - called the first time a new disk is seen,
+ * performs disk spin up, read_capacity, etc.
+@@ -3125,15 +3174,7 @@ static int sd_revalidate_disk(struct gen
+ dev_max = min_not_zero(dev_max, sdkp->max_xfer_blocks);
+ q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);
+
+- /*
+- * Determine the device's preferred I/O size for reads and writes
+- * unless the reported value is unreasonably small, large, or
+- * garbage.
+- */
+- if (sdkp->opt_xfer_blocks &&
+- sdkp->opt_xfer_blocks <= dev_max &&
+- sdkp->opt_xfer_blocks <= SD_DEF_XFER_BLOCKS &&
+- logical_to_bytes(sdp, sdkp->opt_xfer_blocks) >= PAGE_SIZE) {
++ if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
+ q->limits.io_opt = logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
+ rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks);
+ } else
--- /dev/null
+From 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bvanassche@acm.org>
+Date: Fri, 25 Jan 2019 10:34:56 -0800
+Subject: scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+commit 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 upstream.
+
+When using SCSI passthrough in combination with the iSCSI target driver
+then cmd->t_state_lock may be obtained from interrupt context. Hence, all
+code that obtains cmd->t_state_lock from thread context must disable
+interrupts first. This patch avoids that lockdep reports the following:
+
+WARNING: inconsistent lock state
+4.18.0-dbg+ #1 Not tainted
+--------------------------------
+inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
+iscsi_ttx/1800 [HC1[1]:SC0[2]:HE0:SE0] takes:
+000000006e7b0ceb (&(&cmd->t_state_lock)->rlock){?...}, at: target_complete_cmd+0x47/0x2c0 [target_core_mod]
+{HARDIRQ-ON-W} state was registered at:
+ lock_acquire+0xd2/0x260
+ _raw_spin_lock+0x32/0x50
+ iscsit_close_connection+0x97e/0x1020 [iscsi_target_mod]
+ iscsit_take_action_for_connection_exit+0x108/0x200 [iscsi_target_mod]
+ iscsi_target_rx_thread+0x180/0x190 [iscsi_target_mod]
+ kthread+0x1cf/0x1f0
+ ret_from_fork+0x24/0x30
+irq event stamp: 1281
+hardirqs last enabled at (1279): [<ffffffff970ade79>] __local_bh_enable_ip+0xa9/0x160
+hardirqs last disabled at (1281): [<ffffffff97a008a5>] interrupt_entry+0xb5/0xd0
+softirqs last enabled at (1278): [<ffffffff977cd9a1>] lock_sock_nested+0x51/0xc0
+softirqs last disabled at (1280): [<ffffffffc07a6e04>] ip6_finish_output2+0x124/0xe40 [ipv6]
+
+other info that might help us debug this:
+Possible unsafe locking scenario:
+
+ CPU0
+ ----
+ lock(&(&cmd->t_state_lock)->rlock);
+ <Interrupt>
+ lock(&(&cmd->t_state_lock)->rlock);
+
+---
+ drivers/target/iscsi/iscsi_target.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/target/iscsi/iscsi_target.c
++++ b/drivers/target/iscsi/iscsi_target.c
+@@ -4040,9 +4040,9 @@ static void iscsit_release_commands_from
+ struct se_cmd *se_cmd = &cmd->se_cmd;
+
+ if (se_cmd->se_tfo != NULL) {
+- spin_lock(&se_cmd->t_state_lock);
++ spin_lock_irq(&se_cmd->t_state_lock);
+ se_cmd->transport_state |= CMD_T_FABRIC_STOP;
+- spin_unlock(&se_cmd->t_state_lock);
++ spin_unlock_irq(&se_cmd->t_state_lock);
+ }
+ }
+ spin_unlock_bh(&conn->cmd_lock);
--- /dev/null
+From 3722e6a52174d7c3a00e6f5efd006ca093f346c1 Mon Sep 17 00:00:00 2001
+From: Felipe Franciosi <felipe@nutanix.com>
+Date: Wed, 27 Feb 2019 16:10:34 +0000
+Subject: scsi: virtio_scsi: don't send sc payload with tmfs
+
+From: Felipe Franciosi <felipe@nutanix.com>
+
+commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.
+
+The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of
+device-readable records and a single device-writable response entry:
+
+ struct virtio_scsi_ctrl_tmf
+ {
+ // Device-readable part
+ le32 type;
+ le32 subtype;
+ u8 lun[8];
+ le64 id;
+ // Device-writable part
+ u8 response;
+ }
+
+The above should be organised as two descriptor entries (or potentially
+more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64
+id" or after "u8 response".
+
+The Linux driver doesn't respect that, with virtscsi_abort() and
+virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf(). It
+results in the original scsi command payload (or writable buffers) added to
+the tmf.
+
+This fixes the problem by leaving cmd->sc zeroed out, which makes
+virtscsi_kick_cmd() add the tmf to the control vq without any payload.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/virtio_scsi.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/scsi/virtio_scsi.c
++++ b/drivers/scsi/virtio_scsi.c
+@@ -594,7 +594,6 @@ static int virtscsi_device_reset(struct
+ return FAILED;
+
+ memset(cmd, 0, sizeof(*cmd));
+- cmd->sc = sc;
+ cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
+ .type = VIRTIO_SCSI_T_TMF,
+ .subtype = cpu_to_virtio32(vscsi->vdev,
+@@ -653,7 +652,6 @@ static int virtscsi_abort(struct scsi_cm
+ return FAILED;
+
+ memset(cmd, 0, sizeof(*cmd));
+- cmd->sc = sc;
+ cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
+ .type = VIRTIO_SCSI_T_TMF,
+ .subtype = VIRTIO_SCSI_T_TMF_ABORT_TASK,
vmw_balloon-release-lock-on-error-in-vmballoon_reset.patch
xen-fix-dom0-boot-on-huge-systems.patch
acpi-device_sysfs-avoid-of-modalias-creation-for-removed-device.patch
+mmc-sdhci-esdhc-imx-fix-hs400-timing-issue.patch
+mmc-renesas_sdhi-fix-card-initialization-failure-in-high-speed-mode.patch
+mmc-fix-a-bug-when-max_discard-is-0.patch
+spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch
+spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch
+spi-omap2-mcspi-fix-dma-and-fifo-event-trigger-size-mismatch.patch
+spi-spi-gpio-fix-spi_cs_high-capability.patch
+regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch
+regulator-max77620-initialize-values-for-dt-properties.patch
+regulator-s2mpa01-fix-step-values-for-some-ldos.patch
+mt76-fix-corrupted-software-generated-tx-ccmp-pn.patch
+clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch
+clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch
+clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.patch
+s390-vfio_ap-link-the-vfio_ap-devices-to-the-vfio_ap-bus-subsystem.patch
+s390-setup-fix-early-warning-messages.patch
+s390-virtio-handle-find-on-invalid-queue-gracefully.patch
+virtio-introduce-virtio_max_dma_size.patch
+virtio-blk-consider-virtio_max_dma_size-for-maximum-segment-size.patch
+scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch
+scsi-aacraid-fix-performance-issue-on-logical-drives.patch
+scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch
+scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch
+scsi-qla2xxx-fix-lun-discovery-if-loop-id-is-not-assigned-yet-by-firmware.patch
+scsi-qla2xxx-avoid-pci-irq-affinity-mapping-when-multiqueue-is-not-supported.patch
+scsi-qla2xxx-use-complete-switch-scan-for-rscn-events.patch
+fs-devpts-always-delete-dcache-dentry-s-in-dput.patch
+splice-don-t-merge-into-linked-buffers.patch
+ovl-during-copy-up-first-copy-up-data-and-then-xattrs.patch
+ovl-do-not-lose-security.capability-xattr-over-metadata-file-copy-up.patch
+m68k-add-ffreestanding-to-cflags.patch
+btrfs-setup-a-nofs-context-for-memory-allocation-at-btrfs_create_tree.patch
+btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch
+btrfs-scrub-fix-circular-locking-dependency-warning.patch
+btrfs-drop-the-lock-on-error-in-btrfs_dev_replace_cancel.patch
+btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch
+btrfs-init-csum_list-before-possible-free.patch
+btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch
+btrfs-fix-deadlock-between-clone-dedupe-and-rename.patch
--- /dev/null
+From baf8b9f8d260c55a86405f70a384c29cda888476 Mon Sep 17 00:00:00 2001
+From: Vignesh R <vigneshr@ti.com>
+Date: Tue, 15 Jan 2019 12:28:32 +0530
+Subject: spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch
+
+From: Vignesh R <vigneshr@ti.com>
+
+commit baf8b9f8d260c55a86405f70a384c29cda888476 upstream.
+
+Commit b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length")
+broke SPI transfers where bits_per_word != 8. This is because of
+mimsatch between McSPI FIFO level event trigger size (SPI word length) and
+DMA request size(word length * maxburst). This leads to data
+corruption, lockup and errors like:
+
+ spi1.0: EOW timed out
+
+Fix this by setting DMA maxburst size to 1 so that
+McSPI FIFO level event trigger size matches DMA request size.
+
+Fixes: b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length")
+Cc: stable@vger.kernel.org
+Reported-by: David Lechner <david@lechnology.com>
+Tested-by: David Lechner <david@lechnology.com>
+Signed-off-by: Vignesh R <vigneshr@ti.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-omap2-mcspi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/spi/spi-omap2-mcspi.c
++++ b/drivers/spi/spi-omap2-mcspi.c
+@@ -623,8 +623,8 @@ omap2_mcspi_txrx_dma(struct spi_device *
+ cfg.dst_addr = cs->phys + OMAP2_MCSPI_TX0;
+ cfg.src_addr_width = width;
+ cfg.dst_addr_width = width;
+- cfg.src_maxburst = es;
+- cfg.dst_maxburst = es;
++ cfg.src_maxburst = 1;
++ cfg.dst_maxburst = 1;
+
+ rx = xfer->rx_buf;
+ tx = xfer->tx_buf;
--- /dev/null
+From ef070b4e4aa25bb5f8632ad196644026c11903bf Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Tue, 19 Feb 2019 23:21:28 +0300
+Subject: spi: pxa2xx: Setup maximum supported DMA transfer length
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit ef070b4e4aa25bb5f8632ad196644026c11903bf upstream.
+
+When the commit b6ced294fb61
+
+ ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
+
+switches to SPI core provided DMA helpers, it missed to setup maximum
+supported DMA transfer length for the controller and thus users
+mistakenly try to send more data than supported with the following
+warning:
+
+ ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
+
+Setup maximum supported DMA transfer length in order to make users know
+the limit.
+
+Fixes: b6ced294fb61 ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-pxa2xx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -1696,6 +1696,7 @@ static int pxa2xx_spi_probe(struct platf
+ platform_info->enable_dma = false;
+ } else {
+ master->can_dma = pxa2xx_spi_can_dma;
++ master->max_dma_len = MAX_DMA_LEN;
+ }
+ }
+
--- /dev/null
+From b89fefda7d4e3a649129584d855be233c7465264 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@armlinux.org.uk>
+Date: Thu, 21 Feb 2019 15:59:58 +0000
+Subject: spi: spi-gpio: fix SPI_CS_HIGH capability
+
+From: Russell King <rmk+kernel@armlinux.org.uk>
+
+commit b89fefda7d4e3a649129584d855be233c7465264 upstream.
+
+spi-gpio is capable of dealing with active-high chip-selects.
+Unfortunately, commit 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE
+support") broke this by setting master->mode_bits, which overrides
+the setting in the spi-bitbang code. Fix this.
+
+[Fixed a trivial conflict with SPI_3WIRE_HIZ support -- broonie]
+
+Fixes: 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support")
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-gpio.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/spi/spi-gpio.c
++++ b/drivers/spi/spi-gpio.c
+@@ -428,7 +428,8 @@ static int spi_gpio_probe(struct platfor
+ return status;
+
+ master->bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 32);
+- master->mode_bits = SPI_3WIRE | SPI_3WIRE_HIZ | SPI_CPHA | SPI_CPOL;
++ master->mode_bits = SPI_3WIRE | SPI_3WIRE_HIZ | SPI_CPHA | SPI_CPOL |
++ SPI_CS_HIGH;
+ master->flags = master_flags;
+ master->bus_num = pdev->id;
+ /* The master needs to think there is a chipselect even if not connected */
+@@ -455,7 +456,6 @@ static int spi_gpio_probe(struct platfor
+ spi_gpio->bitbang.txrx_word[SPI_MODE_3] = spi_gpio_spec_txrx_word_mode3;
+ }
+ spi_gpio->bitbang.setup_transfer = spi_bitbang_setup_transfer;
+- spi_gpio->bitbang.flags = SPI_CS_HIGH;
+
+ status = spi_bitbang_start(&spi_gpio->bitbang);
+ if (status)
--- /dev/null
+From 673c865efbdc5fec3cc525c46d71844d42c60072 Mon Sep 17 00:00:00 2001
+From: Vignesh R <vigneshr@ti.com>
+Date: Tue, 29 Jan 2019 13:14:22 +0530
+Subject: spi: ti-qspi: Fix mmap read when more than one CS in use
+
+From: Vignesh R <vigneshr@ti.com>
+
+commit 673c865efbdc5fec3cc525c46d71844d42c60072 upstream.
+
+Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has
+has got order of parameter wrong when calling regmap_update_bits() to
+select CS for mmap access. Mask and value arguments are interchanged.
+Code will work on a system with single slave, but fails when more than
+one CS is in use. Fix this by correcting the order of parameters when
+calling regmap_update_bits().
+
+Fixes: 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vignesh R <vigneshr@ti.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-ti-qspi.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/spi/spi-ti-qspi.c
++++ b/drivers/spi/spi-ti-qspi.c
+@@ -490,8 +490,8 @@ static void ti_qspi_enable_memory_map(st
+ ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+ if (qspi->ctrl_base) {
+ regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+- MEM_CS_EN(spi->chip_select),
+- MEM_CS_MASK);
++ MEM_CS_MASK,
++ MEM_CS_EN(spi->chip_select));
+ }
+ qspi->mmap_enabled = true;
+ }
+@@ -503,7 +503,7 @@ static void ti_qspi_disable_memory_map(s
+ ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+ if (qspi->ctrl_base)
+ regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+- 0, MEM_CS_MASK);
++ MEM_CS_MASK, 0);
+ qspi->mmap_enabled = false;
+ }
+
--- /dev/null
+From a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 23 Jan 2019 15:19:17 +0100
+Subject: splice: don't merge into linked buffers
+
+From: Jann Horn <jannh@google.com>
+
+commit a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 upstream.
+
+Before this patch, it was possible for two pipes to affect each other after
+data had been transferred between them with tee():
+
+============
+$ cat tee_test.c
+
+int main(void) {
+ int pipe_a[2];
+ if (pipe(pipe_a)) err(1, "pipe");
+ int pipe_b[2];
+ if (pipe(pipe_b)) err(1, "pipe");
+ if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
+ if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
+ if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
+
+ char buf[5];
+ if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
+ buf[4] = 0;
+ printf("got back: '%s'\n", buf);
+}
+$ gcc -o tee_test tee_test.c
+$ ./tee_test
+got back: 'abxx'
+$
+============
+
+As suggested by Al Viro, fix it by creating a separate type for
+non-mergeable pipe buffers, then changing the types of buffers in
+splice_pipe_to_pipe() and link_pipe().
+
+Cc: <stable@vger.kernel.org>
+Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing")
+Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()")
+Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/pipe.c | 14 ++++++++++++++
+ fs/splice.c | 4 ++++
+ include/linux/pipe_fs_i.h | 1 +
+ 3 files changed, 19 insertions(+)
+
+--- a/fs/pipe.c
++++ b/fs/pipe.c
+@@ -234,6 +234,14 @@ static const struct pipe_buf_operations
+ .get = generic_pipe_buf_get,
+ };
+
++static const struct pipe_buf_operations anon_pipe_buf_nomerge_ops = {
++ .can_merge = 0,
++ .confirm = generic_pipe_buf_confirm,
++ .release = anon_pipe_buf_release,
++ .steal = anon_pipe_buf_steal,
++ .get = generic_pipe_buf_get,
++};
++
+ static const struct pipe_buf_operations packet_pipe_buf_ops = {
+ .can_merge = 0,
+ .confirm = generic_pipe_buf_confirm,
+@@ -242,6 +250,12 @@ static const struct pipe_buf_operations
+ .get = generic_pipe_buf_get,
+ };
+
++void pipe_buf_mark_unmergeable(struct pipe_buffer *buf)
++{
++ if (buf->ops == &anon_pipe_buf_ops)
++ buf->ops = &anon_pipe_buf_nomerge_ops;
++}
++
+ static ssize_t
+ pipe_read(struct kiocb *iocb, struct iov_iter *to)
+ {
+--- a/fs/splice.c
++++ b/fs/splice.c
+@@ -1597,6 +1597,8 @@ retry:
+ */
+ obuf->flags &= ~PIPE_BUF_FLAG_GIFT;
+
++ pipe_buf_mark_unmergeable(obuf);
++
+ obuf->len = len;
+ opipe->nrbufs++;
+ ibuf->offset += obuf->len;
+@@ -1671,6 +1673,8 @@ static int link_pipe(struct pipe_inode_i
+ */
+ obuf->flags &= ~PIPE_BUF_FLAG_GIFT;
+
++ pipe_buf_mark_unmergeable(obuf);
++
+ if (obuf->len > len)
+ obuf->len = len;
+
+--- a/include/linux/pipe_fs_i.h
++++ b/include/linux/pipe_fs_i.h
+@@ -182,6 +182,7 @@ void generic_pipe_buf_get(struct pipe_in
+ int generic_pipe_buf_confirm(struct pipe_inode_info *, struct pipe_buffer *);
+ int generic_pipe_buf_steal(struct pipe_inode_info *, struct pipe_buffer *);
+ void generic_pipe_buf_release(struct pipe_inode_info *, struct pipe_buffer *);
++void pipe_buf_mark_unmergeable(struct pipe_buffer *buf);
+
+ extern const struct pipe_buf_operations nosteal_pipe_buf_ops;
+
--- /dev/null
+From fd1068e1860e44aaaa337b516df4518d1ce98da1 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Thu, 7 Feb 2019 12:59:17 +0100
+Subject: virtio-blk: Consider virtio_max_dma_size() for maximum segment size
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit fd1068e1860e44aaaa337b516df4518d1ce98da1 upstream.
+
+Segments can't be larger than the maximum DMA mapping size
+supported on the platform. Take that into account when
+setting the maximum segment size for a block device.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/virtio_blk.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/block/virtio_blk.c
++++ b/drivers/block/virtio_blk.c
+@@ -723,7 +723,7 @@ static int virtblk_probe(struct virtio_d
+ struct request_queue *q;
+ int err, index;
+
+- u32 v, blk_size, sg_elems, opt_io_size;
++ u32 v, blk_size, max_size, sg_elems, opt_io_size;
+ u16 min_io_size;
+ u8 physical_block_exp, alignment_offset;
+
+@@ -826,14 +826,16 @@ static int virtblk_probe(struct virtio_d
+ /* No real sector limit. */
+ blk_queue_max_hw_sectors(q, -1U);
+
++ max_size = virtio_max_dma_size(vdev);
++
+ /* Host can optionally specify maximum segment size and number of
+ * segments. */
+ err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX,
+ struct virtio_blk_config, size_max, &v);
+ if (!err)
+- blk_queue_max_segment_size(q, v);
+- else
+- blk_queue_max_segment_size(q, -1U);
++ max_size = min(max_size, v);
++
++ blk_queue_max_segment_size(q, max_size);
+
+ /* Host can optionally specify the block size of the device */
+ err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
--- /dev/null
+From e6d6dd6c875eb3c9b69bb640419405726e6e0bbe Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Thu, 7 Feb 2019 12:59:16 +0100
+Subject: virtio: Introduce virtio_max_dma_size()
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit e6d6dd6c875eb3c9b69bb640419405726e6e0bbe upstream.
+
+This function returns the maximum segment size for a single
+dma transaction of a virtio device. The possible limit comes
+from the SWIOTLB implementation in the Linux kernel, that
+has an upper limit of (currently) 256kb of contiguous
+memory it can map. Other DMA-API implementations might also
+have limits.
+
+Use the new dma_max_mapping_size() function to determine the
+maximum mapping size when DMA-API is in use for virtio.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/virtio/virtio_ring.c | 11 +++++++++++
+ include/linux/virtio.h | 2 ++
+ 2 files changed, 13 insertions(+)
+
+--- a/drivers/virtio/virtio_ring.c
++++ b/drivers/virtio/virtio_ring.c
+@@ -271,6 +271,17 @@ static bool vring_use_dma_api(struct vir
+ return false;
+ }
+
++size_t virtio_max_dma_size(struct virtio_device *vdev)
++{
++ size_t max_segment_size = SIZE_MAX;
++
++ if (vring_use_dma_api(vdev))
++ max_segment_size = dma_max_mapping_size(&vdev->dev);
++
++ return max_segment_size;
++}
++EXPORT_SYMBOL_GPL(virtio_max_dma_size);
++
+ static void *vring_alloc_queue(struct virtio_device *vdev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+ {
+--- a/include/linux/virtio.h
++++ b/include/linux/virtio.h
+@@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_d
+ int virtio_device_restore(struct virtio_device *dev);
+ #endif
+
++size_t virtio_max_dma_size(struct virtio_device *vdev);
++
+ #define virtio_device_for_each_vq(vdev, vq) \
+ list_for_each_entry(vq, &vdev->vqs, list)
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
