--- /dev/null
+From d4548543fc4ece56c6f04b8586f435fb4fd84c20 Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Tue, 30 Apr 2019 19:59:42 +0800
+Subject: 9p/virtio: Add cleanup path in p9_virtio_init
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+commit d4548543fc4ece56c6f04b8586f435fb4fd84c20 upstream.
+
+KASAN report this:
+
+BUG: unable to handle kernel paging request at ffffffffa0097000
+PGD 3870067 P4D 3870067 PUD 3871063 PMD 2326e2067 PTE 0
+Oops: 0000 [#1
+CPU: 0 PID: 5340 Comm: modprobe Not tainted 5.1.0-rc7+ #25
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
+RIP: 0010:__list_add_valid+0x10/0x70
+Code: c3 48 8b 06 55 48 89 e5 5d 48 39 07 0f 94 c0 0f b6 c0 c3 90 90 90 90 90 90 90 55 48 89 d0 48 8b 52 08 48 89 e5 48 39 f2 75 19 <48> 8b 32 48 39 f0 75 3a
+
+RSP: 0018:ffffc90000e23c68 EFLAGS: 00010246
+RAX: ffffffffa00ad000 RBX: ffffffffa009d000 RCX: 0000000000000000
+RDX: ffffffffa0097000 RSI: ffffffffa0097000 RDI: ffffffffa009d000
+RBP: ffffc90000e23c68 R08: 0000000000000001 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0097000
+R13: ffff888231797180 R14: 0000000000000000 R15: ffffc90000e23e78
+FS: 00007fb215285540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: ffffffffa0097000 CR3: 000000022f144000 CR4: 00000000000006f0
+Call Trace:
+ v9fs_register_trans+0x2f/0x60 [9pnet
+ ? 0xffffffffa0087000
+ p9_virtio_init+0x25/0x1000 [9pnet_virtio
+ do_one_initcall+0x6c/0x3cc
+ ? kmem_cache_alloc_trace+0x248/0x3b0
+ do_init_module+0x5b/0x1f1
+ load_module+0x1db1/0x2690
+ ? m_show+0x1d0/0x1d0
+ __do_sys_finit_module+0xc5/0xd0
+ __x64_sys_finit_module+0x15/0x20
+ do_syscall_64+0x6b/0x1d0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+RIP: 0033:0x7fb214d8e839
+Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01
+
+RSP: 002b:00007ffc96554278 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
+RAX: ffffffffffffffda RBX: 000055e67eed2aa0 RCX: 00007fb214d8e839
+RDX: 0000000000000000 RSI: 000055e67ce95c2e RDI: 0000000000000003
+RBP: 000055e67ce95c2e R08: 0000000000000000 R09: 000055e67eed2aa0
+R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
+R13: 000055e67eeda500 R14: 0000000000040000 R15: 000055e67eed2aa0
+Modules linked in: 9pnet_virtio(+) 9pnet gre rfkill vmw_vsock_virtio_transport_common vsock [last unloaded: 9pnet_virtio
+CR2: ffffffffa0097000
+---[ end trace 4a52bb13ff07b761
+
+If register_virtio_driver() fails in p9_virtio_init,
+we should call v9fs_unregister_trans() to do cleanup.
+
+Link: http://lkml.kernel.org/r/20190430115942.41840-1-yuehaibing@huawei.com
+Cc: stable@vger.kernel.org
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Fixes: b530cc794024 ("9p: add virtio transport")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/9p/trans_virtio.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/net/9p/trans_virtio.c
++++ b/net/9p/trans_virtio.c
+@@ -764,10 +764,16 @@ static struct p9_trans_module p9_virtio_
+ /* The standard init function */
+ static int __init p9_virtio_init(void)
+ {
++ int rc;
++
+ INIT_LIST_HEAD(&virtio_chan_list);
+
+ v9fs_register_trans(&p9_virtio_trans);
+- return register_virtio_driver(&p9_virtio_drv);
++ rc = register_virtio_driver(&p9_virtio_drv);
++ if (rc)
++ v9fs_unregister_trans(&p9_virtio_trans);
++
++ return rc;
+ }
+
+ static void __exit p9_virtio_cleanup(void)
--- /dev/null
+From 80a316ff16276b36d0392a8f8b2f63259857ae98 Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Tue, 30 Apr 2019 22:39:33 +0800
+Subject: 9p/xen: Add cleanup path in p9_trans_xen_init
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+commit 80a316ff16276b36d0392a8f8b2f63259857ae98 upstream.
+
+If xenbus_register_frontend() fails in p9_trans_xen_init,
+we should call v9fs_unregister_trans() to do cleanup.
+
+Link: http://lkml.kernel.org/r/20190430143933.19368-1-yuehaibing@huawei.com
+Cc: stable@vger.kernel.org
+Fixes: 868eb122739a ("xen/9pfs: introduce Xen 9pfs transport driver")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/9p/trans_xen.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/net/9p/trans_xen.c
++++ b/net/9p/trans_xen.c
+@@ -530,13 +530,19 @@ static struct xenbus_driver xen_9pfs_fro
+
+ static int p9_trans_xen_init(void)
+ {
++ int rc;
++
+ if (!xen_domain())
+ return -ENODEV;
+
+ pr_info("Initialising Xen transport for 9pfs\n");
+
+ v9fs_register_trans(&p9_xen_trans);
+- return xenbus_register_frontend(&xen_9pfs_front_driver);
++ rc = xenbus_register_frontend(&xen_9pfs_front_driver);
++ if (rc)
++ v9fs_unregister_trans(&p9_xen_trans);
++
++ return rc;
+ }
+ module_init(p9_trans_xen_init);
+
--- /dev/null
+From 179006688a7e888cbff39577189f2e034786d06a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 19 Jun 2019 13:05:50 +0100
+Subject: Btrfs: add missing inode version, ctime and mtime updates when punching hole
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 179006688a7e888cbff39577189f2e034786d06a upstream.
+
+If the range for which we are punching a hole covers only part of a page,
+we end up updating the inode item but we skip the update of the inode's
+iversion, mtime and ctime. Fix that by ensuring we update those properties
+of the inode.
+
+A patch for fstests test case generic/059 that tests this as been sent
+along with this fix.
+
+Fixes: 2aaa66558172b0 ("Btrfs: add hole punching")
+Fixes: e8c1c76e804b18 ("Btrfs: add missing inode update when punching hole")
+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/file.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/fs/btrfs/file.c
++++ b/fs/btrfs/file.c
+@@ -2784,6 +2784,11 @@ out_only_mutex:
+ * for detecting, at fsync time, if the inode isn't yet in the
+ * log tree or it's there but not up to date.
+ */
++ struct timespec64 now = current_time(inode);
++
++ inode_inc_iversion(inode);
++ inode->i_mtime = now;
++ inode->i_ctime = now;
+ trans = btrfs_start_transaction(root, 1);
+ if (IS_ERR(trans)) {
+ err = PTR_ERR(trans);
--- /dev/null
+From d1d832a0b51dd9570429bb4b81b2a6c1759e681a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Fri, 7 Jun 2019 11:25:24 +0100
+Subject: Btrfs: fix data loss after inode eviction, renaming it, and fsync it
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit d1d832a0b51dd9570429bb4b81b2a6c1759e681a upstream.
+
+When we log an inode, regardless of logging it completely or only that it
+exists, we always update it as logged (logged_trans and last_log_commit
+fields of the inode are updated). This is generally fine and avoids future
+attempts to log it from having to do repeated work that brings no value.
+
+However, if we write data to a file, then evict its inode after all the
+dealloc was flushed (and ordered extents completed), rename the file and
+fsync it, we end up not logging the new extents, since the rename may
+result in logging that the inode exists in case the parent directory was
+logged before. The following reproducer shows and explains how this can
+happen:
+
+ $ mkfs.btrfs -f /dev/sdb
+ $ mount /dev/sdb /mnt
+
+ $ mkdir /mnt/dir
+ $ touch /mnt/dir/foo
+ $ touch /mnt/dir/bar
+
+ # Do a direct IO write instead of a buffered write because with a
+ # buffered write we would need to make sure dealloc gets flushed and
+ # complete before we do the inode eviction later, and we can not do that
+ # from user space with call to things such as sync(2) since that results
+ # in a transaction commit as well.
+ $ xfs_io -d -c "pwrite -S 0xd3 0 4K" /mnt/dir/bar
+
+ # Keep the directory dir in use while we evict inodes. We want our file
+ # bar's inode to be evicted but we don't want our directory's inode to
+ # be evicted (if it were evicted too, we would not be able to reproduce
+ # the issue since the first fsync below, of file foo, would result in a
+ # transaction commit.
+ $ ( cd /mnt/dir; while true; do :; done ) &
+ $ pid=$!
+
+ # Wait a bit to give time for the background process to chdir.
+ $ sleep 0.1
+
+ # Evict all inodes, except the inode for the directory dir because it is
+ # currently in use by our background process.
+ $ echo 2 > /proc/sys/vm/drop_caches
+
+ # fsync file foo, which ends up persisting information about the parent
+ # directory because it is a new inode.
+ $ xfs_io -c fsync /mnt/dir/foo
+
+ # Rename bar, this results in logging that this inode exists (inode item,
+ # names, xattrs) because the parent directory is in the log.
+ $ mv /mnt/dir/bar /mnt/dir/baz
+
+ # Now fsync baz, which ends up doing absolutely nothing because of the
+ # rename operation which logged that the inode exists only.
+ $ xfs_io -c fsync /mnt/dir/baz
+
+ <power failure>
+
+ $ mount /dev/sdb /mnt
+ $ od -t x1 -A d /mnt/dir/baz
+ 0000000
+
+ --> Empty file, data we wrote is missing.
+
+Fix this by not updating last_sub_trans of an inode when we are logging
+only that it exists and the inode was not yet logged since it was loaded
+from disk (full_sync bit set), this is enough to make btrfs_inode_in_log()
+return false for this scenario and make us log the inode. The logged_trans
+of the inode is still always setsince that alone is used to track if names
+need to be deleted as part of unlink operations.
+
+Fixes: 257c62e1bce03e ("Btrfs: avoid tree log commit when there are no changes")
+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/tree-log.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -5266,9 +5266,19 @@ log_extents:
+ }
+ }
+
++ /*
++ * Don't update last_log_commit if we logged that an inode exists after
++ * it was loaded to memory (full_sync bit set).
++ * This is to prevent data loss when we do a write to the inode, then
++ * the inode gets evicted after all delalloc was flushed, then we log
++ * it exists (due to a rename for example) and then fsync it. This last
++ * fsync would do nothing (not logging the extents previously written).
++ */
+ spin_lock(&inode->lock);
+ inode->logged_trans = trans->transid;
+- inode->last_log_commit = inode->last_sub_trans;
++ if (inode_only != LOG_INODE_EXISTS ||
++ !test_bit(BTRFS_INODE_NEEDS_FULL_SYNC, &inode->runtime_flags))
++ inode->last_log_commit = inode->last_sub_trans;
+ spin_unlock(&inode->lock);
+ out_unlock:
+ if (unlikely(err))
--- /dev/null
+From 803f0f64d17769071d7287d9e3e3b79a3e1ae937 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 19 Jun 2019 13:05:39 +0100
+Subject: Btrfs: fix fsync not persisting dentry deletions due to inode evictions
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 803f0f64d17769071d7287d9e3e3b79a3e1ae937 upstream.
+
+In order to avoid searches on a log tree when unlinking an inode, we check
+if the inode being unlinked was logged in the current transaction, as well
+as the inode of its parent directory. When any of the inodes are logged,
+we proceed to delete directory items and inode reference items from the
+log, to ensure that if a subsequent fsync of only the inode being unlinked
+or only of the parent directory when the other is not fsync'ed as well,
+does not result in the entry still existing after a power failure.
+
+That check however is not reliable when one of the inodes involved (the
+one being unlinked or its parent directory's inode) is evicted, since the
+logged_trans field is transient, that is, it is not stored on disk, so it
+is lost when the inode is evicted and loaded into memory again (which is
+set to zero on load). As a consequence the checks currently being done by
+btrfs_del_dir_entries_in_log() and btrfs_del_inode_ref_in_log() always
+return true if the inode was evicted before, regardless of the inode
+having been logged or not before (and in the current transaction), this
+results in the dentry being unlinked still existing after a log replay
+if after the unlink operation only one of the inodes involved is fsync'ed.
+
+Example:
+
+ $ mkfs.btrfs -f /dev/sdb
+ $ mount /dev/sdb /mnt
+
+ $ mkdir /mnt/dir
+ $ touch /mnt/dir/foo
+ $ xfs_io -c fsync /mnt/dir/foo
+
+ # Keep an open file descriptor on our directory while we evict inodes.
+ # We just want to evict the file's inode, the directory's inode must not
+ # be evicted.
+ $ ( cd /mnt/dir; while true; do :; done ) &
+ $ pid=$!
+
+ # Wait a bit to give time to background process to chdir to our test
+ # directory.
+ $ sleep 0.5
+
+ # Trigger eviction of the file's inode.
+ $ echo 2 > /proc/sys/vm/drop_caches
+
+ # Unlink our file and fsync the parent directory. After a power failure
+ # we don't expect to see the file anymore, since we fsync'ed the parent
+ # directory.
+ $ rm -f $SCRATCH_MNT/dir/foo
+ $ xfs_io -c fsync /mnt/dir
+
+ <power failure>
+
+ $ mount /dev/sdb /mnt
+ $ ls /mnt/dir
+ foo
+ $
+ --> file still there, unlink not persisted despite explicit fsync on dir
+
+Fix this by checking if the inode has the full_sync bit set in its runtime
+flags as well, since that bit is set everytime an inode is loaded from
+disk, or for other less common cases such as after a shrinking truncate
+or failure to allocate extent maps for holes, and gets cleared after the
+first fsync. Also consider the inode as possibly logged only if it was
+last modified in the current transaction (besides having the full_fsync
+flag set).
+
+Fixes: 3a5f1d458ad161 ("Btrfs: Optimize btree walking while logging inodes")
+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/tree-log.c | 28 ++++++++++++++++++++++++++--
+ 1 file changed, 26 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -3153,6 +3153,30 @@ int btrfs_free_log_root_tree(struct btrf
+ }
+
+ /*
++ * Check if an inode was logged in the current transaction. We can't always rely
++ * on an inode's logged_trans value, because it's an in-memory only field and
++ * therefore not persisted. This means that its value is lost if the inode gets
++ * evicted and loaded again from disk (in which case it has a value of 0, and
++ * certainly it is smaller then any possible transaction ID), when that happens
++ * the full_sync flag is set in the inode's runtime flags, so on that case we
++ * assume eviction happened and ignore the logged_trans value, assuming the
++ * worst case, that the inode was logged before in the current transaction.
++ */
++static bool inode_logged(struct btrfs_trans_handle *trans,
++ struct btrfs_inode *inode)
++{
++ if (inode->logged_trans == trans->transid)
++ return true;
++
++ if (inode->last_trans == trans->transid &&
++ test_bit(BTRFS_INODE_NEEDS_FULL_SYNC, &inode->runtime_flags) &&
++ !test_bit(BTRFS_FS_LOG_RECOVERING, &trans->fs_info->flags))
++ return true;
++
++ return false;
++}
++
++/*
+ * If both a file and directory are logged, and unlinks or renames are
+ * mixed in, we have a few interesting corners:
+ *
+@@ -3186,7 +3210,7 @@ int btrfs_del_dir_entries_in_log(struct
+ int bytes_del = 0;
+ u64 dir_ino = btrfs_ino(dir);
+
+- if (dir->logged_trans < trans->transid)
++ if (!inode_logged(trans, dir))
+ return 0;
+
+ ret = join_running_log_trans(root);
+@@ -3291,7 +3315,7 @@ int btrfs_del_inode_ref_in_log(struct bt
+ u64 index;
+ int ret;
+
+- if (inode->logged_trans < trans->transid)
++ if (!inode_logged(trans, inode))
+ return 0;
+
+ ret = join_running_log_trans(root);
--- /dev/null
+From 7fa0a1da3dadfd9216df7745a1331fdaa0940d1c Mon Sep 17 00:00:00 2001
+From: Jan Harkes <jaharkes@cs.cmu.edu>
+Date: Tue, 16 Jul 2019 16:28:04 -0700
+Subject: coda: pass the host file in vma->vm_file on mmap
+
+From: Jan Harkes <jaharkes@cs.cmu.edu>
+
+commit 7fa0a1da3dadfd9216df7745a1331fdaa0940d1c upstream.
+
+Patch series "Coda updates".
+
+The following patch series is a collection of various fixes for Coda,
+most of which were collected from linux-fsdevel or linux-kernel but
+which have as yet not found their way upstream.
+
+This patch (of 22):
+
+Various file systems expect that vma->vm_file points at their own file
+handle, several use file_inode(vma->vm_file) to get at their inode or
+use vma->vm_file->private_data. However the way Coda wrapped mmap on a
+host file broke this assumption, vm_file was still pointing at the Coda
+file and the host file systems would scribble over Coda's inode and
+private file data.
+
+This patch fixes the incorrect expectation and wraps vm_ops->open and
+vm_ops->close to allow Coda to track when the vm_area_struct is
+destroyed so we still release the reference on the Coda file handle at
+the right time.
+
+Link: http://lkml.kernel.org/r/0e850c6e59c0b147dc2dcd51a3af004c948c3697.1558117389.git.jaharkes@cs.cmu.edu
+Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Colin Ian King <colin.king@canonical.com>
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: David Howells <dhowells@redhat.com>
+Cc: Fabian Frederick <fabf@skynet.be>
+Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
+Cc: Sam Protsenko <semen.protsenko@linaro.org>
+Cc: Yann Droneaud <ydroneaud@opteya.com>
+Cc: Zhouyang Jia <jiazhouyang09@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/coda/file.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
+ 1 file changed, 68 insertions(+), 2 deletions(-)
+
+--- a/fs/coda/file.c
++++ b/fs/coda/file.c
+@@ -27,6 +27,13 @@
+ #include "coda_linux.h"
+ #include "coda_int.h"
+
++struct coda_vm_ops {
++ atomic_t refcnt;
++ struct file *coda_file;
++ const struct vm_operations_struct *host_vm_ops;
++ struct vm_operations_struct vm_ops;
++};
++
+ static ssize_t
+ coda_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
+ {
+@@ -61,6 +68,34 @@ coda_file_write_iter(struct kiocb *iocb,
+ return ret;
+ }
+
++static void
++coda_vm_open(struct vm_area_struct *vma)
++{
++ struct coda_vm_ops *cvm_ops =
++ container_of(vma->vm_ops, struct coda_vm_ops, vm_ops);
++
++ atomic_inc(&cvm_ops->refcnt);
++
++ if (cvm_ops->host_vm_ops && cvm_ops->host_vm_ops->open)
++ cvm_ops->host_vm_ops->open(vma);
++}
++
++static void
++coda_vm_close(struct vm_area_struct *vma)
++{
++ struct coda_vm_ops *cvm_ops =
++ container_of(vma->vm_ops, struct coda_vm_ops, vm_ops);
++
++ if (cvm_ops->host_vm_ops && cvm_ops->host_vm_ops->close)
++ cvm_ops->host_vm_ops->close(vma);
++
++ if (atomic_dec_and_test(&cvm_ops->refcnt)) {
++ vma->vm_ops = cvm_ops->host_vm_ops;
++ fput(cvm_ops->coda_file);
++ kfree(cvm_ops);
++ }
++}
++
+ static int
+ coda_file_mmap(struct file *coda_file, struct vm_area_struct *vma)
+ {
+@@ -68,6 +103,8 @@ coda_file_mmap(struct file *coda_file, s
+ struct coda_inode_info *cii;
+ struct file *host_file;
+ struct inode *coda_inode, *host_inode;
++ struct coda_vm_ops *cvm_ops;
++ int ret;
+
+ cfi = CODA_FTOC(coda_file);
+ BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+@@ -76,6 +113,13 @@ coda_file_mmap(struct file *coda_file, s
+ if (!host_file->f_op->mmap)
+ return -ENODEV;
+
++ if (WARN_ON(coda_file != vma->vm_file))
++ return -EIO;
++
++ cvm_ops = kmalloc(sizeof(struct coda_vm_ops), GFP_KERNEL);
++ if (!cvm_ops)
++ return -ENOMEM;
++
+ coda_inode = file_inode(coda_file);
+ host_inode = file_inode(host_file);
+
+@@ -89,6 +133,7 @@ coda_file_mmap(struct file *coda_file, s
+ * the container file on us! */
+ else if (coda_inode->i_mapping != host_inode->i_mapping) {
+ spin_unlock(&cii->c_lock);
++ kfree(cvm_ops);
+ return -EBUSY;
+ }
+
+@@ -97,7 +142,29 @@ coda_file_mmap(struct file *coda_file, s
+ cfi->cfi_mapcount++;
+ spin_unlock(&cii->c_lock);
+
+- return call_mmap(host_file, vma);
++ vma->vm_file = get_file(host_file);
++ ret = call_mmap(vma->vm_file, vma);
++
++ if (ret) {
++ /* if call_mmap fails, our caller will put coda_file so we
++ * should drop the reference to the host_file that we got.
++ */
++ fput(host_file);
++ kfree(cvm_ops);
++ } else {
++ /* here we add redirects for the open/close vm_operations */
++ cvm_ops->host_vm_ops = vma->vm_ops;
++ if (vma->vm_ops)
++ cvm_ops->vm_ops = *vma->vm_ops;
++
++ cvm_ops->vm_ops.open = coda_vm_open;
++ cvm_ops->vm_ops.close = coda_vm_close;
++ cvm_ops->coda_file = coda_file;
++ atomic_set(&cvm_ops->refcnt, 1);
++
++ vma->vm_ops = &cvm_ops->vm_ops;
++ }
++ return ret;
+ }
+
+ int coda_open(struct inode *coda_inode, struct file *coda_file)
+@@ -207,4 +274,3 @@ const struct file_operations coda_file_o
+ .fsync = coda_fsync,
+ .splice_read = generic_file_splice_read,
+ };
+-
--- /dev/null
+From 3b8cafdd5436f9298b3bf6eb831df5eef5ee82b6 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@wdc.com>
+Date: Tue, 16 Jul 2019 14:39:34 +0900
+Subject: dm zoned: fix zone state management race
+
+From: Damien Le Moal <damien.lemoal@wdc.com>
+
+commit 3b8cafdd5436f9298b3bf6eb831df5eef5ee82b6 upstream.
+
+dm-zoned uses the zone flag DMZ_ACTIVE to indicate that a zone of the
+backend device is being actively read or written and so cannot be
+reclaimed. This flag is set as long as the zone atomic reference
+counter is not 0. When this atomic is decremented and reaches 0 (e.g.
+on BIO completion), the active flag is cleared and set again whenever
+the zone is reused and BIO issued with the atomic counter incremented.
+These 2 operations (atomic inc/dec and flag set/clear) are however not
+always executed atomically under the target metadata mutex lock and
+this causes the warning:
+
+WARN_ON(!test_bit(DMZ_ACTIVE, &zone->flags));
+
+in dmz_deactivate_zone() to be displayed. This problem is regularly
+triggered with xfstests generic/209, generic/300, generic/451 and
+xfs/077 with XFS being used as the file system on the dm-zoned target
+device. Similarly, xfstests ext4/303, ext4/304, generic/209 and
+generic/300 trigger the warning with ext4 use.
+
+This problem can be easily fixed by simply removing the DMZ_ACTIVE flag
+and managing the "ACTIVE" state by directly looking at the reference
+counter value. To do so, the functions dmz_activate_zone() and
+dmz_deactivate_zone() are changed to inline functions respectively
+calling atomic_inc() and atomic_dec(), while the dmz_is_active() macro
+is changed to an inline function calling atomic_read().
+
+Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
+Cc: stable@vger.kernel.org
+Reported-by: Masato Suzuki <masato.suzuki@wdc.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-zoned-metadata.c | 24 ------------------------
+ drivers/md/dm-zoned.h | 28 ++++++++++++++++++++++++----
+ 2 files changed, 24 insertions(+), 28 deletions(-)
+
+--- a/drivers/md/dm-zoned-metadata.c
++++ b/drivers/md/dm-zoned-metadata.c
+@@ -1594,30 +1594,6 @@ struct dm_zone *dmz_get_zone_for_reclaim
+ }
+
+ /*
+- * Activate a zone (increment its reference count).
+- */
+-void dmz_activate_zone(struct dm_zone *zone)
+-{
+- set_bit(DMZ_ACTIVE, &zone->flags);
+- atomic_inc(&zone->refcount);
+-}
+-
+-/*
+- * Deactivate a zone. This decrement the zone reference counter
+- * and clears the active state of the zone once the count reaches 0,
+- * indicating that all BIOs to the zone have completed. Returns
+- * true if the zone was deactivated.
+- */
+-void dmz_deactivate_zone(struct dm_zone *zone)
+-{
+- if (atomic_dec_and_test(&zone->refcount)) {
+- WARN_ON(!test_bit(DMZ_ACTIVE, &zone->flags));
+- clear_bit_unlock(DMZ_ACTIVE, &zone->flags);
+- smp_mb__after_atomic();
+- }
+-}
+-
+-/*
+ * Get the zone mapping a chunk, if the chunk is mapped already.
+ * If no mapping exist and the operation is WRITE, a zone is
+ * allocated and used to map the chunk.
+--- a/drivers/md/dm-zoned.h
++++ b/drivers/md/dm-zoned.h
+@@ -115,7 +115,6 @@ enum {
+ DMZ_BUF,
+
+ /* Zone internal state */
+- DMZ_ACTIVE,
+ DMZ_RECLAIM,
+ DMZ_SEQ_WRITE_ERR,
+ };
+@@ -128,7 +127,6 @@ enum {
+ #define dmz_is_empty(z) ((z)->wp_block == 0)
+ #define dmz_is_offline(z) test_bit(DMZ_OFFLINE, &(z)->flags)
+ #define dmz_is_readonly(z) test_bit(DMZ_READ_ONLY, &(z)->flags)
+-#define dmz_is_active(z) test_bit(DMZ_ACTIVE, &(z)->flags)
+ #define dmz_in_reclaim(z) test_bit(DMZ_RECLAIM, &(z)->flags)
+ #define dmz_seq_write_err(z) test_bit(DMZ_SEQ_WRITE_ERR, &(z)->flags)
+
+@@ -188,8 +186,30 @@ void dmz_unmap_zone(struct dmz_metadata
+ unsigned int dmz_nr_rnd_zones(struct dmz_metadata *zmd);
+ unsigned int dmz_nr_unmap_rnd_zones(struct dmz_metadata *zmd);
+
+-void dmz_activate_zone(struct dm_zone *zone);
+-void dmz_deactivate_zone(struct dm_zone *zone);
++/*
++ * Activate a zone (increment its reference count).
++ */
++static inline void dmz_activate_zone(struct dm_zone *zone)
++{
++ atomic_inc(&zone->refcount);
++}
++
++/*
++ * Deactivate a zone. This decrement the zone reference counter
++ * indicating that all BIOs to the zone have completed when the count is 0.
++ */
++static inline void dmz_deactivate_zone(struct dm_zone *zone)
++{
++ atomic_dec(&zone->refcount);
++}
++
++/*
++ * Test if a zone is active, that is, has a refcount > 0.
++ */
++static inline bool dmz_is_active(struct dm_zone *zone)
++{
++ return atomic_read(&zone->refcount);
++}
+
+ int dmz_lock_zone_reclaim(struct dm_zone *zone);
+ void dmz_unlock_zone_reclaim(struct dm_zone *zone);
--- /dev/null
+From 7cb95eeea6706c790571042a06782e378b2561ea Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Wed, 26 Jun 2019 14:10:27 -0400
+Subject: drm/nouveau/i2c: Enable i2c pads & busses during preinit
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 7cb95eeea6706c790571042a06782e378b2561ea upstream.
+
+It turns out that while disabling i2c bus access from software when the
+GPU is suspended was a step in the right direction with:
+
+commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
+->fini()")
+
+We also ended up accidentally breaking the vbios init scripts on some
+older Tesla GPUs, as apparently said scripts can actually use the i2c
+bus. Since these scripts are executed before initializing any
+subdevices, we end up failing to acquire access to the i2c bus which has
+left a number of cards with their fan controllers uninitialized. Luckily
+this doesn't break hardware - it just means the fan gets stuck at 100%.
+
+This also means that we've always been using our i2c busses before
+initializing them during the init scripts for older GPUs, we just didn't
+notice it until we started preventing them from being used until init.
+It's pretty impressive this never caused us any issues before!
+
+So, fix this by initializing our i2c pad and busses during subdev
+pre-init. We skip initializing aux busses during pre-init, as those are
+guaranteed to only ever be used by nouveau for DP aux transactions.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Tested-by: Marc Meledandri <m.meledandri@gmail.com>
+Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c
+@@ -185,6 +185,25 @@ nvkm_i2c_fini(struct nvkm_subdev *subdev
+ }
+
+ static int
++nvkm_i2c_preinit(struct nvkm_subdev *subdev)
++{
++ struct nvkm_i2c *i2c = nvkm_i2c(subdev);
++ struct nvkm_i2c_bus *bus;
++ struct nvkm_i2c_pad *pad;
++
++ /*
++ * We init our i2c busses as early as possible, since they may be
++ * needed by the vbios init scripts on some cards
++ */
++ list_for_each_entry(pad, &i2c->pad, head)
++ nvkm_i2c_pad_init(pad);
++ list_for_each_entry(bus, &i2c->bus, head)
++ nvkm_i2c_bus_init(bus);
++
++ return 0;
++}
++
++static int
+ nvkm_i2c_init(struct nvkm_subdev *subdev)
+ {
+ struct nvkm_i2c *i2c = nvkm_i2c(subdev);
+@@ -238,6 +257,7 @@ nvkm_i2c_dtor(struct nvkm_subdev *subdev
+ static const struct nvkm_subdev_func
+ nvkm_i2c = {
+ .dtor = nvkm_i2c_dtor,
++ .preinit = nvkm_i2c_preinit,
+ .init = nvkm_i2c_init,
+ .fini = nvkm_i2c_fini,
+ .intr = nvkm_i2c_intr,
--- /dev/null
+From 68c20cc2164cc5c7c73f8012ae6491afdb1f7f72 Mon Sep 17 00:00:00 2001
+From: Aaron Armstrong Skomra <skomra@gmail.com>
+Date: Fri, 10 May 2019 15:34:18 -0700
+Subject: HID: wacom: correct touch resolution x/y typo
+
+From: Aaron Armstrong Skomra <skomra@gmail.com>
+
+commit 68c20cc2164cc5c7c73f8012ae6491afdb1f7f72 upstream.
+
+This affects the 2nd-gen Intuos Pro Medium and Large
+when using their Bluetooth connection.
+
+Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
+Cc: <stable@vger.kernel.org> # v4.11+
+Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
+Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/wacom_wac.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hid/wacom_wac.c
++++ b/drivers/hid/wacom_wac.c
+@@ -3550,7 +3550,7 @@ int wacom_setup_touch_input_capabilities
+ 0, 5920, 4, 0);
+ }
+ input_abs_set_res(input_dev, ABS_MT_POSITION_X, 40);
+- input_abs_set_res(input_dev, ABS_MT_POSITION_X, 40);
++ input_abs_set_res(input_dev, ABS_MT_POSITION_Y, 40);
+
+ /* fall through */
+
--- /dev/null
+From d8e9806005f28bbb49899dab2068e3359e22ba35 Mon Sep 17 00:00:00 2001
+From: Aaron Armstrong Skomra <skomra@gmail.com>
+Date: Fri, 10 May 2019 15:31:16 -0700
+Subject: HID: wacom: generic: only switch the mode on devices with LEDs
+
+From: Aaron Armstrong Skomra <skomra@gmail.com>
+
+commit d8e9806005f28bbb49899dab2068e3359e22ba35 upstream.
+
+Currently, the driver will attempt to set the mode on all
+devices with a center button, but some devices with a center
+button lack LEDs, and attempting to set the LEDs on devices
+without LEDs results in the kernel error message of the form:
+
+"leds input8::wacom-0.1: Setting an LED's brightness failed (-32)"
+
+This is because the generic codepath erroneously assumes that the
+BUTTON_CENTER usage indicates that the device has LEDs, the
+previously ignored TOUCH_RING_SETTING usage is a more accurate
+indication of the existence of LEDs on the device.
+
+Fixes: 10c55cacb8b2 ("HID: wacom: generic: support LEDs")
+Cc: <stable@vger.kernel.org> # v4.11+
+Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
+Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/wacom_sys.c | 3 +++
+ drivers/hid/wacom_wac.c | 2 --
+ drivers/hid/wacom_wac.h | 1 +
+ 3 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/hid/wacom_sys.c
++++ b/drivers/hid/wacom_sys.c
+@@ -118,6 +118,9 @@ static void wacom_feature_mapping(struct
+ u32 n;
+
+ switch (equivalent_usage) {
++ case WACOM_HID_WD_TOUCH_RING_SETTING:
++ wacom->generic_has_leds = true;
++ break;
+ case HID_DG_CONTACTMAX:
+ /* leave touch_max as is if predefined */
+ if (!features->touch_max) {
+--- a/drivers/hid/wacom_wac.c
++++ b/drivers/hid/wacom_wac.c
+@@ -1871,8 +1871,6 @@ static void wacom_wac_pad_usage_mapping(
+ features->device_type |= WACOM_DEVICETYPE_PAD;
+ break;
+ case WACOM_HID_WD_BUTTONCENTER:
+- wacom->generic_has_leds = true;
+- /* fall through */
+ case WACOM_HID_WD_BUTTONHOME:
+ case WACOM_HID_WD_BUTTONUP:
+ case WACOM_HID_WD_BUTTONDOWN:
+--- a/drivers/hid/wacom_wac.h
++++ b/drivers/hid/wacom_wac.h
+@@ -140,6 +140,7 @@
+ #define WACOM_HID_WD_OFFSETBOTTOM (WACOM_HID_UP_WACOMDIGITIZER | 0x0d33)
+ #define WACOM_HID_WD_DATAMODE (WACOM_HID_UP_WACOMDIGITIZER | 0x1002)
+ #define WACOM_HID_WD_DIGITIZERINFO (WACOM_HID_UP_WACOMDIGITIZER | 0x1013)
++#define WACOM_HID_WD_TOUCH_RING_SETTING (WACOM_HID_UP_WACOMDIGITIZER | 0x1032)
+ #define WACOM_HID_UP_G9 0xff090000
+ #define WACOM_HID_G9_PEN (WACOM_HID_UP_G9 | 0x02)
+ #define WACOM_HID_G9_TOUCHSCREEN (WACOM_HID_UP_G9 | 0x11)
--- /dev/null
+From 4aa5aed2b6f267592705a526f57518a5d715b769 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Fri, 21 Jun 2019 19:19:30 +0300
+Subject: intel_th: pci: Add Ice Lake NNPI support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 4aa5aed2b6f267592705a526f57518a5d715b769 upstream.
+
+This adds Ice Lake NNPI support to the Intel(R) Trace Hub.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20190621161930.60785-5-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -178,6 +178,11 @@ static const struct pci_device_id intel_
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x02a6),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
++ {
++ /* Ice Lake NNPI */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x45c5),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
+ { 0 },
+ };
+
--- /dev/null
+From 7e3e888dfc138089f4c15a81b418e88f0978f744 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Thu, 18 Jul 2019 15:58:36 -0700
+Subject: libnvdimm/pfn: fix fsdax-mode namespace info-block zero-fields
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit 7e3e888dfc138089f4c15a81b418e88f0978f744 upstream.
+
+At namespace creation time there is the potential for the "expected to
+be zero" fields of a 'pfn' info-block to be filled with indeterminate
+data. While the kernel buffer is zeroed on allocation it is immediately
+overwritten by nd_pfn_validate() filling it with the current contents of
+the on-media info-block location. For fields like, 'flags' and the
+'padding' it potentially means that future implementations can not rely on
+those fields being zero.
+
+In preparation to stop using the 'start_pad' and 'end_trunc' fields for
+section alignment, arrange for fields that are not explicitly
+initialized to be guaranteed zero. Bump the minor version to indicate
+it is safe to assume the 'padding' and 'flags' are zero. Otherwise,
+this corruption is expected to benign since all other critical fields
+are explicitly initialized.
+
+Note The cc: stable is about spreading this new policy to as many
+kernels as possible not fixing an issue in those kernels. It is not
+until the change titled "libnvdimm/pfn: Stop padding pmem namespaces to
+section alignment" where this improper initialization becomes a problem.
+So if someone decides to backport "libnvdimm/pfn: Stop padding pmem
+namespaces to section alignment" (which is not tagged for stable), make
+sure this pre-requisite is flagged.
+
+Link: http://lkml.kernel.org/r/156092356065.979959.6681003754765958296.stgit@dwillia2-desk3.amr.corp.intel.com
+Fixes: 32ab0a3f5170 ("libnvdimm, pmem: 'struct page' for pmem")
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [ppc64]
+Cc: <stable@vger.kernel.org>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Jane Chu <jane.chu@oracle.com>
+Cc: Jeff Moyer <jmoyer@redhat.com>
+Cc: Jérôme Glisse <jglisse@redhat.com>
+Cc: Jonathan Corbet <corbet@lwn.net>
+Cc: Logan Gunthorpe <logang@deltatee.com>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Mike Rapoport <rppt@linux.ibm.com>
+Cc: Oscar Salvador <osalvador@suse.de>
+Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
+Cc: Toshi Kani <toshi.kani@hpe.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Wei Yang <richardw.yang@linux.intel.com>
+Cc: Jason Gunthorpe <jgg@mellanox.com>
+Cc: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/nvdimm/dax_devs.c | 2 +-
+ drivers/nvdimm/pfn.h | 1 +
+ drivers/nvdimm/pfn_devs.c | 18 +++++++++++++++---
+ 3 files changed, 17 insertions(+), 4 deletions(-)
+
+--- a/drivers/nvdimm/dax_devs.c
++++ b/drivers/nvdimm/dax_devs.c
+@@ -126,7 +126,7 @@ int nd_dax_probe(struct device *dev, str
+ nvdimm_bus_unlock(&ndns->dev);
+ if (!dax_dev)
+ return -ENOMEM;
+- pfn_sb = devm_kzalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
++ pfn_sb = devm_kmalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
+ nd_pfn->pfn_sb = pfn_sb;
+ rc = nd_pfn_validate(nd_pfn, DAX_SIG);
+ dev_dbg(dev, "%s: dax: %s\n", __func__,
+--- a/drivers/nvdimm/pfn.h
++++ b/drivers/nvdimm/pfn.h
+@@ -36,6 +36,7 @@ struct nd_pfn_sb {
+ __le32 end_trunc;
+ /* minor-version-2 record the base alignment of the mapping */
+ __le32 align;
++ /* minor-version-3 guarantee the padding and flags are zero */
+ u8 padding[4000];
+ __le64 checksum;
+ };
+--- a/drivers/nvdimm/pfn_devs.c
++++ b/drivers/nvdimm/pfn_devs.c
+@@ -361,6 +361,15 @@ struct device *nd_pfn_create(struct nd_r
+ return dev;
+ }
+
++/**
++ * nd_pfn_validate - read and validate info-block
++ * @nd_pfn: fsdax namespace runtime state / properties
++ * @sig: 'devdax' or 'fsdax' signature
++ *
++ * Upon return the info-block buffer contents (->pfn_sb) are
++ * indeterminate when validation fails, and a coherent info-block
++ * otherwise.
++ */
+ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
+ {
+ u64 checksum, offset;
+@@ -506,7 +515,7 @@ int nd_pfn_probe(struct device *dev, str
+ nvdimm_bus_unlock(&ndns->dev);
+ if (!pfn_dev)
+ return -ENOMEM;
+- pfn_sb = devm_kzalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
++ pfn_sb = devm_kmalloc(dev, sizeof(*pfn_sb), GFP_KERNEL);
+ nd_pfn = to_nd_pfn(pfn_dev);
+ nd_pfn->pfn_sb = pfn_sb;
+ rc = nd_pfn_validate(nd_pfn, PFN_SIG);
+@@ -637,7 +646,7 @@ static int nd_pfn_init(struct nd_pfn *nd
+ u64 checksum;
+ int rc;
+
+- pfn_sb = devm_kzalloc(&nd_pfn->dev, sizeof(*pfn_sb), GFP_KERNEL);
++ pfn_sb = devm_kmalloc(&nd_pfn->dev, sizeof(*pfn_sb), GFP_KERNEL);
+ if (!pfn_sb)
+ return -ENOMEM;
+
+@@ -646,11 +655,14 @@ static int nd_pfn_init(struct nd_pfn *nd
+ sig = DAX_SIG;
+ else
+ sig = PFN_SIG;
++
+ rc = nd_pfn_validate(nd_pfn, sig);
+ if (rc != -ENODEV)
+ return rc;
+
+ /* no info block, do init */;
++ memset(pfn_sb, 0, sizeof(*pfn_sb));
++
+ nd_region = to_nd_region(nd_pfn->dev.parent);
+ if (nd_region->ro) {
+ dev_info(&nd_pfn->dev,
+@@ -704,7 +716,7 @@ static int nd_pfn_init(struct nd_pfn *nd
+ memcpy(pfn_sb->uuid, nd_pfn->uuid, 16);
+ memcpy(pfn_sb->parent_uuid, nd_dev_to_uuid(&ndns->dev), 16);
+ pfn_sb->version_major = cpu_to_le16(1);
+- pfn_sb->version_minor = cpu_to_le16(2);
++ pfn_sb->version_minor = cpu_to_le16(3);
+ pfn_sb->start_pad = cpu_to_le32(start_pad);
+ pfn_sb->end_trunc = cpu_to_le32(end_trunc);
+ pfn_sb->align = cpu_to_le32(nd_pfn->align);
--- /dev/null
+From cf144f81a99d1a3928f90b0936accfd3f45c9a0a Mon Sep 17 00:00:00 2001
+From: Daniel Jordan <daniel.m.jordan@oracle.com>
+Date: Tue, 16 Jul 2019 12:32:53 -0400
+Subject: padata: use smp_mb in padata_reorder to avoid orphaned padata jobs
+
+From: Daniel Jordan <daniel.m.jordan@oracle.com>
+
+commit cf144f81a99d1a3928f90b0936accfd3f45c9a0a upstream.
+
+Testing padata with the tcrypt module on a 5.2 kernel...
+
+ # modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
+ # modprobe tcrypt mode=211 sec=1
+
+...produces this splat:
+
+ INFO: task modprobe:10075 blocked for more than 120 seconds.
+ Not tainted 5.2.0-base+ #16
+ modprobe D 0 10075 10064 0x80004080
+ Call Trace:
+ ? __schedule+0x4dd/0x610
+ ? ring_buffer_unlock_commit+0x23/0x100
+ schedule+0x6c/0x90
+ schedule_timeout+0x3b/0x320
+ ? trace_buffer_unlock_commit_regs+0x4f/0x1f0
+ wait_for_common+0x160/0x1a0
+ ? wake_up_q+0x80/0x80
+ { crypto_wait_req } # entries in braces added by hand
+ { do_one_aead_op }
+ { test_aead_jiffies }
+ test_aead_speed.constprop.17+0x681/0xf30 [tcrypt]
+ do_test+0x4053/0x6a2b [tcrypt]
+ ? 0xffffffffa00f4000
+ tcrypt_mod_init+0x50/0x1000 [tcrypt]
+ ...
+
+The second modprobe command never finishes because in padata_reorder,
+CPU0's load of reorder_objects is executed before the unlocking store in
+spin_unlock_bh(pd->lock), causing CPU0 to miss CPU1's increment:
+
+CPU0 CPU1
+
+padata_reorder padata_do_serial
+ LOAD reorder_objects // 0
+ INC reorder_objects // 1
+ padata_reorder
+ TRYLOCK pd->lock // failed
+ UNLOCK pd->lock
+
+CPU0 deletes the timer before returning from padata_reorder and since no
+other job is submitted to padata, modprobe waits indefinitely.
+
+Add a pair of full barriers to guarantee proper ordering:
+
+CPU0 CPU1
+
+padata_reorder padata_do_serial
+ UNLOCK pd->lock
+ smp_mb()
+ LOAD reorder_objects
+ INC reorder_objects
+ smp_mb__after_atomic()
+ padata_reorder
+ TRYLOCK pd->lock
+
+smp_mb__after_atomic is needed so the read part of the trylock operation
+comes after the INC, as Andrea points out. Thanks also to Andrea for
+help with writing a litmus test.
+
+Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface")
+Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
+Cc: <stable@vger.kernel.org>
+Cc: Andrea Parri <andrea.parri@amarulasolutions.com>
+Cc: Boqun Feng <boqun.feng@gmail.com>
+Cc: Herbert Xu <herbert@gondor.apana.org.au>
+Cc: Paul E. McKenney <paulmck@linux.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Steffen Klassert <steffen.klassert@secunet.com>
+Cc: linux-arch@vger.kernel.org
+Cc: linux-crypto@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/padata.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/kernel/padata.c
++++ b/kernel/padata.c
+@@ -265,7 +265,12 @@ static void padata_reorder(struct parall
+ * The next object that needs serialization might have arrived to
+ * the reorder queues in the meantime, we will be called again
+ * from the timer function if no one else cares for it.
++ *
++ * Ensure reorder_objects is read after pd->lock is dropped so we see
++ * an increment from another task in padata_do_serial. Pairs with
++ * smp_mb__after_atomic in padata_do_serial.
+ */
++ smp_mb();
+ if (atomic_read(&pd->reorder_objects)
+ && !(pinst->flags & PADATA_RESET))
+ mod_timer(&pd->timer, jiffies + HZ);
+@@ -334,6 +339,13 @@ void padata_do_serial(struct padata_priv
+ list_add_tail(&padata->list, &pqueue->reorder.list);
+ spin_unlock(&pqueue->reorder.lock);
+
++ /*
++ * Ensure the atomic_inc of reorder_objects above is ordered correctly
++ * with the trylock of pd->lock in padata_reorder. Pairs with smp_mb
++ * in padata_reorder.
++ */
++ smp_mb__after_atomic();
++
+ put_cpu();
+
+ padata_reorder(pd);
--- /dev/null
+From 000dd5316e1c756a1c028f22e01d06a38249dd4d Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Wed, 12 Jun 2019 13:57:39 +0300
+Subject: PCI: Do not poll for PME if the device is in D3cold
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit 000dd5316e1c756a1c028f22e01d06a38249dd4d upstream.
+
+PME polling does not take into account that a device that is directly
+connected to the host bridge may go into D3cold as well. This leads to a
+situation where the PME poll thread reads from a config space of a
+device that is in D3cold and gets incorrect information because the
+config space is not accessible.
+
+Here is an example from Intel Ice Lake system where two PCIe root ports
+are in D3cold (I've instrumented the kernel to log the PMCSR register
+contents):
+
+ [ 62.971442] pcieport 0000:00:07.1: Check PME status, PMCSR=0xffff
+ [ 62.971504] pcieport 0000:00:07.0: Check PME status, PMCSR=0xffff
+
+Since 0xffff is interpreted so that PME is pending, the root ports will
+be runtime resumed. This repeats over and over again essentially
+blocking all runtime power management.
+
+Prevent this from happening by checking whether the device is in D3cold
+before its PME status is read.
+
+Fixes: 71a83bd727cc ("PCI/PM: add runtime PM support to PCIe port")
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Cc: 3.6+ <stable@vger.kernel.org> # v3.6+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pci.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -1786,6 +1786,13 @@ static void pci_pme_list_scan(struct wor
+ */
+ if (bridge && bridge->current_state != PCI_D0)
+ continue;
++ /*
++ * If the device is in D3cold it should not be
++ * polled either.
++ */
++ if (pme_dev->dev->current_state == PCI_D3cold)
++ continue;
++
+ pci_pme_wakeup(pme_dev->dev, NULL);
+ } else {
+ list_del(&pme_dev->list);
--- /dev/null
+From 16f4641166b10e199f0d7b68c2c5f004fef0bda3 Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+Date: Fri, 28 Jun 2019 21:59:20 +0000
+Subject: perf/x86/amd/uncore: Do not set 'ThreadMask' and 'SliceMask' for non-L3 PMCs
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+commit 16f4641166b10e199f0d7b68c2c5f004fef0bda3 upstream.
+
+The following commit:
+
+ d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 Cache perf events")
+
+enables L3 PMC events for all threads and slices by writing 1's in
+'ChL3PmcCfg' (L3 PMC PERF_CTL) register fields.
+
+Those bitfields overlap with high order event select bits in the Data
+Fabric PMC control register, however.
+
+So when a user requests raw Data Fabric events (-e amd_df/event=0xYYY/),
+the two highest order bits get inadvertently set, changing the counter
+select to events that don't exist, and for which no counts are read.
+
+This patch changes the logic to write the L3 masks only when dealing
+with L3 PMC counters.
+
+AMD Family 16h and below Northbridge (NB) counters were not affected.
+
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: <stable@vger.kernel.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Gary Hook <Gary.Hook@amd.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Martin Liska <mliska@suse.cz>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Pu Wen <puwen@hygon.cn>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Fixes: d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 Cache perf events")
+Link: https://lkml.kernel.org/r/20190628215906.4276-1-kim.phillips@amd.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/amd/uncore.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/events/amd/uncore.c
++++ b/arch/x86/events/amd/uncore.c
+@@ -213,7 +213,7 @@ static int amd_uncore_event_init(struct
+ * SliceMask and ThreadMask need to be set for certain L3 events in
+ * Family 17h. For other events, the two fields do not affect the count.
+ */
+- if (l3_mask)
++ if (l3_mask && is_llc_event(event))
+ hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK);
+
+ if (event->cpu < 0)
--- /dev/null
+From 2f217d58a8a086d3399fecce39fb358848e799c4 Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+Date: Fri, 28 Jun 2019 21:59:33 +0000
+Subject: perf/x86/amd/uncore: Set the thread mask for F17h L3 PMCs
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+commit 2f217d58a8a086d3399fecce39fb358848e799c4 upstream.
+
+Fill in the L3 performance event select register ThreadMask
+bitfield, to enable per hardware thread accounting.
+
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: <stable@vger.kernel.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Gary Hook <Gary.Hook@amd.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Martin Liska <mliska@suse.cz>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Pu Wen <puwen@hygon.cn>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Link: https://lkml.kernel.org/r/20190628215906.4276-2-kim.phillips@amd.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/amd/uncore.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/events/amd/uncore.c
++++ b/arch/x86/events/amd/uncore.c
+@@ -209,15 +209,22 @@ static int amd_uncore_event_init(struct
+ hwc->config = event->attr.config & AMD64_RAW_EVENT_MASK_NB;
+ hwc->idx = -1;
+
++ if (event->cpu < 0)
++ return -EINVAL;
++
+ /*
+ * SliceMask and ThreadMask need to be set for certain L3 events in
+ * Family 17h. For other events, the two fields do not affect the count.
+ */
+- if (l3_mask && is_llc_event(event))
+- hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK);
++ if (l3_mask && is_llc_event(event)) {
++ int thread = 2 * (cpu_data(event->cpu).cpu_core_id % 4);
+
+- if (event->cpu < 0)
+- return -EINVAL;
++ if (smp_num_siblings > 1)
++ thread += cpu_data(event->cpu).apicid & 1;
++
++ hwc->config |= (1ULL << (AMD64_L3_THREAD_SHIFT + thread) &
++ AMD64_L3_THREAD_MASK) | AMD64_L3_SLICE_MASK;
++ }
+
+ uncore = event_to_amd_uncore(event);
+ if (!uncore)
kvm-x86-vpmu-refine-kvm_pmu-err-msg-when-event-creation-failed.patch
arm64-tegra-fix-agic-register-range.patch
fs-proc-proc_sysctl.c-fix-the-default-values-of-i_uid-i_gid-on-proc-sys-inodes.patch
+drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch
+padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch
+dm-zoned-fix-zone-state-management-race.patch
+xen-events-fix-binding-user-event-channels-to-cpus.patch
+9p-xen-add-cleanup-path-in-p9_trans_xen_init.patch
+9p-virtio-add-cleanup-path-in-p9_virtio_init.patch
+x86-boot-fix-memory-leak-in-default_get_smp_config.patch
+perf-x86-amd-uncore-do-not-set-threadmask-and-slicemask-for-non-l3-pmcs.patch
+perf-x86-amd-uncore-set-the-thread-mask-for-f17h-l3-pmcs.patch
+intel_th-pci-add-ice-lake-nnpi-support.patch
+pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch
+btrfs-fix-data-loss-after-inode-eviction-renaming-it-and-fsync-it.patch
+btrfs-fix-fsync-not-persisting-dentry-deletions-due-to-inode-evictions.patch
+btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch
+hid-wacom-generic-only-switch-the-mode-on-devices-with-leds.patch
+hid-wacom-correct-touch-resolution-x-y-typo.patch
+libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
+coda-pass-the-host-file-in-vma-vm_file-on-mmap.patch
--- /dev/null
+From e74bd96989dd42a51a73eddb4a5510a6f5e42ac3 Mon Sep 17 00:00:00 2001
+From: David Rientjes <rientjes@google.com>
+Date: Tue, 9 Jul 2019 19:44:03 -0700
+Subject: x86/boot: Fix memory leak in default_get_smp_config()
+
+From: David Rientjes <rientjes@google.com>
+
+commit e74bd96989dd42a51a73eddb4a5510a6f5e42ac3 upstream.
+
+When default_get_smp_config() is called with early == 1 and mpf->feature1
+is non-zero, mpf is leaked because the return path does not do
+early_memunmap().
+
+Fix this and share a common exit routine.
+
+Fixes: 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
+Reported-by: Cfir Cohen <cfir@google.com>
+Signed-off-by: David Rientjes <rientjes@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907091942570.28240@chino.kir.corp.google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/mpparse.c | 10 ++++------
+ 1 file changed, 4 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kernel/mpparse.c
++++ b/arch/x86/kernel/mpparse.c
+@@ -544,17 +544,15 @@ void __init default_get_smp_config(unsig
+ * local APIC has default address
+ */
+ mp_lapic_addr = APIC_DEFAULT_PHYS_BASE;
+- return;
++ goto out;
+ }
+
+ pr_info("Default MP configuration #%d\n", mpf->feature1);
+ construct_default_ISA_mptable(mpf->feature1);
+
+ } else if (mpf->physptr) {
+- if (check_physptr(mpf, early)) {
+- early_memunmap(mpf, sizeof(*mpf));
+- return;
+- }
++ if (check_physptr(mpf, early))
++ goto out;
+ } else
+ BUG();
+
+@@ -563,7 +561,7 @@ void __init default_get_smp_config(unsig
+ /*
+ * Only use the first configuration found.
+ */
+-
++out:
+ early_memunmap(mpf, sizeof(*mpf));
+ }
+
--- /dev/null
+From bce5963bcb4f9934faa52be323994511d59fd13c Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Fri, 21 Jun 2019 20:47:03 +0200
+Subject: xen/events: fix binding user event channels to cpus
+
+From: Juergen Gross <jgross@suse.com>
+
+commit bce5963bcb4f9934faa52be323994511d59fd13c upstream.
+
+When binding an interdomain event channel to a vcpu via
+IOCTL_EVTCHN_BIND_INTERDOMAIN not only the event channel needs to be
+bound, but the affinity of the associated IRQi must be changed, too.
+Otherwise the IRQ and the event channel won't be moved to another vcpu
+in case the original vcpu they were bound to is going offline.
+
+Cc: <stable@vger.kernel.org> # 4.13
+Fixes: c48f64ab472389df ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU")
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/events/events_base.c | 12 ++++++++++--
+ drivers/xen/evtchn.c | 2 +-
+ include/xen/events.h | 3 ++-
+ 3 files changed, 13 insertions(+), 4 deletions(-)
+
+--- a/drivers/xen/events/events_base.c
++++ b/drivers/xen/events/events_base.c
+@@ -1293,7 +1293,7 @@ void rebind_evtchn_irq(int evtchn, int i
+ }
+
+ /* Rebind an evtchn so that it gets delivered to a specific cpu */
+-int xen_rebind_evtchn_to_cpu(int evtchn, unsigned tcpu)
++static int xen_rebind_evtchn_to_cpu(int evtchn, unsigned int tcpu)
+ {
+ struct evtchn_bind_vcpu bind_vcpu;
+ int masked;
+@@ -1327,7 +1327,6 @@ int xen_rebind_evtchn_to_cpu(int evtchn,
+
+ return 0;
+ }
+-EXPORT_SYMBOL_GPL(xen_rebind_evtchn_to_cpu);
+
+ static int set_affinity_irq(struct irq_data *data, const struct cpumask *dest,
+ bool force)
+@@ -1341,6 +1340,15 @@ static int set_affinity_irq(struct irq_d
+ return ret;
+ }
+
++/* To be called with desc->lock held. */
++int xen_set_affinity_evtchn(struct irq_desc *desc, unsigned int tcpu)
++{
++ struct irq_data *d = irq_desc_get_irq_data(desc);
++
++ return set_affinity_irq(d, cpumask_of(tcpu), false);
++}
++EXPORT_SYMBOL_GPL(xen_set_affinity_evtchn);
++
+ static void enable_dynirq(struct irq_data *data)
+ {
+ int evtchn = evtchn_from_irq(data->irq);
+--- a/drivers/xen/evtchn.c
++++ b/drivers/xen/evtchn.c
+@@ -447,7 +447,7 @@ static void evtchn_bind_interdom_next_vc
+ this_cpu_write(bind_last_selected_cpu, selected_cpu);
+
+ /* unmask expects irqs to be disabled */
+- xen_rebind_evtchn_to_cpu(evtchn, selected_cpu);
++ xen_set_affinity_evtchn(desc, selected_cpu);
+ raw_spin_unlock_irqrestore(&desc->lock, flags);
+ }
+
+--- a/include/xen/events.h
++++ b/include/xen/events.h
+@@ -3,6 +3,7 @@
+ #define _XEN_EVENTS_H
+
+ #include <linux/interrupt.h>
++#include <linux/irq.h>
+ #ifdef CONFIG_PCI_MSI
+ #include <linux/msi.h>
+ #endif
+@@ -59,7 +60,7 @@ void evtchn_put(unsigned int evtchn);
+
+ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector);
+ void rebind_evtchn_irq(int evtchn, int irq);
+-int xen_rebind_evtchn_to_cpu(int evtchn, unsigned tcpu);
++int xen_set_affinity_evtchn(struct irq_desc *desc, unsigned int tcpu);
+
+ static inline void notify_remote_via_evtchn(int port)
+ {
projects / thirdparty / kernel / stable-queue.git / commitdiff
