--- /dev/null
+From 307f4065b9d7c1e887e8bdfb2487e4638559fea1 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Tue, 15 Oct 2019 08:49:27 -0700
+Subject: blk-rq-qos: fix first node deletion of rq_qos_del()
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 307f4065b9d7c1e887e8bdfb2487e4638559fea1 upstream.
+
+rq_qos_del() incorrectly assigns the node being deleted to the head if
+it was the first on the list in the !prev path. Fix it by iterating
+with ** instead.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Cc: Josef Bacik <josef@toxicpanda.com>
+Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt")
+Cc: stable@vger.kernel.org # v4.19+
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-rq-qos.h | 13 +++++--------
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+--- a/block/blk-rq-qos.h
++++ b/block/blk-rq-qos.h
+@@ -103,16 +103,13 @@ static inline void rq_qos_add(struct req
+
+ static inline void rq_qos_del(struct request_queue *q, struct rq_qos *rqos)
+ {
+- struct rq_qos *cur, *prev = NULL;
+- for (cur = q->rq_qos; cur; cur = cur->next) {
+- if (cur == rqos) {
+- if (prev)
+- prev->next = rqos->next;
+- else
+- q->rq_qos = cur;
++ struct rq_qos **cur;
++
++ for (cur = &q->rq_qos; *cur; cur = &(*cur)->next) {
++ if (*cur == rqos) {
++ *cur = rqos->next;
+ break;
+ }
+- prev = cur;
+ }
+
+ blk_mq_debugfs_unregister_rqos(rqos);
--- /dev/null
+From 44db1216efe37bf670f8d1019cdc41658d84baf5 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 9 Oct 2019 17:43:45 +0100
+Subject: Btrfs: add missing extents release on file extent cluster relocation error
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 44db1216efe37bf670f8d1019cdc41658d84baf5 upstream.
+
+If we error out when finding a page at relocate_file_extent_cluster(), we
+need to release the outstanding extents counter on the relocation inode,
+set by the previous call to btrfs_delalloc_reserve_metadata(), otherwise
+the inode's block reserve size can never decrease to zero and metadata
+space is leaked. Therefore add a call to btrfs_delalloc_release_extents()
+in case we can't find the target page.
+
+Fixes: 8b62f87bad9c ("Btrfs: rework outstanding_extents")
+CC: stable@vger.kernel.org # 4.19+
+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/relocation.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -3276,6 +3276,8 @@ static int relocate_file_extent_cluster(
+ if (!page) {
+ btrfs_delalloc_release_metadata(BTRFS_I(inode),
+ PAGE_SIZE, true);
++ btrfs_delalloc_release_extents(BTRFS_I(inode),
++ PAGE_SIZE, true);
+ ret = -ENOMEM;
+ goto out;
+ }
--- /dev/null
+From 4b654acdae850f48b8250b9a578a4eaa518c7a6f Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Thu, 10 Oct 2019 10:39:26 +0800
+Subject: btrfs: block-group: Fix a memory leak due to missing btrfs_put_block_group()
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 4b654acdae850f48b8250b9a578a4eaa518c7a6f upstream.
+
+In btrfs_read_block_groups(), if we have an invalid block group which
+has mixed type (DATA|METADATA) while the fs doesn't have MIXED_GROUPS
+feature, we error out without freeing the block group cache.
+
+This patch will add the missing btrfs_put_block_group() to prevent
+memory leak.
+
+Note for stable backports: the file to patch in versions <= 5.3 is
+fs/btrfs/extent-tree.c
+
+Fixes: 49303381f19a ("Btrfs: bail out if block group has different mixed flag")
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Signed-off-by: Qu Wenruo <wqu@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/extent-tree.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/btrfs/extent-tree.c
++++ b/fs/btrfs/extent-tree.c
+@@ -8117,6 +8117,7 @@ int btrfs_read_block_groups(struct btrfs
+ btrfs_err(info,
+ "bg %llu is a mixed block group but filesystem hasn't enabled mixed block groups",
+ cache->key.objectid);
++ btrfs_put_block_group(cache);
+ ret = -EINVAL;
+ goto error;
+ }
--- /dev/null
+From ba0b084ac309283db6e329785c1dc4f45fdbd379 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 16 Oct 2019 16:28:52 +0100
+Subject: Btrfs: check for the full sync flag while holding the inode lock during fsync
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit ba0b084ac309283db6e329785c1dc4f45fdbd379 upstream.
+
+We were checking for the full fsync flag in the inode before locking the
+inode, which is racy, since at that that time it might not be set but
+after we acquire the inode lock some other task set it. One case where
+this can happen is on a system low on memory and some concurrent task
+failed to allocate an extent map and therefore set the full sync flag on
+the inode, to force the next fsync to work in full mode.
+
+A consequence of missing the full fsync flag set is hitting the problems
+fixed by commit 0c713cbab620 ("Btrfs: fix race between ranged fsync and
+writeback of adjacent ranges"), BUG_ON() when dropping extents from a log
+tree, hitting assertion failures at tree-log.c:copy_items() or all sorts
+of weird inconsistencies after replaying a log due to file extents items
+representing ranges that overlap.
+
+So just move the check such that it's done after locking the inode and
+before starting writeback again.
+
+Fixes: 0c713cbab620 ("Btrfs: fix race between ranged fsync and writeback of adjacent ranges")
+CC: stable@vger.kernel.org # 5.2+
+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/file.c | 36 +++++++++++++++++-------------------
+ 1 file changed, 17 insertions(+), 19 deletions(-)
+
+--- a/fs/btrfs/file.c
++++ b/fs/btrfs/file.c
+@@ -2067,25 +2067,7 @@ int btrfs_sync_file(struct file *file, l
+ struct btrfs_trans_handle *trans;
+ struct btrfs_log_ctx ctx;
+ int ret = 0, err;
+- u64 len;
+
+- /*
+- * If the inode needs a full sync, make sure we use a full range to
+- * avoid log tree corruption, due to hole detection racing with ordered
+- * extent completion for adjacent ranges, and assertion failures during
+- * hole detection.
+- */
+- if (test_bit(BTRFS_INODE_NEEDS_FULL_SYNC,
+- &BTRFS_I(inode)->runtime_flags)) {
+- start = 0;
+- end = LLONG_MAX;
+- }
+-
+- /*
+- * The range length can be represented by u64, we have to do the typecasts
+- * to avoid signed overflow if it's [0, LLONG_MAX] eg. from fsync()
+- */
+- len = (u64)end - (u64)start + 1;
+ trace_btrfs_sync_file(file, datasync);
+
+ btrfs_init_log_ctx(&ctx, inode);
+@@ -2112,6 +2094,19 @@ int btrfs_sync_file(struct file *file, l
+ atomic_inc(&root->log_batch);
+
+ /*
++ * If the inode needs a full sync, make sure we use a full range to
++ * avoid log tree corruption, due to hole detection racing with ordered
++ * extent completion for adjacent ranges, and assertion failures during
++ * hole detection. Do this while holding the inode lock, to avoid races
++ * with other tasks.
++ */
++ if (test_bit(BTRFS_INODE_NEEDS_FULL_SYNC,
++ &BTRFS_I(inode)->runtime_flags)) {
++ start = 0;
++ end = LLONG_MAX;
++ }
++
++ /*
+ * Before we acquired the inode's lock, someone may have dirtied more
+ * pages in the target range. We need to make sure that writeback for
+ * any such pages does not start while we are logging the inode, because
+@@ -2138,8 +2133,11 @@ int btrfs_sync_file(struct file *file, l
+ /*
+ * We have to do this here to avoid the priority inversion of waiting on
+ * IO of a lower priority task while holding a transaction open.
++ *
++ * Also, the range length can be represented by u64, we have to do the
++ * typecasts to avoid signed overflow if it's [0, LLONG_MAX].
+ */
+- ret = btrfs_wait_ordered_range(inode, start, len);
++ ret = btrfs_wait_ordered_range(inode, start, (u64)end - (u64)start + 1);
+ if (ret) {
+ up_write(&BTRFS_I(inode)->dio_sem);
+ inode_unlock(inode);
--- /dev/null
+From 80ed4548d0711d15ca51be5dee0ff813051cfc90 Mon Sep 17 00:00:00 2001
+From: David Sterba <dsterba@suse.com>
+Date: Sat, 12 Oct 2019 18:42:10 +0200
+Subject: btrfs: don't needlessly create extent-refs kernel thread
+
+From: David Sterba <dsterba@suse.com>
+
+commit 80ed4548d0711d15ca51be5dee0ff813051cfc90 upstream.
+
+The patch 32b593bfcb58 ("Btrfs: remove no longer used function to run
+delayed refs asynchronously") removed the async delayed refs but the
+thread has been created, without any use. Remove it to avoid resource
+consumption.
+
+Fixes: 32b593bfcb58 ("Btrfs: remove no longer used function to run delayed refs asynchronously")
+CC: stable@vger.kernel.org # 5.2+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/ctree.h | 2 --
+ fs/btrfs/disk-io.c | 6 ------
+ 2 files changed, 8 deletions(-)
+
+--- a/fs/btrfs/ctree.h
++++ b/fs/btrfs/ctree.h
+@@ -908,8 +908,6 @@ struct btrfs_fs_info {
+ struct btrfs_workqueue *fixup_workers;
+ struct btrfs_workqueue *delayed_workers;
+
+- /* the extent workers do delayed refs on the extent allocation tree */
+- struct btrfs_workqueue *extent_workers;
+ struct task_struct *transaction_kthread;
+ struct task_struct *cleaner_kthread;
+ u32 thread_pool_size;
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -2036,7 +2036,6 @@ static void btrfs_stop_all_workers(struc
+ btrfs_destroy_workqueue(fs_info->readahead_workers);
+ btrfs_destroy_workqueue(fs_info->flush_workers);
+ btrfs_destroy_workqueue(fs_info->qgroup_rescan_workers);
+- btrfs_destroy_workqueue(fs_info->extent_workers);
+ /*
+ * Now that all other work queues are destroyed, we can safely destroy
+ * the queues used for metadata I/O, since tasks from those other work
+@@ -2242,10 +2241,6 @@ static int btrfs_init_workqueues(struct
+ max_active, 2);
+ fs_info->qgroup_rescan_workers =
+ btrfs_alloc_workqueue(fs_info, "qgroup-rescan", flags, 1, 0);
+- fs_info->extent_workers =
+- btrfs_alloc_workqueue(fs_info, "extent-refs", flags,
+- min_t(u64, fs_devices->num_devices,
+- max_active), 8);
+
+ if (!(fs_info->workers && fs_info->delalloc_workers &&
+ fs_info->submit_workers && fs_info->flush_workers &&
+@@ -2256,7 +2251,6 @@ static int btrfs_init_workqueues(struct
+ fs_info->endio_freespace_worker && fs_info->rmw_workers &&
+ fs_info->caching_workers && fs_info->readahead_workers &&
+ fs_info->fixup_workers && fs_info->delayed_workers &&
+- fs_info->extent_workers &&
+ fs_info->qgroup_rescan_workers)) {
+ return -ENOMEM;
+ }
--- /dev/null
+From c7967fc1499beb9b70bb9d33525fb0b384af8883 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Tue, 15 Oct 2019 10:54:39 +0100
+Subject: Btrfs: fix qgroup double free after failure to reserve metadata for delalloc
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit c7967fc1499beb9b70bb9d33525fb0b384af8883 upstream.
+
+If we fail to reserve metadata for delalloc operations we end up releasing
+the previously reserved qgroup amount twice, once explicitly under the
+'out_qgroup' label by calling btrfs_qgroup_free_meta_prealloc() and once
+again, under label 'out_fail', by calling btrfs_inode_rsv_release() with a
+value of 'true' for its 'qgroup_free' argument, which results in
+btrfs_qgroup_free_meta_prealloc() being called again, so we end up having
+a double free.
+
+Also if we fail to reserve the necessary qgroup amount, we jump to the
+label 'out_fail', which calls btrfs_inode_rsv_release() and that in turns
+calls btrfs_qgroup_free_meta_prealloc(), even though we weren't able to
+reserve any qgroup amount. So we freed some amount we never reserved.
+
+So fix this by removing the call to btrfs_inode_rsv_release() in the
+failure path, since it's not necessary at all as we haven't changed the
+inode's block reserve in any way at this point.
+
+Fixes: c8eaeac7b73434 ("btrfs: reserve delalloc metadata differently")
+CC: stable@vger.kernel.org # 5.2+
+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/delalloc-space.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/fs/btrfs/delalloc-space.c
++++ b/fs/btrfs/delalloc-space.c
+@@ -371,7 +371,6 @@ int btrfs_delalloc_reserve_metadata(stru
+ out_qgroup:
+ btrfs_qgroup_free_meta_prealloc(root, qgroup_reserve);
+ out_fail:
+- btrfs_inode_rsv_release(inode, true);
+ if (delalloc_lock)
+ mutex_unlock(&inode->delalloc_mutex);
+ return ret;
--- /dev/null
+From 1b2442b4ae0f234daeadd90e153b466332c466d8 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Thu, 17 Oct 2019 10:38:37 +0800
+Subject: btrfs: tracepoints: Fix bad entry members of qgroup events
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 1b2442b4ae0f234daeadd90e153b466332c466d8 upstream.
+
+[BUG]
+For btrfs:qgroup_meta_reserve event, the trace event can output garbage:
+
+ qgroup_meta_reserve: 9c7f6acc-b342-4037-bc47-7f6e4d2232d7: refroot=5(FS_TREE) type=DATA diff=2
+ qgroup_meta_reserve: 9c7f6acc-b342-4037-bc47-7f6e4d2232d7: refroot=5(FS_TREE) type=0x258792 diff=2
+
+The @type can be completely garbage, as DATA type is not possible for
+trace_qgroup_meta_reserve() trace event.
+
+[CAUSE]
+Ther are several problems related to qgroup trace events:
+- Unassigned entry member
+ Member entry::type of trace_qgroup_update_reserve() and
+ trace_qgourp_meta_reserve() is not assigned
+
+- Redundant entry member
+ Member entry::type is completely useless in
+ trace_qgroup_meta_convert()
+
+Fixes: 4ee0d8832c2e ("btrfs: qgroup: Update trace events for metadata reservation")
+CC: stable@vger.kernel.org # 4.10+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Qu Wenruo <wqu@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>
+
+---
+ include/trace/events/btrfs.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/trace/events/btrfs.h
++++ b/include/trace/events/btrfs.h
+@@ -1687,6 +1687,7 @@ TRACE_EVENT(qgroup_update_reserve,
+ __entry->qgid = qgroup->qgroupid;
+ __entry->cur_reserved = qgroup->rsv.values[type];
+ __entry->diff = diff;
++ __entry->type = type;
+ ),
+
+ TP_printk_btrfs("qgid=%llu type=%s cur_reserved=%llu diff=%lld",
+@@ -1709,6 +1710,7 @@ TRACE_EVENT(qgroup_meta_reserve,
+ TP_fast_assign_btrfs(root->fs_info,
+ __entry->refroot = root->root_key.objectid;
+ __entry->diff = diff;
++ __entry->type = type;
+ ),
+
+ TP_printk_btrfs("refroot=%llu(%s) type=%s diff=%lld",
+@@ -1725,7 +1727,6 @@ TRACE_EVENT(qgroup_meta_convert,
+ TP_STRUCT__entry_btrfs(
+ __field( u64, refroot )
+ __field( s64, diff )
+- __field( int, type )
+ ),
+
+ TP_fast_assign_btrfs(root->fs_info,
--- /dev/null
+From fd2b007eaec898564e269d1f478a2da0380ecf51 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Thu, 17 Oct 2019 10:38:36 +0800
+Subject: btrfs: tracepoints: Fix wrong parameter order for qgroup events
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit fd2b007eaec898564e269d1f478a2da0380ecf51 upstream.
+
+[BUG]
+For btrfs:qgroup_meta_reserve event, the trace event can output garbage:
+
+ qgroup_meta_reserve: 9c7f6acc-b342-4037-bc47-7f6e4d2232d7: refroot=5(FS_TREE) type=DATA diff=2
+
+The diff should always be alinged to sector size (4k), so there is
+definitely something wrong.
+
+[CAUSE]
+For the wrong @diff, it's caused by wrong parameter order.
+The correct parameters are:
+
+ struct btrfs_root, s64 diff, int type.
+
+However the parameters used are:
+
+ struct btrfs_root, int type, s64 diff.
+
+Fixes: 4ee0d8832c2e ("btrfs: qgroup: Update trace events for metadata reservation")
+CC: stable@vger.kernel.org # 4.19+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Qu Wenruo <wqu@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/qgroup.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/qgroup.c
++++ b/fs/btrfs/qgroup.c
+@@ -3617,7 +3617,7 @@ int __btrfs_qgroup_reserve_meta(struct b
+ return 0;
+
+ BUG_ON(num_bytes != round_down(num_bytes, fs_info->nodesize));
+- trace_qgroup_meta_reserve(root, type, (s64)num_bytes);
++ trace_qgroup_meta_reserve(root, (s64)num_bytes, type);
+ ret = qgroup_reserve(root, num_bytes, enforce, type);
+ if (ret < 0)
+ return ret;
+@@ -3664,7 +3664,7 @@ void __btrfs_qgroup_free_meta(struct btr
+ */
+ num_bytes = sub_root_meta_rsv(root, num_bytes, type);
+ BUG_ON(num_bytes != round_down(num_bytes, fs_info->nodesize));
+- trace_qgroup_meta_reserve(root, type, -(s64)num_bytes);
++ trace_qgroup_meta_reserve(root, -(s64)num_bytes, type);
+ btrfs_qgroup_free_refroot(fs_info, root->root_key.objectid,
+ num_bytes, type);
+ }
--- /dev/null
+From 1d3f87233e26362fc3d4e59f0f31a71b570f90b9 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@kernel.org>
+Date: Thu, 26 Sep 2019 16:05:11 -0400
+Subject: ceph: just skip unrecognized info in ceph_reply_info_extra
+
+From: Jeff Layton <jlayton@kernel.org>
+
+commit 1d3f87233e26362fc3d4e59f0f31a71b570f90b9 upstream.
+
+In the future, we're going to want to extend the ceph_reply_info_extra
+for create replies. Currently though, the kernel code doesn't accept an
+extra blob that is larger than the expected data.
+
+Change the code to skip over any unrecognized fields at the end of the
+extra blob, rather than returning -EIO.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ceph/mds_client.c | 21 +++++++++++----------
+ 1 file changed, 11 insertions(+), 10 deletions(-)
+
+--- a/fs/ceph/mds_client.c
++++ b/fs/ceph/mds_client.c
+@@ -384,8 +384,8 @@ static int parse_reply_info_readdir(void
+ }
+
+ done:
+- if (*p != end)
+- goto bad;
++ /* Skip over any unrecognized fields */
++ *p = end;
+ return 0;
+
+ bad:
+@@ -406,12 +406,10 @@ static int parse_reply_info_filelock(voi
+ goto bad;
+
+ info->filelock_reply = *p;
+- *p += sizeof(*info->filelock_reply);
+
+- if (unlikely(*p != end))
+- goto bad;
++ /* Skip over any unrecognized fields */
++ *p = end;
+ return 0;
+-
+ bad:
+ return -EIO;
+ }
+@@ -425,18 +423,21 @@ static int parse_reply_info_create(void
+ {
+ if (features == (u64)-1 ||
+ (features & CEPH_FEATURE_REPLY_CREATE_INODE)) {
++ /* Malformed reply? */
+ if (*p == end) {
+ info->has_create_ino = false;
+ } else {
+ info->has_create_ino = true;
+- info->ino = ceph_decode_64(p);
++ ceph_decode_64_safe(p, end, info->ino, bad);
+ }
++ } else {
++ if (*p != end)
++ goto bad;
+ }
+
+- if (unlikely(*p != end))
+- goto bad;
++ /* Skip over any unrecognized fields */
++ *p = end;
+ return 0;
+-
+ bad:
+ return -EIO;
+ }
--- /dev/null
+From 03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb Mon Sep 17 00:00:00 2001
+From: Roberto Bergantinos Corpas <rbergant@redhat.com>
+Date: Mon, 14 Oct 2019 10:59:23 +0200
+Subject: CIFS: avoid using MID 0xFFFF
+
+From: Roberto Bergantinos Corpas <rbergant@redhat.com>
+
+commit 03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb upstream.
+
+According to MS-CIFS specification MID 0xFFFF should not be used by the
+CIFS client, but we actually do. Besides, this has proven to cause races
+leading to oops between SendReceive2/cifs_demultiplex_thread. On SMB1,
+MID is a 2 byte value easy to reach in CurrentMid which may conflict with
+an oplock break notification request coming from server
+
+Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb1ops.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/cifs/smb1ops.c
++++ b/fs/cifs/smb1ops.c
+@@ -171,6 +171,9 @@ cifs_get_next_mid(struct TCP_Server_Info
+ /* we do not want to loop forever */
+ last_mid = cur_mid;
+ cur_mid++;
++ /* avoid 0xFFFF MID */
++ if (cur_mid == 0xffff)
++ cur_mid++;
+
+ /*
+ * This nested loop looks more expensive than it is.
--- /dev/null
+From 783bf7b8b641167fb6f3f4f787f60ae62bad41b3 Mon Sep 17 00:00:00 2001
+From: Chuhong Yuan <hslester96@gmail.com>
+Date: Mon, 14 Oct 2019 15:15:31 +0800
+Subject: cifs: Fix missed free operations
+
+From: Chuhong Yuan <hslester96@gmail.com>
+
+commit 783bf7b8b641167fb6f3f4f787f60ae62bad41b3 upstream.
+
+cifs_setattr_nounix has two paths which miss free operations
+for xid and fullpath.
+Use goto cifs_setattr_exit like other paths to fix them.
+
+CC: Stable <stable@vger.kernel.org>
+Fixes: aa081859b10c ("cifs: flush before set-info if we have writeable handles")
+Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/inode.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/cifs/inode.c
++++ b/fs/cifs/inode.c
+@@ -2465,9 +2465,9 @@ cifs_setattr_nounix(struct dentry *diren
+ rc = tcon->ses->server->ops->flush(xid, tcon, &wfile->fid);
+ cifsFileInfo_put(wfile);
+ if (rc)
+- return rc;
++ goto cifs_setattr_exit;
+ } else if (rc != -EBADF)
+- return rc;
++ goto cifs_setattr_exit;
+ else
+ rc = 0;
+ }
--- /dev/null
+From 1a67c415965752879e2e9fad407bc44fc7f25f23 Mon Sep 17 00:00:00 2001
+From: Pavel Shilovsky <pshilov@microsoft.com>
+Date: Wed, 23 Oct 2019 15:37:19 -0700
+Subject: CIFS: Fix use after free of file info structures
+
+From: Pavel Shilovsky <pshilov@microsoft.com>
+
+commit 1a67c415965752879e2e9fad407bc44fc7f25f23 upstream.
+
+Currently the code assumes that if a file info entry belongs
+to lists of open file handles of an inode and a tcon then
+it has non-zero reference. The recent changes broke that
+assumption when putting the last reference of the file info.
+There may be a situation when a file is being deleted but
+nothing prevents another thread to reference it again
+and start using it. This happens because we do not hold
+the inode list lock while checking the number of references
+of the file info structure. Fix this by doing the proper
+locking when doing the check.
+
+Fixes: 487317c99477d ("cifs: add spinlock for the openFileList to cifsInodeInfo")
+Fixes: cb248819d209d ("cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic")
+Cc: Stable <stable@vger.kernel.org>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/file.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/fs/cifs/file.c
++++ b/fs/cifs/file.c
+@@ -405,10 +405,11 @@ void _cifsFileInfo_put(struct cifsFileIn
+ bool oplock_break_cancelled;
+
+ spin_lock(&tcon->open_file_lock);
+-
++ spin_lock(&cifsi->open_file_lock);
+ spin_lock(&cifs_file->file_info_lock);
+ if (--cifs_file->count > 0) {
+ spin_unlock(&cifs_file->file_info_lock);
++ spin_unlock(&cifsi->open_file_lock);
+ spin_unlock(&tcon->open_file_lock);
+ return;
+ }
+@@ -421,9 +422,7 @@ void _cifsFileInfo_put(struct cifsFileIn
+ cifs_add_pending_open_locked(&fid, cifs_file->tlink, &open);
+
+ /* remove it from the lists */
+- spin_lock(&cifsi->open_file_lock);
+ list_del(&cifs_file->flist);
+- spin_unlock(&cifsi->open_file_lock);
+ list_del(&cifs_file->tlist);
+ atomic_dec(&tcon->num_local_opens);
+
+@@ -440,6 +439,7 @@ void _cifsFileInfo_put(struct cifsFileIn
+ cifs_set_oplock_level(cifsi, 0);
+ }
+
++ spin_unlock(&cifsi->open_file_lock);
+ spin_unlock(&tcon->open_file_lock);
+
+ oplock_break_cancelled = wait_oplock_handler ?
--- /dev/null
+From 65650b35133ff20f0c9ef0abd5c3c66dbce3ae57 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Wed, 9 Oct 2019 01:29:10 +0200
+Subject: cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 65650b35133ff20f0c9ef0abd5c3c66dbce3ae57 upstream.
+
+It is incorrect to set the cpufreq syscore shutdown callback pointer
+to cpufreq_suspend(), because that function cannot be run in the
+syscore stage of system shutdown for two reasons: (a) it may attempt
+to carry out actions depending on devices that have already been shut
+down at that point and (b) the RCU synchronization carried out by it
+may not be able to make progress then.
+
+The latter issue has been present since commit 45975c7d21a1 ("rcu:
+Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"),
+but the former one has been there since commit 90de2a4aa9f3 ("cpufreq:
+suspend cpufreq governors on shutdown") regardless.
+
+Fix that by dropping cpufreq_syscore_ops altogether and making
+device_shutdown() call cpufreq_suspend() directly before shutting
+down devices, which is along the lines of what system-wide power
+management does.
+
+Fixes: 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds")
+Fixes: 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown")
+Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/core.c | 3 +++
+ drivers/cpufreq/cpufreq.c | 10 ----------
+ 2 files changed, 3 insertions(+), 10 deletions(-)
+
+--- a/drivers/base/core.c
++++ b/drivers/base/core.c
+@@ -9,6 +9,7 @@
+ */
+
+ #include <linux/acpi.h>
++#include <linux/cpufreq.h>
+ #include <linux/device.h>
+ #include <linux/err.h>
+ #include <linux/fwnode.h>
+@@ -3150,6 +3151,8 @@ void device_shutdown(void)
+ wait_for_device_probe();
+ device_block_probing();
+
++ cpufreq_suspend();
++
+ spin_lock(&devices_kset->list_lock);
+ /*
+ * Walk the devices list backward, shutting down each in turn.
+--- a/drivers/cpufreq/cpufreq.c
++++ b/drivers/cpufreq/cpufreq.c
+@@ -2746,14 +2746,6 @@ int cpufreq_unregister_driver(struct cpu
+ }
+ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
+
+-/*
+- * Stop cpufreq at shutdown to make sure it isn't holding any locks
+- * or mutexes when secondary CPUs are halted.
+- */
+-static struct syscore_ops cpufreq_syscore_ops = {
+- .shutdown = cpufreq_suspend,
+-};
+-
+ struct kobject *cpufreq_global_kobject;
+ EXPORT_SYMBOL(cpufreq_global_kobject);
+
+@@ -2765,8 +2757,6 @@ static int __init cpufreq_core_init(void
+ cpufreq_global_kobject = kobject_create_and_add("cpufreq", &cpu_subsys.dev_root->kobj);
+ BUG_ON(!cpufreq_global_kobject);
+
+- register_syscore_ops(&cpufreq_syscore_ops);
+-
+ return 0;
+ }
+ module_param(off, int, 0444);
--- /dev/null
+From 13bd677a472d534bf100bab2713efc3f9e3f5978 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 16 Oct 2019 09:21:50 -0400
+Subject: dm cache: fix bugs when a GFP_NOWAIT allocation fails
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 13bd677a472d534bf100bab2713efc3f9e3f5978 upstream.
+
+GFP_NOWAIT allocation can fail anytime - it doesn't wait for memory being
+available and it fails if the mempool is exhausted and there is not enough
+memory.
+
+If we go down this path:
+ map_bio -> mg_start -> alloc_migration -> mempool_alloc(GFP_NOWAIT)
+we can see that map_bio() doesn't check the return value of mg_start(),
+and the bio is leaked.
+
+If we go down this path:
+ map_bio -> mg_start -> mg_lock_writes -> alloc_prison_cell ->
+ dm_bio_prison_alloc_cell_v2 -> mempool_alloc(GFP_NOWAIT) ->
+ mg_lock_writes -> mg_complete
+the bio is ended with an error - it is unacceptable because it could
+cause filesystem corruption if the machine ran out of memory
+temporarily.
+
+Change GFP_NOWAIT to GFP_NOIO, so that the mempool code will properly
+wait until memory becomes available. mempool_alloc with GFP_NOIO can't
+fail, so remove the code paths that deal with allocation failure.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-cache-target.c | 28 ++--------------------------
+ 1 file changed, 2 insertions(+), 26 deletions(-)
+
+--- a/drivers/md/dm-cache-target.c
++++ b/drivers/md/dm-cache-target.c
+@@ -542,7 +542,7 @@ static void wake_migration_worker(struct
+
+ static struct dm_bio_prison_cell_v2 *alloc_prison_cell(struct cache *cache)
+ {
+- return dm_bio_prison_alloc_cell_v2(cache->prison, GFP_NOWAIT);
++ return dm_bio_prison_alloc_cell_v2(cache->prison, GFP_NOIO);
+ }
+
+ static void free_prison_cell(struct cache *cache, struct dm_bio_prison_cell_v2 *cell)
+@@ -554,9 +554,7 @@ static struct dm_cache_migration *alloc_
+ {
+ struct dm_cache_migration *mg;
+
+- mg = mempool_alloc(&cache->migration_pool, GFP_NOWAIT);
+- if (!mg)
+- return NULL;
++ mg = mempool_alloc(&cache->migration_pool, GFP_NOIO);
+
+ memset(mg, 0, sizeof(*mg));
+
+@@ -664,10 +662,6 @@ static bool bio_detain_shared(struct cac
+ struct dm_bio_prison_cell_v2 *cell_prealloc, *cell;
+
+ cell_prealloc = alloc_prison_cell(cache); /* FIXME: allow wait if calling from worker */
+- if (!cell_prealloc) {
+- defer_bio(cache, bio);
+- return false;
+- }
+
+ build_key(oblock, end, &key);
+ r = dm_cell_get_v2(cache->prison, &key, lock_level(bio), bio, cell_prealloc, &cell);
+@@ -1493,11 +1487,6 @@ static int mg_lock_writes(struct dm_cach
+ struct dm_bio_prison_cell_v2 *prealloc;
+
+ prealloc = alloc_prison_cell(cache);
+- if (!prealloc) {
+- DMERR_LIMIT("%s: alloc_prison_cell failed", cache_device_name(cache));
+- mg_complete(mg, false);
+- return -ENOMEM;
+- }
+
+ /*
+ * Prevent writes to the block, but allow reads to continue.
+@@ -1535,11 +1524,6 @@ static int mg_start(struct cache *cache,
+ }
+
+ mg = alloc_migration(cache);
+- if (!mg) {
+- policy_complete_background_work(cache->policy, op, false);
+- background_work_end(cache);
+- return -ENOMEM;
+- }
+
+ mg->op = op;
+ mg->overwrite_bio = bio;
+@@ -1628,10 +1612,6 @@ static int invalidate_lock(struct dm_cac
+ struct dm_bio_prison_cell_v2 *prealloc;
+
+ prealloc = alloc_prison_cell(cache);
+- if (!prealloc) {
+- invalidate_complete(mg, false);
+- return -ENOMEM;
+- }
+
+ build_key(mg->invalidate_oblock, oblock_succ(mg->invalidate_oblock), &key);
+ r = dm_cell_lock_v2(cache->prison, &key,
+@@ -1669,10 +1649,6 @@ static int invalidate_start(struct cache
+ return -EPERM;
+
+ mg = alloc_migration(cache);
+- if (!mg) {
+- background_work_end(cache);
+- return -ENOMEM;
+- }
+
+ mg->overwrite_bio = bio;
+ mg->invalidate_cblock = cblock;
--- /dev/null
+From 6370740e5f8ef12de7f9a9bf48a0393d202cd827 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Mon, 21 Oct 2019 09:29:20 -0700
+Subject: fs/dax: Fix pmd vs pte conflict detection
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit 6370740e5f8ef12de7f9a9bf48a0393d202cd827 upstream.
+
+Users reported a v5.3 performance regression and inability to establish
+huge page mappings. A revised version of the ndctl "dax.sh" huge page
+unit test identifies commit 23c84eb78375 "dax: Fix missed wakeup with
+PMD faults" as the source.
+
+Update get_unlocked_entry() to check for NULL entries before checking
+the entry order, otherwise NULL is misinterpreted as a present pte
+conflict. The 'order' check needs to happen before the locked check as
+an unlocked entry at the wrong order must fallback to lookup the correct
+order.
+
+Reported-by: Jeff Smits <jeff.smits@intel.com>
+Reported-by: Doug Nelson <doug.nelson@intel.com>
+Cc: <stable@vger.kernel.org>
+Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults")
+Reviewed-by: Jan Kara <jack@suse.cz>
+Cc: Jeff Moyer <jmoyer@redhat.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Link: https://lore.kernel.org/r/157167532455.3945484.11971474077040503994.stgit@dwillia2-desk3.amr.corp.intel.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/dax.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/fs/dax.c
++++ b/fs/dax.c
+@@ -220,10 +220,11 @@ static void *get_unlocked_entry(struct x
+
+ for (;;) {
+ entry = xas_find_conflict(xas);
++ if (!entry || WARN_ON_ONCE(!xa_is_value(entry)))
++ return entry;
+ if (dax_entry_order(entry) < order)
+ return XA_RETRY_ENTRY;
+- if (!entry || WARN_ON_ONCE(!xa_is_value(entry)) ||
+- !dax_is_locked(entry))
++ if (!dax_is_locked(entry))
+ return entry;
+
+ wq = dax_entry_waitqueue(xas, entry, &ewait.key);
--- /dev/null
+From bb0fed1c60cccbe4063b455a7228818395dac86e Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Sun, 15 Sep 2019 15:17:45 +0100
+Subject: irqchip/sifive-plic: Switch to fasteoi flow
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit bb0fed1c60cccbe4063b455a7228818395dac86e upstream.
+
+The SiFive PLIC interrupt controller seems to have all the HW
+features to support the fasteoi flow, but the driver seems to be
+stuck in a distant past. Bring it into the 21st century.
+
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Tested-by: Palmer Dabbelt <palmer@sifive.com> (QEMU Boot)
+Tested-by: Darius Rad <darius@bluespec.com> (on 2 HW PLIC implementations)
+Tested-by: Paul Walmsley <paul.walmsley@sifive.com> (HiFive Unleashed)
+Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/8636gxskmj.wl-maz@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-sifive-plic.c | 29 +++++++++++++++--------------
+ 1 file changed, 15 insertions(+), 14 deletions(-)
+
+--- a/drivers/irqchip/irq-sifive-plic.c
++++ b/drivers/irqchip/irq-sifive-plic.c
+@@ -97,7 +97,7 @@ static inline void plic_irq_toggle(const
+ }
+ }
+
+-static void plic_irq_enable(struct irq_data *d)
++static void plic_irq_unmask(struct irq_data *d)
+ {
+ unsigned int cpu = cpumask_any_and(irq_data_get_affinity_mask(d),
+ cpu_online_mask);
+@@ -106,7 +106,7 @@ static void plic_irq_enable(struct irq_d
+ plic_irq_toggle(cpumask_of(cpu), d->hwirq, 1);
+ }
+
+-static void plic_irq_disable(struct irq_data *d)
++static void plic_irq_mask(struct irq_data *d)
+ {
+ plic_irq_toggle(cpu_possible_mask, d->hwirq, 0);
+ }
+@@ -125,10 +125,8 @@ static int plic_set_affinity(struct irq_
+ if (cpu >= nr_cpu_ids)
+ return -EINVAL;
+
+- if (!irqd_irq_disabled(d)) {
+- plic_irq_toggle(cpu_possible_mask, d->hwirq, 0);
+- plic_irq_toggle(cpumask_of(cpu), d->hwirq, 1);
+- }
++ plic_irq_toggle(cpu_possible_mask, d->hwirq, 0);
++ plic_irq_toggle(cpumask_of(cpu), d->hwirq, 1);
+
+ irq_data_update_effective_affinity(d, cpumask_of(cpu));
+
+@@ -136,14 +134,18 @@ static int plic_set_affinity(struct irq_
+ }
+ #endif
+
++static void plic_irq_eoi(struct irq_data *d)
++{
++ struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
++
++ writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
++}
++
+ static struct irq_chip plic_chip = {
+ .name = "SiFive PLIC",
+- /*
+- * There is no need to mask/unmask PLIC interrupts. They are "masked"
+- * by reading claim and "unmasked" when writing it back.
+- */
+- .irq_enable = plic_irq_enable,
+- .irq_disable = plic_irq_disable,
++ .irq_mask = plic_irq_mask,
++ .irq_unmask = plic_irq_unmask,
++ .irq_eoi = plic_irq_eoi,
+ #ifdef CONFIG_SMP
+ .irq_set_affinity = plic_set_affinity,
+ #endif
+@@ -152,7 +154,7 @@ static struct irq_chip plic_chip = {
+ static int plic_irqdomain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+ {
+- irq_set_chip_and_handler(irq, &plic_chip, handle_simple_irq);
++ irq_set_chip_and_handler(irq, &plic_chip, handle_fasteoi_irq);
+ irq_set_chip_data(irq, NULL);
+ irq_set_noprobe(irq);
+ return 0;
+@@ -188,7 +190,6 @@ static void plic_handle_irq(struct pt_re
+ hwirq);
+ else
+ generic_handle_irq(irq);
+- writel(hwirq, claim);
+ }
+ csr_set(sie, SIE_SEIE);
+ }
--- /dev/null
+From 12ade69c1eb9958b13374edf5ef742ea20ccffde Mon Sep 17 00:00:00 2001
+From: Greg Kurz <groug@kaod.org>
+Date: Fri, 27 Sep 2019 13:53:43 +0200
+Subject: KVM: PPC: Book3S HV: XIVE: Ensure VP isn't already in use
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Greg Kurz <groug@kaod.org>
+
+commit 12ade69c1eb9958b13374edf5ef742ea20ccffde upstream.
+
+Connecting a vCPU to a XIVE KVM device means establishing a 1:1
+association between a vCPU id and the offset (VP id) of a VP
+structure within a fixed size block of VPs. We currently try to
+enforce the 1:1 relationship by checking that a vCPU with the
+same id isn't already connected. This is good but unfortunately
+not enough because we don't map VP ids to raw vCPU ids but to
+packed vCPU ids, and the packing function kvmppc_pack_vcpu_id()
+isn't bijective by design. We got away with it because QEMU passes
+vCPU ids that fit well in the packing pattern. But nothing prevents
+userspace to come up with a forged vCPU id resulting in a packed id
+collision which causes the KVM device to associate two vCPUs to the
+same VP. This greatly confuses the irq layer and ultimately crashes
+the kernel, as shown below.
+
+Example: a guest with 1 guest thread per core, a core stride of
+8 and 300 vCPUs has vCPU ids 0,8,16...2392. If QEMU is patched to
+inject at some point an invalid vCPU id 348, which is the packed
+version of itself and 2392, we get:
+
+genirq: Flags mismatch irq 199. 00010000 (kvm-2-2392) vs. 00010000 (kvm-2-348)
+CPU: 24 PID: 88176 Comm: qemu-system-ppc Not tainted 5.3.0-xive-nr-servers-5.3-gku+ #38
+Call Trace:
+[c000003f7f9937e0] [c000000000c0110c] dump_stack+0xb0/0xf4 (unreliable)
+[c000003f7f993820] [c0000000001cb480] __setup_irq+0xa70/0xad0
+[c000003f7f9938d0] [c0000000001cb75c] request_threaded_irq+0x13c/0x260
+[c000003f7f993940] [c00800000d44e7ac] kvmppc_xive_attach_escalation+0x104/0x270 [kvm]
+[c000003f7f9939d0] [c00800000d45013c] kvmppc_xive_connect_vcpu+0x424/0x620 [kvm]
+[c000003f7f993ac0] [c00800000d444428] kvm_arch_vcpu_ioctl+0x260/0x448 [kvm]
+[c000003f7f993b90] [c00800000d43593c] kvm_vcpu_ioctl+0x154/0x7c8 [kvm]
+[c000003f7f993d00] [c0000000004840f0] do_vfs_ioctl+0xe0/0xc30
+[c000003f7f993db0] [c000000000484d44] ksys_ioctl+0x104/0x120
+[c000003f7f993e00] [c000000000484d88] sys_ioctl+0x28/0x80
+[c000003f7f993e20] [c00000000000b278] system_call+0x5c/0x68
+xive-kvm: Failed to request escalation interrupt for queue 0 of VCPU 2392
+------------[ cut here ]------------
+remove_proc_entry: removing non-empty directory 'irq/199', leaking at least 'kvm-2-348'
+WARNING: CPU: 24 PID: 88176 at /home/greg/Work/linux/kernel-kvm-ppc/fs/proc/generic.c:684 remove_proc_entry+0x1ec/0x200
+Modules linked in: kvm_hv kvm dm_mod vhost_net vhost tap xt_CHECKSUM iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter squashfs loop fuse i2c_dev sg ofpart ocxl powernv_flash at24 xts mtd uio_pdrv_genirq vmx_crypto opal_prd ipmi_powernv uio ipmi_devintf ipmi_msghandler ibmpowernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables ext4 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq libcrc32c raid1 raid0 linear sd_mod ast i2c_algo_bit drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci libata tg3 drm_panel_orientation_quirks [last unloaded: kvm]
+CPU: 24 PID: 88176 Comm: qemu-system-ppc Not tainted 5.3.0-xive-nr-servers-5.3-gku+ #38
+NIP: c00000000053b0cc LR: c00000000053b0c8 CTR: c0000000000ba3b0
+REGS: c000003f7f9934b0 TRAP: 0700 Not tainted (5.3.0-xive-nr-servers-5.3-gku+)
+MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 48228222 XER: 20040000
+CFAR: c000000000131a50 IRQMASK: 0
+GPR00: c00000000053b0c8 c000003f7f993740 c0000000015ec500 0000000000000057
+GPR04: 0000000000000001 0000000000000000 000049fb98484262 0000000000001bcf
+GPR08: 0000000000000007 0000000000000007 0000000000000001 9000000000001033
+GPR12: 0000000000008000 c000003ffffeb800 0000000000000000 000000012f4ce5a1
+GPR16: 000000012ef5a0c8 0000000000000000 000000012f113bb0 0000000000000000
+GPR20: 000000012f45d918 c000003f863758b0 c000003f86375870 0000000000000006
+GPR24: c000003f86375a30 0000000000000007 c0002039373d9020 c0000000014c4a48
+GPR28: 0000000000000001 c000003fe62a4f6b c00020394b2e9fab c000003fe62a4ec0
+NIP [c00000000053b0cc] remove_proc_entry+0x1ec/0x200
+LR [c00000000053b0c8] remove_proc_entry+0x1e8/0x200
+Call Trace:
+[c000003f7f993740] [c00000000053b0c8] remove_proc_entry+0x1e8/0x200 (unreliable)
+[c000003f7f9937e0] [c0000000001d3654] unregister_irq_proc+0x114/0x150
+[c000003f7f993880] [c0000000001c6284] free_desc+0x54/0xb0
+[c000003f7f9938c0] [c0000000001c65ec] irq_free_descs+0xac/0x100
+[c000003f7f993910] [c0000000001d1ff8] irq_dispose_mapping+0x68/0x80
+[c000003f7f993940] [c00800000d44e8a4] kvmppc_xive_attach_escalation+0x1fc/0x270 [kvm]
+[c000003f7f9939d0] [c00800000d45013c] kvmppc_xive_connect_vcpu+0x424/0x620 [kvm]
+[c000003f7f993ac0] [c00800000d444428] kvm_arch_vcpu_ioctl+0x260/0x448 [kvm]
+[c000003f7f993b90] [c00800000d43593c] kvm_vcpu_ioctl+0x154/0x7c8 [kvm]
+[c000003f7f993d00] [c0000000004840f0] do_vfs_ioctl+0xe0/0xc30
+[c000003f7f993db0] [c000000000484d44] ksys_ioctl+0x104/0x120
+[c000003f7f993e00] [c000000000484d88] sys_ioctl+0x28/0x80
+[c000003f7f993e20] [c00000000000b278] system_call+0x5c/0x68
+Instruction dump:
+2c230000 41820008 3923ff78 e8e900a0 3c82ff69 3c62ff8d 7fa6eb78 7fc5f378
+3884f080 3863b948 4bbf6925 60000000 <0fe00000> 4bffff7c fba10088 4bbf6e41
+---[ end trace b925b67a74a1d8d1 ]---
+BUG: Kernel NULL pointer dereference at 0x00000010
+Faulting instruction address: 0xc00800000d44fc04
+Oops: Kernel access of bad area, sig: 11 [#1]
+LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
+Modules linked in: kvm_hv kvm dm_mod vhost_net vhost tap xt_CHECKSUM iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter squashfs loop fuse i2c_dev sg ofpart ocxl powernv_flash at24 xts mtd uio_pdrv_genirq vmx_crypto opal_prd ipmi_powernv uio ipmi_devintf ipmi_msghandler ibmpowernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables ext4 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq libcrc32c raid1 raid0 linear sd_mod ast i2c_algo_bit drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci libata tg3 drm_panel_orientation_quirks [last unloaded: kvm]
+CPU: 24 PID: 88176 Comm: qemu-system-ppc Tainted: G W 5.3.0-xive-nr-servers-5.3-gku+ #38
+NIP: c00800000d44fc04 LR: c00800000d44fc00 CTR: c0000000001cd970
+REGS: c000003f7f9938e0 TRAP: 0300 Tainted: G W (5.3.0-xive-nr-servers-5.3-gku+)
+MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24228882 XER: 20040000
+CFAR: c0000000001cd9ac DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
+GPR00: c00800000d44fc00 c000003f7f993b70 c00800000d468300 0000000000000000
+GPR04: 00000000000000c7 0000000000000000 0000000000000000 c000003ffacd06d8
+GPR08: 0000000000000000 c000003ffacd0738 0000000000000000 fffffffffffffffd
+GPR12: 0000000000000040 c000003ffffeb800 0000000000000000 000000012f4ce5a1
+GPR16: 000000012ef5a0c8 0000000000000000 000000012f113bb0 0000000000000000
+GPR20: 000000012f45d918 00007ffffe0d9a80 000000012f4f5df0 000000012ef8c9f8
+GPR24: 0000000000000001 0000000000000000 c000003fe4501ed0 c000003f8b1d0000
+GPR28: c0000033314689c0 c000003fe4501c00 c000003fe4501e70 c000003fe4501e90
+NIP [c00800000d44fc04] kvmppc_xive_cleanup_vcpu+0xfc/0x210 [kvm]
+LR [c00800000d44fc00] kvmppc_xive_cleanup_vcpu+0xf8/0x210 [kvm]
+Call Trace:
+[c000003f7f993b70] [c00800000d44fc00] kvmppc_xive_cleanup_vcpu+0xf8/0x210 [kvm] (unreliable)
+[c000003f7f993bd0] [c00800000d450bd4] kvmppc_xive_release+0xdc/0x1b0 [kvm]
+[c000003f7f993c30] [c00800000d436a98] kvm_device_release+0xb0/0x110 [kvm]
+[c000003f7f993c70] [c00000000046730c] __fput+0xec/0x320
+[c000003f7f993cd0] [c000000000164ae0] task_work_run+0x150/0x1c0
+[c000003f7f993d30] [c000000000025034] do_notify_resume+0x304/0x440
+[c000003f7f993e20] [c00000000000dcc4] ret_from_except_lite+0x70/0x74
+Instruction dump:
+3bff0008 7fbfd040 419e0054 847e0004 2fa30000 419effec e93d0000 8929203c
+2f890000 419effb8 4800821d e8410018 <e9230010> e9490008 9b2a0039 7c0004ac
+---[ end trace b925b67a74a1d8d2 ]---
+
+Kernel panic - not syncing: Fatal exception
+
+This affects both XIVE and XICS-on-XIVE devices since the beginning.
+
+Check the VP id instead of the vCPU id when a new vCPU is connected.
+The allocation of the XIVE CPU structure in kvmppc_xive_connect_vcpu()
+is moved after the check to avoid the need for rollback.
+
+Cc: stable@vger.kernel.org # v4.12+
+Signed-off-by: Greg Kurz <groug@kaod.org>
+Reviewed-by: Cédric Le Goater <clg@kaod.org>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_xive.c | 24 ++++++++++++++++--------
+ arch/powerpc/kvm/book3s_xive.h | 12 ++++++++++++
+ arch/powerpc/kvm/book3s_xive_native.c | 6 ++++--
+ 3 files changed, 32 insertions(+), 10 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_xive.c
++++ b/arch/powerpc/kvm/book3s_xive.c
+@@ -1217,6 +1217,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_
+ struct kvmppc_xive *xive = dev->private;
+ struct kvmppc_xive_vcpu *xc;
+ int i, r = -EBUSY;
++ u32 vp_id;
+
+ pr_devel("connect_vcpu(cpu=%d)\n", cpu);
+
+@@ -1228,25 +1229,32 @@ int kvmppc_xive_connect_vcpu(struct kvm_
+ return -EPERM;
+ if (vcpu->arch.irq_type != KVMPPC_IRQ_DEFAULT)
+ return -EBUSY;
+- if (kvmppc_xive_find_server(vcpu->kvm, cpu)) {
+- pr_devel("Duplicate !\n");
+- return -EEXIST;
+- }
+ if (cpu >= (KVM_MAX_VCPUS * vcpu->kvm->arch.emul_smt_mode)) {
+ pr_devel("Out of bounds !\n");
+ return -EINVAL;
+ }
+- xc = kzalloc(sizeof(*xc), GFP_KERNEL);
+- if (!xc)
+- return -ENOMEM;
+
+ /* We need to synchronize with queue provisioning */
+ mutex_lock(&xive->lock);
++
++ vp_id = kvmppc_xive_vp(xive, cpu);
++ if (kvmppc_xive_vp_in_use(xive->kvm, vp_id)) {
++ pr_devel("Duplicate !\n");
++ r = -EEXIST;
++ goto bail;
++ }
++
++ xc = kzalloc(sizeof(*xc), GFP_KERNEL);
++ if (!xc) {
++ r = -ENOMEM;
++ goto bail;
++ }
++
+ vcpu->arch.xive_vcpu = xc;
+ xc->xive = xive;
+ xc->vcpu = vcpu;
+ xc->server_num = cpu;
+- xc->vp_id = kvmppc_xive_vp(xive, cpu);
++ xc->vp_id = vp_id;
+ xc->mfrr = 0xff;
+ xc->valid = true;
+
+--- a/arch/powerpc/kvm/book3s_xive.h
++++ b/arch/powerpc/kvm/book3s_xive.h
+@@ -220,6 +220,18 @@ static inline u32 kvmppc_xive_vp(struct
+ return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server);
+ }
+
++static inline bool kvmppc_xive_vp_in_use(struct kvm *kvm, u32 vp_id)
++{
++ struct kvm_vcpu *vcpu = NULL;
++ int i;
++
++ kvm_for_each_vcpu(i, vcpu, kvm) {
++ if (vcpu->arch.xive_vcpu && vp_id == vcpu->arch.xive_vcpu->vp_id)
++ return true;
++ }
++ return false;
++}
++
+ /*
+ * Mapping between guest priorities and host priorities
+ * is as follow.
+--- a/arch/powerpc/kvm/book3s_xive_native.c
++++ b/arch/powerpc/kvm/book3s_xive_native.c
+@@ -106,6 +106,7 @@ int kvmppc_xive_native_connect_vcpu(stru
+ struct kvmppc_xive *xive = dev->private;
+ struct kvmppc_xive_vcpu *xc = NULL;
+ int rc;
++ u32 vp_id;
+
+ pr_devel("native_connect_vcpu(server=%d)\n", server_num);
+
+@@ -124,7 +125,8 @@ int kvmppc_xive_native_connect_vcpu(stru
+
+ mutex_lock(&xive->lock);
+
+- if (kvmppc_xive_find_server(vcpu->kvm, server_num)) {
++ vp_id = kvmppc_xive_vp(xive, server_num);
++ if (kvmppc_xive_vp_in_use(xive->kvm, vp_id)) {
+ pr_devel("Duplicate !\n");
+ rc = -EEXIST;
+ goto bail;
+@@ -141,7 +143,7 @@ int kvmppc_xive_native_connect_vcpu(stru
+ xc->vcpu = vcpu;
+ xc->server_num = server_num;
+
+- xc->vp_id = kvmppc_xive_vp(xive, server_num);
++ xc->vp_id = vp_id;
+ xc->valid = true;
+ vcpu->arch.irq_type = KVMPPC_IRQ_XIVE;
+
--- /dev/null
+From 28c9fac09ab0147158db0baeec630407a5e9b892 Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sat, 5 Oct 2019 13:21:01 +0200
+Subject: memstick: jmb38x_ms: Fix an error handling path in 'jmb38x_ms_probe()'
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 28c9fac09ab0147158db0baeec630407a5e9b892 upstream.
+
+If 'jmb38x_ms_count_slots()' returns 0, we must undo the previous
+'pci_request_regions()' call.
+
+Goto 'err_out_int' to fix it.
+
+Fixes: 60fdd931d577 ("memstick: add support for JMicron jmb38x MemoryStick host controller")
+Cc: stable@vger.kernel.org
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/memstick/host/jmb38x_ms.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/memstick/host/jmb38x_ms.c
++++ b/drivers/memstick/host/jmb38x_ms.c
+@@ -941,7 +941,7 @@ static int jmb38x_ms_probe(struct pci_de
+ if (!cnt) {
+ rc = -ENODEV;
+ pci_dev_busy = 1;
+- goto err_out;
++ goto err_out_int;
+ }
+
+ jm = kzalloc(sizeof(struct jmb38x_ms)
--- /dev/null
+From 5dba51754b04a941a1064f584e7a7f607df3f9bc Mon Sep 17 00:00:00 2001
+From: Chris Goldsworthy <cgoldswo@codeaurora.org>
+Date: Sat, 19 Oct 2019 18:57:24 -0700
+Subject: of: reserved_mem: add missing of_node_put() for proper ref-counting
+
+From: Chris Goldsworthy <cgoldswo@codeaurora.org>
+
+commit 5dba51754b04a941a1064f584e7a7f607df3f9bc upstream.
+
+Commit d698a388146c ("of: reserved-memory: ignore disabled memory-region
+nodes") added an early return in of_reserved_mem_device_init_by_idx(), but
+didn't call of_node_put() on a device_node whose ref-count was incremented
+in the call to of_parse_phandle() preceding the early exit.
+
+Fixes: d698a388146c ("of: reserved-memory: ignore disabled memory-region nodes")
+Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
+Cc: stable@vger.kernel.org
+Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/of/of_reserved_mem.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/of/of_reserved_mem.c
++++ b/drivers/of/of_reserved_mem.c
+@@ -324,8 +324,10 @@ int of_reserved_mem_device_init_by_idx(s
+ if (!target)
+ return -ENODEV;
+
+- if (!of_device_is_available(target))
++ if (!of_device_is_available(target)) {
++ of_node_put(target);
+ return 0;
++ }
+
+ rmem = __find_rmem(target);
+ of_node_put(target);
--- /dev/null
+From f2edbb6699b0bc6e4f789846b99007200546c6c2 Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Thu, 10 Oct 2019 15:55:33 +0530
+Subject: opp: of: drop incorrect lockdep_assert_held()
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+commit f2edbb6699b0bc6e4f789846b99007200546c6c2 upstream.
+
+_find_opp_of_np() doesn't traverse the list of OPP tables but instead
+just the entries within an OPP table and so only requires to lock the
+OPP table itself.
+
+The lockdep_assert_held() was added there by mistake and isn't really
+required.
+
+Fixes: 5d6d106fa455 ("OPP: Populate required opp tables from "required-opps" property")
+Cc: v5.0+ <stable@vger.kernel.org> # v5.0+
+Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/opp/of.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/opp/of.c
++++ b/drivers/opp/of.c
+@@ -77,8 +77,6 @@ static struct dev_pm_opp *_find_opp_of_n
+ {
+ struct dev_pm_opp *opp;
+
+- lockdep_assert_held(&opp_table_lock);
+-
+ mutex_lock(&opp_table->lock);
+
+ list_for_each_entry(opp, &opp_table->opp_list, node) {
--- /dev/null
+From 45144d42f299455911cc29366656c7324a3a7c97 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Mon, 14 Oct 2019 13:25:00 +0200
+Subject: PCI: PM: Fix pci_power_up()
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 45144d42f299455911cc29366656c7324a3a7c97 upstream.
+
+There is an arbitrary difference between the system resume and
+runtime resume code paths for PCI devices regarding the delay to
+apply when switching the devices from D3cold to D0.
+
+Namely, pci_restore_standard_config() used in the runtime resume
+code path calls pci_set_power_state() which in turn invokes
+__pci_start_power_transition() to power up the device through the
+platform firmware and that function applies the transition delay
+(as per PCI Express Base Specification Revision 2.0, Section 6.6.1).
+However, pci_pm_default_resume_early() used in the system resume
+code path calls pci_power_up() which doesn't apply the delay at
+all and that causes issues to occur during resume from
+suspend-to-idle on some systems where the delay is required.
+
+Since there is no reason for that difference to exist, modify
+pci_power_up() to follow pci_set_power_state() more closely and
+invoke __pci_start_power_transition() from there to call the
+platform firmware to power up the device (in case that's necessary).
+
+Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()")
+Reported-by: Daniel Drake <drake@endlessm.com>
+Tested-by: Daniel Drake <drake@endlessm.com>
+Link: https://lore.kernel.org/linux-pm/CAD8Lp44TYxrMgPLkHCqF9hv6smEurMXvmmvmtyFhZ6Q4SE+dig@mail.gmail.com/T/#m21be74af263c6a34f36e0fc5c77c5449d9406925
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Acked-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pci.c | 24 +++++++++++-------------
+ 1 file changed, 11 insertions(+), 13 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -959,19 +959,6 @@ void pci_refresh_power_state(struct pci_
+ }
+
+ /**
+- * pci_power_up - Put the given device into D0 forcibly
+- * @dev: PCI device to power up
+- */
+-void pci_power_up(struct pci_dev *dev)
+-{
+- if (platform_pci_power_manageable(dev))
+- platform_pci_set_power_state(dev, PCI_D0);
+-
+- pci_raw_set_power_state(dev, PCI_D0);
+- pci_update_current_state(dev, PCI_D0);
+-}
+-
+-/**
+ * pci_platform_power_transition - Use platform to change device power state
+ * @dev: PCI device to handle.
+ * @state: State to put the device into.
+@@ -1154,6 +1141,17 @@ int pci_set_power_state(struct pci_dev *
+ EXPORT_SYMBOL(pci_set_power_state);
+
+ /**
++ * pci_power_up - Put the given device into D0 forcibly
++ * @dev: PCI device to power up
++ */
++void pci_power_up(struct pci_dev *dev)
++{
++ __pci_start_power_transition(dev, PCI_D0);
++ pci_raw_set_power_state(dev, PCI_D0);
++ pci_update_current_state(dev, PCI_D0);
++}
++
++/**
+ * pci_choose_state - Choose the power state of a PCI device
+ * @dev: PCI device to be suspended
+ * @state: target sleep state for the whole system. This is the value
--- /dev/null
+From f3a519e4add93b7b31a6616f0b09635ff2e6a159 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 22 Oct 2019 10:39:40 +0300
+Subject: perf/aux: Fix AUX output stopping
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit f3a519e4add93b7b31a6616f0b09635ff2e6a159 upstream.
+
+Commit:
+
+ 8a58ddae2379 ("perf/core: Fix exclusive events' grouping")
+
+allows CAP_EXCLUSIVE events to be grouped with other events. Since all
+of those also happen to be AUX events (which is not the case the other
+way around, because arch/s390), this changes the rules for stopping the
+output: the AUX event may not be on its PMU's context any more, if it's
+grouped with a HW event, in which case it will be on that HW event's
+context instead. If that's the case, munmap() of the AUX buffer can't
+find and stop the AUX event, potentially leaving the last reference with
+the atomic context, which will then end up freeing the AUX buffer. This
+will then trip warnings:
+
+Fix this by using the context's PMU context when looking for events
+to stop, instead of the event's PMU context.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20191022073940.61814-1-alexander.shishkin@linux.intel.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/events/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/events/core.c
++++ b/kernel/events/core.c
+@@ -6839,7 +6839,7 @@ static void __perf_event_output_stop(str
+ static int __perf_pmu_output_stop(void *info)
+ {
+ struct perf_event *event = info;
+- struct pmu *pmu = event->pmu;
++ struct pmu *pmu = event->ctx->pmu;
+ struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
+ struct remote_output ro = {
+ .rb = event->rb,
--- /dev/null
+From 20504fa1d2ffd5d03cdd9dc9c9dd4ed4579b97ef Mon Sep 17 00:00:00 2001
+From: Patrick Williams <alpawi@amazon.com>
+Date: Tue, 1 Oct 2019 10:46:31 -0500
+Subject: pinctrl: armada-37xx: fix control of pins 32 and up
+
+From: Patrick Williams <alpawi@amazon.com>
+
+commit 20504fa1d2ffd5d03cdd9dc9c9dd4ed4579b97ef upstream.
+
+The 37xx configuration registers are only 32 bits long, so
+pins 32-35 spill over into the next register. The calculation
+for the register address was done, but the bitmask was not, so
+any configuration to pin 32 or above resulted in a bitmask that
+overflowed and performed no action.
+
+Fix the register / offset calculation to also adjust the offset.
+
+Fixes: 5715092a458c ("pinctrl: armada-37xx: Add gpio support")
+Signed-off-by: Patrick Williams <alpawi@amazon.com>
+Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191001154634.96165-1-alpawi@amazon.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
++++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+@@ -221,11 +221,11 @@ static const struct armada_37xx_pin_data
+ };
+
+ static inline void armada_37xx_update_reg(unsigned int *reg,
+- unsigned int offset)
++ unsigned int *offset)
+ {
+ /* We never have more than 2 registers */
+- if (offset >= GPIO_PER_REG) {
+- offset -= GPIO_PER_REG;
++ if (*offset >= GPIO_PER_REG) {
++ *offset -= GPIO_PER_REG;
+ *reg += sizeof(u32);
+ }
+ }
+@@ -376,7 +376,7 @@ static inline void armada_37xx_irq_updat
+ {
+ int offset = irqd_to_hwirq(d);
+
+- armada_37xx_update_reg(reg, offset);
++ armada_37xx_update_reg(reg, &offset);
+ }
+
+ static int armada_37xx_gpio_direction_input(struct gpio_chip *chip,
+@@ -386,7 +386,7 @@ static int armada_37xx_gpio_direction_in
+ unsigned int reg = OUTPUT_EN;
+ unsigned int mask;
+
+- armada_37xx_update_reg(®, offset);
++ armada_37xx_update_reg(®, &offset);
+ mask = BIT(offset);
+
+ return regmap_update_bits(info->regmap, reg, mask, 0);
+@@ -399,7 +399,7 @@ static int armada_37xx_gpio_get_directio
+ unsigned int reg = OUTPUT_EN;
+ unsigned int val, mask;
+
+- armada_37xx_update_reg(®, offset);
++ armada_37xx_update_reg(®, &offset);
+ mask = BIT(offset);
+ regmap_read(info->regmap, reg, &val);
+
+@@ -413,7 +413,7 @@ static int armada_37xx_gpio_direction_ou
+ unsigned int reg = OUTPUT_EN;
+ unsigned int mask, val, ret;
+
+- armada_37xx_update_reg(®, offset);
++ armada_37xx_update_reg(®, &offset);
+ mask = BIT(offset);
+
+ ret = regmap_update_bits(info->regmap, reg, mask, mask);
+@@ -434,7 +434,7 @@ static int armada_37xx_gpio_get(struct g
+ unsigned int reg = INPUT_VAL;
+ unsigned int val, mask;
+
+- armada_37xx_update_reg(®, offset);
++ armada_37xx_update_reg(®, &offset);
+ mask = BIT(offset);
+
+ regmap_read(info->regmap, reg, &val);
+@@ -449,7 +449,7 @@ static void armada_37xx_gpio_set(struct
+ unsigned int reg = OUTPUT_VAL;
+ unsigned int mask, val;
+
+- armada_37xx_update_reg(®, offset);
++ armada_37xx_update_reg(®, &offset);
+ mask = BIT(offset);
+ val = value ? mask : 0;
+
--- /dev/null
+From b835d6953009dc350d61402a854b5a7178d8c615 Mon Sep 17 00:00:00 2001
+From: Patrick Williams <alpawi@amazon.com>
+Date: Tue, 1 Oct 2019 10:51:38 -0500
+Subject: pinctrl: armada-37xx: swap polarity on LED group
+
+From: Patrick Williams <alpawi@amazon.com>
+
+commit b835d6953009dc350d61402a854b5a7178d8c615 upstream.
+
+The configuration registers for the LED group have inverted
+polarity, which puts the GPIO into open-drain state when used in
+GPIO mode. Switch to '0' for GPIO and '1' for LED modes.
+
+Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for Armada 37xx")
+Signed-off-by: Patrick Williams <alpawi@amazon.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191001155154.99710-1-alpawi@amazon.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
++++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+@@ -183,10 +183,10 @@ static struct armada_37xx_pin_group arma
+ PIN_GRP_EXTRA("uart2", 9, 2, BIT(1) | BIT(13) | BIT(14) | BIT(19),
+ BIT(1) | BIT(13) | BIT(14), BIT(1) | BIT(19),
+ 18, 2, "gpio", "uart"),
+- PIN_GRP_GPIO("led0_od", 11, 1, BIT(20), "led"),
+- PIN_GRP_GPIO("led1_od", 12, 1, BIT(21), "led"),
+- PIN_GRP_GPIO("led2_od", 13, 1, BIT(22), "led"),
+- PIN_GRP_GPIO("led3_od", 14, 1, BIT(23), "led"),
++ PIN_GRP_GPIO_2("led0_od", 11, 1, BIT(20), BIT(20), 0, "led"),
++ PIN_GRP_GPIO_2("led1_od", 12, 1, BIT(21), BIT(21), 0, "led"),
++ PIN_GRP_GPIO_2("led2_od", 13, 1, BIT(22), BIT(22), 0, "led"),
++ PIN_GRP_GPIO_2("led3_od", 14, 1, BIT(23), BIT(23), 0, "led"),
+
+ };
+
--- /dev/null
+From 260996c30f4f3a732f45045e3e0efe27017615e4 Mon Sep 17 00:00:00 2001
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Date: Mon, 23 Sep 2019 19:49:58 -0700
+Subject: pinctrl: cherryview: restore Strago DMI workaround for all versions
+
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+commit 260996c30f4f3a732f45045e3e0efe27017615e4 upstream.
+
+This is essentially a revert of:
+
+e3f72b749da2 pinctrl: cherryview: fix Strago DMI workaround
+86c5dd6860a6 pinctrl: cherryview: limit Strago DMI workarounds to version 1.0
+
+because even with 1.1 versions of BIOS there are some pins that are
+configured as interrupts but not claimed by any driver, and they
+sometimes fire up and result in interrupt storms that cause touchpad
+stop functioning and other issues.
+
+Given that we are unlikely to qualify another firmware version for a
+while it is better to keep the workaround active on all Strago boards.
+
+Reported-by: Alex Levin <levinale@chromium.org>
+Fixes: 86c5dd6860a6 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Tested-by: Alex Levin <levinale@chromium.org>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
++++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
+@@ -1513,7 +1513,6 @@ static const struct dmi_system_id chv_no
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "Intel_Strago"),
+- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
+ },
+ },
+ {
+@@ -1521,7 +1520,6 @@ static const struct dmi_system_id chv_no
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Setzer"),
+- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
+ },
+ },
+ {
+@@ -1529,7 +1527,6 @@ static const struct dmi_system_id chv_no
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Cyan"),
+- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
+ },
+ },
+ {
+@@ -1537,7 +1534,6 @@ static const struct dmi_system_id chv_no
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Celes"),
+- DMI_MATCH(DMI_PRODUCT_VERSION, "1.0"),
+ },
+ },
+ {}
arm64-avoid-cavium-tx2-erratum-219-when-switching-ttbr.patch
arm64-enable-workaround-for-cavium-tx2-erratum-219-when-running-smt.patch
arm64-allow-cavium_tx2_erratum_219-to-be-selected.patch
+cifs-avoid-using-mid-0xffff.patch
+cifs-fix-missed-free-operations.patch
+cifs-fix-use-after-free-of-file-info-structures.patch
+perf-aux-fix-aux-output-stopping.patch
+tracing-fix-race-in-perf_trace_buf-initialization.patch
+fs-dax-fix-pmd-vs-pte-conflict-detection.patch
+dm-cache-fix-bugs-when-a-gfp_nowait-allocation-fails.patch
+irqchip-sifive-plic-switch-to-fasteoi-flow.patch
+x86-boot-64-make-level2_kernel_pgt-pages-invalid-outside-kernel-area.patch
+x86-apic-x2apic-fix-a-null-pointer-deref-when-handling-a-dying-cpu.patch
+x86-hyperv-make-vapic-support-x2apic-mode.patch
+pinctrl-cherryview-restore-strago-dmi-workaround-for-all-versions.patch
+pinctrl-armada-37xx-fix-control-of-pins-32-and-up.patch
+pinctrl-armada-37xx-swap-polarity-on-led-group.patch
+btrfs-block-group-fix-a-memory-leak-due-to-missing-btrfs_put_block_group.patch
+btrfs-add-missing-extents-release-on-file-extent-cluster-relocation-error.patch
+btrfs-don-t-needlessly-create-extent-refs-kernel-thread.patch
+btrfs-fix-qgroup-double-free-after-failure-to-reserve-metadata-for-delalloc.patch
+btrfs-check-for-the-full-sync-flag-while-holding-the-inode-lock-during-fsync.patch
+btrfs-tracepoints-fix-wrong-parameter-order-for-qgroup-events.patch
+btrfs-tracepoints-fix-bad-entry-members-of-qgroup-events.patch
+kvm-ppc-book3s-hv-xive-ensure-vp-isn-t-already-in-use.patch
+memstick-jmb38x_ms-fix-an-error-handling-path-in-jmb38x_ms_probe.patch
+cpufreq-avoid-cpufreq_suspend-deadlock-on-system-shutdown.patch
+ceph-just-skip-unrecognized-info-in-ceph_reply_info_extra.patch
+xen-netback-fix-error-path-of-xenvif_connect_data.patch
+pci-pm-fix-pci_power_up.patch
+opp-of-drop-incorrect-lockdep_assert_held.patch
+of-reserved_mem-add-missing-of_node_put-for-proper-ref-counting.patch
+blk-rq-qos-fix-first-node-deletion-of-rq_qos_del.patch
--- /dev/null
+From 6b1340cc00edeadd52ebd8a45171f38c8de2a387 Mon Sep 17 00:00:00 2001
+From: Prateek Sood <prsood@codeaurora.org>
+Date: Tue, 15 Oct 2019 11:47:25 +0530
+Subject: tracing: Fix race in perf_trace_buf initialization
+
+From: Prateek Sood <prsood@codeaurora.org>
+
+commit 6b1340cc00edeadd52ebd8a45171f38c8de2a387 upstream.
+
+A race condition exists while initialiazing perf_trace_buf from
+perf_trace_init() and perf_kprobe_init().
+
+ CPU0 CPU1
+perf_trace_init()
+ mutex_lock(&event_mutex)
+ perf_trace_event_init()
+ perf_trace_event_reg()
+ total_ref_count == 0
+ buf = alloc_percpu()
+ perf_trace_buf[i] = buf
+ tp_event->class->reg() //fails perf_kprobe_init()
+ goto fail perf_trace_event_init()
+ perf_trace_event_reg()
+ fail:
+ total_ref_count == 0
+
+ total_ref_count == 0
+ buf = alloc_percpu()
+ perf_trace_buf[i] = buf
+ tp_event->class->reg()
+ total_ref_count++
+
+ free_percpu(perf_trace_buf[i])
+ perf_trace_buf[i] = NULL
+
+Any subsequent call to perf_trace_event_reg() will observe total_ref_count > 0,
+causing the perf_trace_buf to be always NULL. This can result in perf_trace_buf
+getting accessed from perf_trace_buf_alloc() without being initialized. Acquiring
+event_mutex in perf_kprobe_init() before calling perf_trace_event_init() should
+fix this race.
+
+The race caused the following bug:
+
+ Unable to handle kernel paging request at virtual address 0000003106f2003c
+ Mem abort info:
+ ESR = 0x96000045
+ Exception class = DABT (current EL), IL = 32 bits
+ SET = 0, FnV = 0
+ EA = 0, S1PTW = 0
+ Data abort info:
+ ISV = 0, ISS = 0x00000045
+ CM = 0, WnR = 1
+ user pgtable: 4k pages, 39-bit VAs, pgdp = ffffffc034b9b000
+ [0000003106f2003c] pgd=0000000000000000, pud=0000000000000000
+ Internal error: Oops: 96000045 [#1] PREEMPT SMP
+ Process syz-executor (pid: 18393, stack limit = 0xffffffc093190000)
+ pstate: 80400005 (Nzcv daif +PAN -UAO)
+ pc : __memset+0x20/0x1ac
+ lr : memset+0x3c/0x50
+ sp : ffffffc09319fc50
+
+ __memset+0x20/0x1ac
+ perf_trace_buf_alloc+0x140/0x1a0
+ perf_trace_sys_enter+0x158/0x310
+ syscall_trace_enter+0x348/0x7c0
+ el0_svc_common+0x11c/0x368
+ el0_svc_handler+0x12c/0x198
+ el0_svc+0x8/0xc
+
+Ramdumps showed the following:
+ total_ref_count = 3
+ perf_trace_buf = (
+ 0x0 -> NULL,
+ 0x0 -> NULL,
+ 0x0 -> NULL,
+ 0x0 -> NULL)
+
+Link: http://lkml.kernel.org/r/1571120245-4186-1-git-send-email-prsood@codeaurora.org
+
+Cc: stable@vger.kernel.org
+Fixes: e12f03d7031a9 ("perf/core: Implement the 'perf_kprobe' PMU")
+Acked-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Prateek Sood <prsood@codeaurora.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_event_perf.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/trace/trace_event_perf.c
++++ b/kernel/trace/trace_event_perf.c
+@@ -272,9 +272,11 @@ int perf_kprobe_init(struct perf_event *
+ goto out;
+ }
+
++ mutex_lock(&event_mutex);
+ ret = perf_trace_event_init(tp_event, p_event);
+ if (ret)
+ destroy_local_trace_kprobe(tp_event);
++ mutex_unlock(&event_mutex);
+ out:
+ kfree(func);
+ return ret;
+@@ -282,8 +284,10 @@ out:
+
+ void perf_kprobe_destroy(struct perf_event *p_event)
+ {
++ mutex_lock(&event_mutex);
+ perf_trace_event_close(p_event);
+ perf_trace_event_unreg(p_event);
++ mutex_unlock(&event_mutex);
+
+ destroy_local_trace_kprobe(p_event->tp_event);
+ }
--- /dev/null
+From 7a22e03b0c02988e91003c505b34d752a51de344 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Tue, 1 Oct 2019 13:50:19 -0700
+Subject: x86/apic/x2apic: Fix a NULL pointer deref when handling a dying cpu
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit 7a22e03b0c02988e91003c505b34d752a51de344 upstream.
+
+Check that the per-cpu cluster mask pointer has been set prior to
+clearing a dying cpu's bit. The per-cpu pointer is not set until the
+target cpu reaches smp_callin() during CPUHP_BRINGUP_CPU, whereas the
+teardown function, x2apic_dead_cpu(), is associated with the earlier
+CPUHP_X2APIC_PREPARE. If an error occurs before the cpu is awakened,
+e.g. if do_boot_cpu() itself fails, x2apic_dead_cpu() will dereference
+the NULL pointer and cause a panic.
+
+ smpboot: do_boot_cpu failed(-22) to wakeup CPU#1
+ BUG: kernel NULL pointer dereference, address: 0000000000000008
+ RIP: 0010:x2apic_dead_cpu+0x1a/0x30
+ Call Trace:
+ cpuhp_invoke_callback+0x9a/0x580
+ _cpu_up+0x10d/0x140
+ do_cpu_up+0x69/0xb0
+ smp_init+0x63/0xa9
+ kernel_init_freeable+0xd7/0x229
+ ? rest_init+0xa0/0xa0
+ kernel_init+0xa/0x100
+ ret_from_fork+0x35/0x40
+
+Fixes: 023a611748fd5 ("x86/apic/x2apic: Simplify cluster management")
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20191001205019.5789-1-sean.j.christopherson@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/apic/x2apic_cluster.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/apic/x2apic_cluster.c
++++ b/arch/x86/kernel/apic/x2apic_cluster.c
+@@ -158,7 +158,8 @@ static int x2apic_dead_cpu(unsigned int
+ {
+ struct cluster_mask *cmsk = per_cpu(cluster_masks, dead_cpu);
+
+- cpumask_clear_cpu(dead_cpu, &cmsk->mask);
++ if (cmsk)
++ cpumask_clear_cpu(dead_cpu, &cmsk->mask);
+ free_cpumask_var(per_cpu(ipi_mask, dead_cpu));
+ return 0;
+ }
--- /dev/null
+From 2aa85f246c181b1fa89f27e8e20c5636426be624 Mon Sep 17 00:00:00 2001
+From: Steve Wahl <steve.wahl@hpe.com>
+Date: Tue, 24 Sep 2019 16:03:55 -0500
+Subject: x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area
+
+From: Steve Wahl <steve.wahl@hpe.com>
+
+commit 2aa85f246c181b1fa89f27e8e20c5636426be624 upstream.
+
+Our hardware (UV aka Superdome Flex) has address ranges marked
+reserved by the BIOS. Access to these ranges is caught as an error,
+causing the BIOS to halt the system.
+
+Initial page tables mapped a large range of physical addresses that
+were not checked against the list of BIOS reserved addresses, and
+sometimes included reserved addresses in part of the mapped range.
+Including the reserved range in the map allowed processor speculative
+accesses to the reserved range, triggering a BIOS halt.
+
+Used early in booting, the page table level2_kernel_pgt addresses 1
+GiB divided into 2 MiB pages, and it was set up to linearly map a full
+ 1 GiB of physical addresses that included the physical address range
+of the kernel image, as chosen by KASLR. But this also included a
+large range of unused addresses on either side of the kernel image.
+And unlike the kernel image's physical address range, this extra
+mapped space was not checked against the BIOS tables of usable RAM
+addresses. So there were times when the addresses chosen by KASLR
+would result in processor accessible mappings of BIOS reserved
+physical addresses.
+
+The kernel code did not directly access any of this extra mapped
+space, but having it mapped allowed the processor to issue speculative
+accesses into reserved memory, causing system halts.
+
+This was encountered somewhat rarely on a normal system boot, and much
+more often when starting the crash kernel if "crashkernel=512M,high"
+was specified on the command line (this heavily restricts the physical
+address of the crash kernel, in our case usually within 1 GiB of
+reserved space).
+
+The solution is to invalidate the pages of this table outside the kernel
+image's space before the page table is activated. It fixes this problem
+on our hardware.
+
+ [ bp: Touchups. ]
+
+Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: Baoquan He <bhe@redhat.com>
+Cc: Brijesh Singh <brijesh.singh@amd.com>
+Cc: dimitri.sivanich@hpe.com
+Cc: Feng Tang <feng.tang@intel.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Jordan Borgner <mail@jordan-borgner.de>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: mike.travis@hpe.com
+Cc: russ.anderson@hpe.com
+Cc: stable@vger.kernel.org
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: x86-ml <x86@kernel.org>
+Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
+Link: https://lkml.kernel.org/r/9c011ee51b081534a7a15065b1681d200298b530.1569358539.git.steve.wahl@hpe.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/head64.c | 22 ++++++++++++++++++++--
+ 1 file changed, 20 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/head64.c
++++ b/arch/x86/kernel/head64.c
+@@ -222,13 +222,31 @@ unsigned long __head __startup_64(unsign
+ * we might write invalid pmds, when the kernel is relocated
+ * cleanup_highmap() fixes this up along with the mappings
+ * beyond _end.
++ *
++ * Only the region occupied by the kernel image has so far
++ * been checked against the table of usable memory regions
++ * provided by the firmware, so invalidate pages outside that
++ * region. A page table entry that maps to a reserved area of
++ * memory would allow processor speculation into that area,
++ * and on some hardware (particularly the UV platform) even
++ * speculative access to some reserved areas is caught as an
++ * error, causing the BIOS to halt the system.
+ */
+
+ pmd = fixup_pointer(level2_kernel_pgt, physaddr);
+- for (i = 0; i < PTRS_PER_PMD; i++) {
++
++ /* invalidate pages before the kernel image */
++ for (i = 0; i < pmd_index((unsigned long)_text); i++)
++ pmd[i] &= ~_PAGE_PRESENT;
++
++ /* fixup pages that are part of the kernel image */
++ for (; i <= pmd_index((unsigned long)_end); i++)
+ if (pmd[i] & _PAGE_PRESENT)
+ pmd[i] += load_delta;
+- }
++
++ /* invalidate pages after the kernel image */
++ for (; i < PTRS_PER_PMD; i++)
++ pmd[i] &= ~_PAGE_PRESENT;
+
+ /*
+ * Fixup phys_base - remove the memory encryption mask to obtain
--- /dev/null
+From e211288b72f15259da86eed6eca680758dbe9e74 Mon Sep 17 00:00:00 2001
+From: Roman Kagan <rkagan@virtuozzo.com>
+Date: Thu, 10 Oct 2019 12:33:05 +0000
+Subject: x86/hyperv: Make vapic support x2apic mode
+
+From: Roman Kagan <rkagan@virtuozzo.com>
+
+commit e211288b72f15259da86eed6eca680758dbe9e74 upstream.
+
+Now that there's Hyper-V IOMMU driver, Linux can switch to x2apic mode
+when supported by the vcpus.
+
+However, the apic access functions for Hyper-V enlightened apic assume
+xapic mode only.
+
+As a result, Linux fails to bring up secondary cpus when run as a guest
+in QEMU/KVM with both hv_apic and x2apic enabled.
+
+According to Michael Kelley, when in x2apic mode, the Hyper-V synthetic
+apic MSRs behave exactly the same as the corresponding architectural
+x2apic MSRs, so there's no need to override the apic accessors. The
+only exception is hv_apic_eoi_write, which benefits from lazy EOI when
+available; however, its implementation works for both xapic and x2apic
+modes.
+
+Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
+Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access")
+Suggested-by: Michael Kelley <mikelley@microsoft.com>
+Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20191010123258.16919-1-rkagan@virtuozzo.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/hyperv/hv_apic.c | 20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/hyperv/hv_apic.c
++++ b/arch/x86/hyperv/hv_apic.c
+@@ -260,11 +260,21 @@ void __init hv_apic_init(void)
+ }
+
+ if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
+- pr_info("Hyper-V: Using MSR based APIC access\n");
++ pr_info("Hyper-V: Using enlightened APIC (%s mode)",
++ x2apic_enabled() ? "x2apic" : "xapic");
++ /*
++ * With x2apic, architectural x2apic MSRs are equivalent to the
++ * respective synthetic MSRs, so there's no need to override
++ * the apic accessors. The only exception is
++ * hv_apic_eoi_write, because it benefits from lazy EOI when
++ * available, but it works for both xapic and x2apic modes.
++ */
+ apic_set_eoi_write(hv_apic_eoi_write);
+- apic->read = hv_apic_read;
+- apic->write = hv_apic_write;
+- apic->icr_write = hv_apic_icr_write;
+- apic->icr_read = hv_apic_icr_read;
++ if (!x2apic_enabled()) {
++ apic->read = hv_apic_read;
++ apic->write = hv_apic_write;
++ apic->icr_write = hv_apic_icr_write;
++ apic->icr_read = hv_apic_icr_read;
++ }
+ }
+ }
--- /dev/null
+From 3d5c1a037d37392a6859afbde49be5ba6a70a6b3 Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Fri, 18 Oct 2019 09:45:49 +0200
+Subject: xen/netback: fix error path of xenvif_connect_data()
+
+From: Juergen Gross <jgross@suse.com>
+
+commit 3d5c1a037d37392a6859afbde49be5ba6a70a6b3 upstream.
+
+xenvif_connect_data() calls module_put() in case of error. This is
+wrong as there is no related module_get().
+
+Remove the superfluous module_put().
+
+Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif is shut down")
+Cc: <stable@vger.kernel.org> # 3.12
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Reviewed-by: Paul Durrant <paul@xen.org>
+Reviewed-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/xen-netback/interface.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/net/xen-netback/interface.c
++++ b/drivers/net/xen-netback/interface.c
+@@ -719,7 +719,6 @@ err_unmap:
+ xenvif_unmap_frontend_data_rings(queue);
+ netif_napi_del(&queue->napi);
+ err:
+- module_put(THIS_MODULE);
+ return err;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
