From: Greg Kroah-Hartman Date: Tue, 23 Jul 2019 12:11:51 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v5.2.3~29 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6f3cfaff3ff6d555fe76ec59b43db6ccaa091ce6;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: 9p-virtio-add-cleanup-path-in-p9_virtio_init.patch 9p-xen-add-cleanup-path-in-p9_trans_xen_init.patch btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.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 coda-pass-the-host-file-in-vma-vm_file-on-mmap.patch dm-zoned-fix-zone-state-management-race.patch drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch hid-wacom-correct-touch-resolution-x-y-typo.patch hid-wacom-generic-only-switch-the-mode-on-devices-with-leds.patch intel_th-pci-add-ice-lake-nnpi-support.patch libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.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 x86-boot-fix-memory-leak-in-default_get_smp_config.patch xen-events-fix-binding-user-event-channels-to-cpus.patch --- diff --git a/queue-4.14/9p-virtio-add-cleanup-path-in-p9_virtio_init.patch b/queue-4.14/9p-virtio-add-cleanup-path-in-p9_virtio_init.patch new file mode 100644 index 00000000000..917eb668dc7 --- /dev/null +++ b/queue-4.14/9p-virtio-add-cleanup-path-in-p9_virtio_init.patch @@ -0,0 +1,89 @@ +From d4548543fc4ece56c6f04b8586f435fb4fd84c20 Mon Sep 17 00:00:00 2001 +From: YueHaibing +Date: Tue, 30 Apr 2019 19:59:42 +0800 +Subject: 9p/virtio: Add cleanup path in p9_virtio_init + +From: YueHaibing + +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 +Fixes: b530cc794024 ("9p: add virtio transport") +Signed-off-by: YueHaibing +Signed-off-by: Dominique Martinet +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.14/9p-xen-add-cleanup-path-in-p9_trans_xen_init.patch b/queue-4.14/9p-xen-add-cleanup-path-in-p9_trans_xen_init.patch new file mode 100644 index 00000000000..7c7941220c6 --- /dev/null +++ b/queue-4.14/9p-xen-add-cleanup-path-in-p9_trans_xen_init.patch @@ -0,0 +1,46 @@ +From 80a316ff16276b36d0392a8f8b2f63259857ae98 Mon Sep 17 00:00:00 2001 +From: YueHaibing +Date: Tue, 30 Apr 2019 22:39:33 +0800 +Subject: 9p/xen: Add cleanup path in p9_trans_xen_init + +From: YueHaibing + +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 +Signed-off-by: Dominique Martinet +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.14/btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch b/queue-4.14/btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch new file mode 100644 index 00000000000..12124875f2e --- /dev/null +++ b/queue-4.14/btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch @@ -0,0 +1,42 @@ +From 179006688a7e888cbff39577189f2e034786d06a Mon Sep 17 00:00:00 2001 +From: Filipe Manana +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 + +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 +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/btrfs-fix-data-loss-after-inode-eviction-renaming-it-and-fsync-it.patch b/queue-4.14/btrfs-fix-data-loss-after-inode-eviction-renaming-it-and-fsync-it.patch new file mode 100644 index 00000000000..0d6054da94b --- /dev/null +++ b/queue-4.14/btrfs-fix-data-loss-after-inode-eviction-renaming-it-and-fsync-it.patch @@ -0,0 +1,110 @@ +From d1d832a0b51dd9570429bb4b81b2a6c1759e681a Mon Sep 17 00:00:00 2001 +From: Filipe Manana +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 + +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 + + + + $ 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 +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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)) diff --git a/queue-4.14/btrfs-fix-fsync-not-persisting-dentry-deletions-due-to-inode-evictions.patch b/queue-4.14/btrfs-fix-fsync-not-persisting-dentry-deletions-due-to-inode-evictions.patch new file mode 100644 index 00000000000..ffca77bdf42 --- /dev/null +++ b/queue-4.14/btrfs-fix-fsync-not-persisting-dentry-deletions-due-to-inode-evictions.patch @@ -0,0 +1,133 @@ +From 803f0f64d17769071d7287d9e3e3b79a3e1ae937 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 19 Jun 2019 13:05:39 +0100 +Subject: Btrfs: fix fsync not persisting dentry deletions due to inode evictions + +From: Filipe Manana + +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 + + + + $ 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 +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/coda-pass-the-host-file-in-vma-vm_file-on-mmap.patch b/queue-4.14/coda-pass-the-host-file-in-vma-vm_file-on-mmap.patch new file mode 100644 index 00000000000..0fb8831c5e3 --- /dev/null +++ b/queue-4.14/coda-pass-the-host-file-in-vma-vm_file-on-mmap.patch @@ -0,0 +1,167 @@ +From 7fa0a1da3dadfd9216df7745a1331fdaa0940d1c Mon Sep 17 00:00:00 2001 +From: Jan Harkes +Date: Tue, 16 Jul 2019 16:28:04 -0700 +Subject: coda: pass the host file in vma->vm_file on mmap + +From: Jan Harkes + +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 +Cc: Arnd Bergmann +Cc: Colin Ian King +Cc: Dan Carpenter +Cc: David Howells +Cc: Fabian Frederick +Cc: Mikko Rapeli +Cc: Sam Protsenko +Cc: Yann Droneaud +Cc: Zhouyang Jia +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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, + }; +- diff --git a/queue-4.14/dm-zoned-fix-zone-state-management-race.patch b/queue-4.14/dm-zoned-fix-zone-state-management-race.patch new file mode 100644 index 00000000000..afd3499b944 --- /dev/null +++ b/queue-4.14/dm-zoned-fix-zone-state-management-race.patch @@ -0,0 +1,130 @@ +From 3b8cafdd5436f9298b3bf6eb831df5eef5ee82b6 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Tue, 16 Jul 2019 14:39:34 +0900 +Subject: dm zoned: fix zone state management race + +From: Damien Le Moal + +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 +Signed-off-by: Damien Le Moal +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch b/queue-4.14/drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch new file mode 100644 index 00000000000..4539b61dd0c --- /dev/null +++ b/queue-4.14/drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch @@ -0,0 +1,78 @@ +From 7cb95eeea6706c790571042a06782e378b2561ea Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Wed, 26 Jun 2019 14:10:27 -0400 +Subject: drm/nouveau/i2c: Enable i2c pads & busses during preinit + +From: Lyude Paul + +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 +Tested-by: Marc Meledandri +Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()") +Cc: stable@vger.kernel.org +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-4.14/hid-wacom-correct-touch-resolution-x-y-typo.patch b/queue-4.14/hid-wacom-correct-touch-resolution-x-y-typo.patch new file mode 100644 index 00000000000..cfed2111461 --- /dev/null +++ b/queue-4.14/hid-wacom-correct-touch-resolution-x-y-typo.patch @@ -0,0 +1,34 @@ +From 68c20cc2164cc5c7c73f8012ae6491afdb1f7f72 Mon Sep 17 00:00:00 2001 +From: Aaron Armstrong Skomra +Date: Fri, 10 May 2019 15:34:18 -0700 +Subject: HID: wacom: correct touch resolution x/y typo + +From: Aaron Armstrong Skomra + +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: # v4.11+ +Signed-off-by: Aaron Armstrong Skomra +Reviewed-by: Jason Gerecke +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ + diff --git a/queue-4.14/hid-wacom-generic-only-switch-the-mode-on-devices-with-leds.patch b/queue-4.14/hid-wacom-generic-only-switch-the-mode-on-devices-with-leds.patch new file mode 100644 index 00000000000..46654f939fe --- /dev/null +++ b/queue-4.14/hid-wacom-generic-only-switch-the-mode-on-devices-with-leds.patch @@ -0,0 +1,67 @@ +From d8e9806005f28bbb49899dab2068e3359e22ba35 Mon Sep 17 00:00:00 2001 +From: Aaron Armstrong Skomra +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 + +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: # v4.11+ +Signed-off-by: Aaron Armstrong Skomra +Reviewed-by: Jason Gerecke +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.14/intel_th-pci-add-ice-lake-nnpi-support.patch b/queue-4.14/intel_th-pci-add-ice-lake-nnpi-support.patch new file mode 100644 index 00000000000..c1a698b6a82 --- /dev/null +++ b/queue-4.14/intel_th-pci-add-ice-lake-nnpi-support.patch @@ -0,0 +1,35 @@ +From 4aa5aed2b6f267592705a526f57518a5d715b769 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Fri, 21 Jun 2019 19:19:30 +0300 +Subject: intel_th: pci: Add Ice Lake NNPI support + +From: Alexander Shishkin + +commit 4aa5aed2b6f267592705a526f57518a5d715b769 upstream. + +This adds Ice Lake NNPI support to the Intel(R) Trace Hub. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: stable +Link: https://lore.kernel.org/r/20190621161930.60785-5-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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 }, + }; + diff --git a/queue-4.14/libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch b/queue-4.14/libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch new file mode 100644 index 00000000000..e89ae9e439c --- /dev/null +++ b/queue-4.14/libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch @@ -0,0 +1,146 @@ +From 7e3e888dfc138089f4c15a81b418e88f0978f744 Mon Sep 17 00:00:00 2001 +From: Dan Williams +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 + +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 +Tested-by: Aneesh Kumar K.V [ppc64] +Cc: +Cc: David Hildenbrand +Cc: Jane Chu +Cc: Jeff Moyer +Cc: Jérôme Glisse +Cc: Jonathan Corbet +Cc: Logan Gunthorpe +Cc: Michal Hocko +Cc: Mike Rapoport +Cc: Oscar Salvador +Cc: Pavel Tatashin +Cc: Toshi Kani +Cc: Vlastimil Babka +Cc: Wei Yang +Cc: Jason Gunthorpe +Cc: Christoph Hellwig +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch b/queue-4.14/padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch new file mode 100644 index 00000000000..6bb51ff22fd --- /dev/null +++ b/queue-4.14/padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch @@ -0,0 +1,117 @@ +From cf144f81a99d1a3928f90b0936accfd3f45c9a0a Mon Sep 17 00:00:00 2001 +From: Daniel Jordan +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 + +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 +Cc: +Cc: Andrea Parri +Cc: Boqun Feng +Cc: Herbert Xu +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Steffen Klassert +Cc: linux-arch@vger.kernel.org +Cc: linux-crypto@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch b/queue-4.14/pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch new file mode 100644 index 00000000000..f3556893285 --- /dev/null +++ b/queue-4.14/pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch @@ -0,0 +1,56 @@ +From 000dd5316e1c756a1c028f22e01d06a38249dd4d Mon Sep 17 00:00:00 2001 +From: Mika Westerberg +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 + +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 +Reviewed-by: Lukas Wunner +Cc: 3.6+ # v3.6+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/perf-x86-amd-uncore-do-not-set-threadmask-and-slicemask-for-non-l3-pmcs.patch b/queue-4.14/perf-x86-amd-uncore-do-not-set-threadmask-and-slicemask-for-non-l3-pmcs.patch new file mode 100644 index 00000000000..1cf4bf09ca3 --- /dev/null +++ b/queue-4.14/perf-x86-amd-uncore-do-not-set-threadmask-and-slicemask-for-non-l3-pmcs.patch @@ -0,0 +1,67 @@ +From 16f4641166b10e199f0d7b68c2c5f004fef0bda3 Mon Sep 17 00:00:00 2001 +From: Kim Phillips +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 + +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 +Signed-off-by: Peter Zijlstra (Intel) +Cc: +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Borislav Petkov +Cc: Gary Hook +Cc: H. Peter Anvin +Cc: Janakarajan Natarajan +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Martin Liska +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Pu Wen +Cc: Stephane Eranian +Cc: Suravee Suthikulpanit +Cc: Thomas Gleixner +Cc: Vince Weaver +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.14/perf-x86-amd-uncore-set-the-thread-mask-for-f17h-l3-pmcs.patch b/queue-4.14/perf-x86-amd-uncore-set-the-thread-mask-for-f17h-l3-pmcs.patch new file mode 100644 index 00000000000..b63af37d89f --- /dev/null +++ b/queue-4.14/perf-x86-amd-uncore-set-the-thread-mask-for-f17h-l3-pmcs.patch @@ -0,0 +1,68 @@ +From 2f217d58a8a086d3399fecce39fb358848e799c4 Mon Sep 17 00:00:00 2001 +From: Kim Phillips +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 + +commit 2f217d58a8a086d3399fecce39fb358848e799c4 upstream. + +Fill in the L3 performance event select register ThreadMask +bitfield, to enable per hardware thread accounting. + +Signed-off-by: Kim Phillips +Signed-off-by: Peter Zijlstra (Intel) +Cc: +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Borislav Petkov +Cc: Gary Hook +Cc: H. Peter Anvin +Cc: Janakarajan Natarajan +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Martin Liska +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Pu Wen +Cc: Stephane Eranian +Cc: Suravee Suthikulpanit +Cc: Thomas Gleixner +Cc: Vince Weaver +Link: https://lkml.kernel.org/r/20190628215906.4276-2-kim.phillips@amd.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.14/series b/queue-4.14/series index 9d2d99277e1..ded8f9791ce 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -144,3 +144,21 @@ media-coda-remove-unbalanced-and-unneeded-mutex-unlock.patch 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 diff --git a/queue-4.14/x86-boot-fix-memory-leak-in-default_get_smp_config.patch b/queue-4.14/x86-boot-fix-memory-leak-in-default_get_smp_config.patch new file mode 100644 index 00000000000..c9453379f1f --- /dev/null +++ b/queue-4.14/x86-boot-fix-memory-leak-in-default_get_smp_config.patch @@ -0,0 +1,59 @@ +From e74bd96989dd42a51a73eddb4a5510a6f5e42ac3 Mon Sep 17 00:00:00 2001 +From: David Rientjes +Date: Tue, 9 Jul 2019 19:44:03 -0700 +Subject: x86/boot: Fix memory leak in default_get_smp_config() + +From: David Rientjes + +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 +Signed-off-by: David Rientjes +Signed-off-by: Thomas Gleixner +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 + +--- + 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)); + } + diff --git a/queue-4.14/xen-events-fix-binding-user-event-channels-to-cpus.patch b/queue-4.14/xen-events-fix-binding-user-event-channels-to-cpus.patch new file mode 100644 index 00000000000..6c8768a2101 --- /dev/null +++ b/queue-4.14/xen-events-fix-binding-user-event-channels-to-cpus.patch @@ -0,0 +1,93 @@ +From bce5963bcb4f9934faa52be323994511d59fd13c Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Fri, 21 Jun 2019 20:47:03 +0200 +Subject: xen/events: fix binding user event channels to cpus + +From: Juergen Gross + +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: # 4.13 +Fixes: c48f64ab472389df ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU") +Signed-off-by: Juergen Gross +Reviewed-by: Boris Ostrovsky +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman + +--- + 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 ++#include + #ifdef CONFIG_PCI_MSI + #include + #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) + {