From d65b160f6fc8669b1f91f6a737d503b58340c066 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Tue, 8 Oct 2019 21:26:32 -0400 Subject: [PATCH] fixes for 4.19 Signed-off-by: Sasha Levin --- ...ng-writeback_fid-on-mmap-with-type-p.patch | 47 +++++ .../9p-transport-error-uninitialized.patch | 91 +++++++++ ...ories-inode-i_blkbits-initialization.patch | 50 +++++ ...onnection-if-session-hang-in-opening.patch | 46 +++++ ...-for-valid-number-of-registers-to-re.patch | 39 ++++ ...ix-kfd-related-kernel-oops-on-hawaii.patch | 41 ++++ ...-acquire-the-page-lock-around-set_pa.patch | 57 ++++++ ...earlier-when-radeon.cik_-si_support-.patch | 119 ++++++++++++ ...ble-null-pointer-dereferences-in-enc.patch | 46 +++++ ...use-fix-memleak-in-cuse_channel_open.patch | 39 ++++ ...lways-return-negative-code-for-error.patch | 44 +++++ ...ma-fix-freeing-ongoing-ahash_request.patch | 42 +++++ ...-elfcore.c-include-proper-prototypes.patch | 51 +++++ ...sistency-check-on-injected-exception.patch | 48 +++++ ...v-xive-free-escalation-interrupts-be.patch | 86 +++++++++ ...it_test-fix-acpi_handle-redefinition.patch | 70 +++++++ ...-initialize-bad-block-for-volatile-n.patch | 110 +++++++++++ ...d-fix-crash-when-the-blksize-is-zero.patch | 87 +++++++++ ...tables-allow-lookups-in-dynamic-sets.patch | 107 +++++++++++ ...emory-leak-in-nfp_flower_spawn_vnic_.patch | 36 ++++ ...b-point-to-right-memory-window-index.patch | 53 ++++++ ...etection-of-java-11-openjdk-devel-pa.patch | 62 ++++++ ...previous-counts-on-repeat-with-inter.patch | 168 +++++++++++++++++ ...ix-segfault-in-cpu_cache_level__read.patch | 63 +++++++ ...libunwind-build-failure-on-i386-syst.patch | 51 +++++ ...o-clear-the-return-on-close-layout-s.patch | 48 +++++ ...-radix-rename-cpu_ftr_p9_tlbie_bug-f.patch | 119 ++++++++++++ ...fix-cpu_hotplug_lock-acquisition-in-.patch | 176 ++++++++++++++++++ ...-check-in-case-requested-period-cann.patch | 49 +++++ ...rrupts-being-erroneously-enabled-in-.patch | 62 ++++++ ...igration-to-invalid-cpu-in-__set_cpu.patch | 85 +++++++++ ...-call-sync_core-only-before-usermode.patch | 50 +++++ ...-fix-private-expedited-registration-.patch | 53 ++++++ queue-4.19/series | 40 ++++ ...after-free-when-unregistering-therma.patch | 134 +++++++++++++ ...mal_hwmon-sanitize-thermal_zone-type.patch | 53 ++++++ ...st-hrtimer-fix-a-race-in-bc_set_next.patch | 173 +++++++++++++++++ ...vent-do-not-free-tep-cmdlines-in-add.patch | 57 ++++++ ...chdog-aspeed-add-support-for-ast2600.patch | 47 +++++ ...sable-the-stackleak-gcc-plugin-for-t.patch | 53 ++++++ .../xen-pci-reserve-mcfg-areas-earlier.patch | 90 +++++++++ 41 files changed, 2942 insertions(+) create mode 100644 queue-4.19/9p-avoid-attaching-writeback_fid-on-mmap-with-type-p.patch create mode 100644 queue-4.19/9p-transport-error-uninitialized.patch create mode 100644 queue-4.19/ceph-fix-directories-inode-i_blkbits-initialization.patch create mode 100644 queue-4.19/ceph-reconnect-connection-if-session-hang-in-opening.patch create mode 100644 queue-4.19/drm-amdgpu-check-for-valid-number-of-registers-to-re.patch create mode 100644 queue-4.19/drm-amdgpu-fix-kfd-related-kernel-oops-on-hawaii.patch create mode 100644 queue-4.19/drm-i915-userptr-acquire-the-page-lock-around-set_pa.patch create mode 100644 queue-4.19/drm-radeon-bail-earlier-when-radeon.cik_-si_support-.patch create mode 100644 queue-4.19/fs-nfs-fix-possible-null-pointer-dereferences-in-enc.patch create mode 100644 queue-4.19/fuse-fix-memleak-in-cuse_channel_open.patch create mode 100644 queue-4.19/ima-always-return-negative-code-for-error.patch create mode 100644 queue-4.19/ima-fix-freeing-ongoing-ahash_request.patch create mode 100644 queue-4.19/kernel-elfcore.c-include-proper-prototypes.patch create mode 100644 queue-4.19/kvm-nvmx-fix-consistency-check-on-injected-exception.patch create mode 100644 queue-4.19/kvm-ppc-book3s-hv-xive-free-escalation-interrupts-be.patch create mode 100644 queue-4.19/libnvdimm-nfit_test-fix-acpi_handle-redefinition.patch create mode 100644 queue-4.19/libnvdimm-region-initialize-bad-block-for-volatile-n.patch create mode 100644 queue-4.19/nbd-fix-crash-when-the-blksize-is-zero.patch create mode 100644 queue-4.19/netfilter-nf_tables-allow-lookups-in-dynamic-sets.patch create mode 100644 queue-4.19/nfp-flower-fix-memory-leak-in-nfp_flower_spawn_vnic_.patch create mode 100644 queue-4.19/ntb-point-to-right-memory-window-index.patch create mode 100644 queue-4.19/perf-build-add-detection-of-java-11-openjdk-devel-pa.patch create mode 100644 queue-4.19/perf-stat-reset-previous-counts-on-repeat-with-inter.patch create mode 100644 queue-4.19/perf-tools-fix-segfault-in-cpu_cache_level__read.patch create mode 100644 queue-4.19/perf-unwind-fix-libunwind-build-failure-on-i386-syst.patch create mode 100644 queue-4.19/pnfs-ensure-we-do-clear-the-return-on-close-layout-s.patch create mode 100644 queue-4.19/powerpc-book3s64-radix-rename-cpu_ftr_p9_tlbie_bug-f.patch create mode 100644 queue-4.19/powerpc-pseries-fix-cpu_hotplug_lock-acquisition-in-.patch create mode 100644 queue-4.19/pwm-stm32-lp-add-check-in-case-requested-period-cann.patch create mode 100644 queue-4.19/riscv-avoid-interrupts-being-erroneously-enabled-in-.patch create mode 100644 queue-4.19/sched-core-fix-migration-to-invalid-cpu-in-__set_cpu.patch create mode 100644 queue-4.19/sched-membarrier-call-sync_core-only-before-usermode.patch create mode 100644 queue-4.19/sched-membarrier-fix-private-expedited-registration-.patch create mode 100644 queue-4.19/thermal-fix-use-after-free-when-unregistering-therma.patch create mode 100644 queue-4.19/thermal_hwmon-sanitize-thermal_zone-type.patch create mode 100644 queue-4.19/tick-broadcast-hrtimer-fix-a-race-in-bc_set_next.patch create mode 100644 queue-4.19/tools-lib-traceevent-do-not-free-tep-cmdlines-in-add.patch create mode 100644 queue-4.19/watchdog-aspeed-add-support-for-ast2600.patch create mode 100644 queue-4.19/x86-purgatory-disable-the-stackleak-gcc-plugin-for-t.patch create mode 100644 queue-4.19/xen-pci-reserve-mcfg-areas-earlier.patch diff --git a/queue-4.19/9p-avoid-attaching-writeback_fid-on-mmap-with-type-p.patch b/queue-4.19/9p-avoid-attaching-writeback_fid-on-mmap-with-type-p.patch new file mode 100644 index 00000000000..5fce4c36ba2 --- /dev/null +++ b/queue-4.19/9p-avoid-attaching-writeback_fid-on-mmap-with-type-p.patch @@ -0,0 +1,47 @@ +From 289fe560726c6456029e541f227c709b701a4afc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 20 Aug 2019 18:03:25 +0800 +Subject: 9p: avoid attaching writeback_fid on mmap with type PRIVATE + +From: Chengguang Xu + +[ Upstream commit c87a37ebd40b889178664c2c09cc187334146292 ] + +Currently on mmap cache policy, we always attach writeback_fid +whether mmap type is SHARED or PRIVATE. However, in the use case +of kata-container which combines 9p(Guest OS) with overlayfs(Host OS), +this behavior will trigger overlayfs' copy-up when excute command +inside container. + +Link: http://lkml.kernel.org/r/20190820100325.10313-1-cgxu519@zoho.com.cn +Signed-off-by: Chengguang Xu +Signed-off-by: Dominique Martinet +Signed-off-by: Sasha Levin +--- + fs/9p/vfs_file.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c +index 05454a7e22dc2..550d0b169d7c2 100644 +--- a/fs/9p/vfs_file.c ++++ b/fs/9p/vfs_file.c +@@ -528,6 +528,7 @@ v9fs_mmap_file_mmap(struct file *filp, struct vm_area_struct *vma) + v9inode = V9FS_I(inode); + mutex_lock(&v9inode->v_mutex); + if (!v9inode->writeback_fid && ++ (vma->vm_flags & VM_SHARED) && + (vma->vm_flags & VM_WRITE)) { + /* + * clone a fid and add it to writeback_fid +@@ -629,6 +630,8 @@ static void v9fs_mmap_vm_close(struct vm_area_struct *vma) + (vma->vm_end - vma->vm_start - 1), + }; + ++ if (!(vma->vm_flags & VM_SHARED)) ++ return; + + p9_debug(P9_DEBUG_VFS, "9p VMA close, %p, flushing", vma); + +-- +2.20.1 + diff --git a/queue-4.19/9p-transport-error-uninitialized.patch b/queue-4.19/9p-transport-error-uninitialized.patch new file mode 100644 index 00000000000..344edccc361 --- /dev/null +++ b/queue-4.19/9p-transport-error-uninitialized.patch @@ -0,0 +1,91 @@ +From f58c7c171a08db471e3d1ec4b7ea6122cdf66a42 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 13 Jun 2019 15:08:54 +0800 +Subject: 9p: Transport error uninitialized + +From: Lu Shuaibing + +[ Upstream commit 0ce772fe79b68f83df40f07f28207b292785c677 ] + +The p9_tag_alloc() does not initialize the transport error t_err field. +The struct p9_req_t *req is allocated and stored in a struct p9_client +variable. The field t_err is never initialized before p9_conn_cancel() +checks its value. + +KUMSAN(KernelUninitializedMemorySantizer, a new error detection tool) +reports this bug. + +================================================================== +BUG: KUMSAN: use of uninitialized memory in p9_conn_cancel+0x2d9/0x3b0 +Read of size 4 at addr ffff88805f9b600c by task kworker/1:2/1216 + +CPU: 1 PID: 1216 Comm: kworker/1:2 Not tainted 5.2.0-rc4+ #28 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 +Workqueue: events p9_write_work +Call Trace: + dump_stack+0x75/0xae + __kumsan_report+0x17c/0x3e6 + kumsan_report+0xe/0x20 + p9_conn_cancel+0x2d9/0x3b0 + p9_write_work+0x183/0x4a0 + process_one_work+0x4d1/0x8c0 + worker_thread+0x6e/0x780 + kthread+0x1ca/0x1f0 + ret_from_fork+0x35/0x40 + +Allocated by task 1979: + save_stack+0x19/0x80 + __kumsan_kmalloc.constprop.3+0xbc/0x120 + kmem_cache_alloc+0xa7/0x170 + p9_client_prepare_req.part.9+0x3b/0x380 + p9_client_rpc+0x15e/0x880 + p9_client_create+0x3d0/0xac0 + v9fs_session_init+0x192/0xc80 + v9fs_mount+0x67/0x470 + legacy_get_tree+0x70/0xd0 + vfs_get_tree+0x4a/0x1c0 + do_mount+0xba9/0xf90 + ksys_mount+0xa8/0x120 + __x64_sys_mount+0x62/0x70 + do_syscall_64+0x6d/0x1e0 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +Freed by task 0: +(stack is not available) + +The buggy address belongs to the object at ffff88805f9b6008 + which belongs to the cache p9_req_t of size 144 +The buggy address is located 4 bytes inside of + 144-byte region [ffff88805f9b6008, ffff88805f9b6098) +The buggy address belongs to the page: +page:ffffea00017e6d80 refcount:1 mapcount:0 mapping:ffff888068b63740 index:0xffff88805f9b7d90 compound_mapcount: 0 +flags: 0x100000000010200(slab|head) +raw: 0100000000010200 ffff888068b66450 ffff888068b66450 ffff888068b63740 +raw: ffff88805f9b7d90 0000000000100001 00000001ffffffff 0000000000000000 +page dumped because: kumsan: bad access detected +================================================================== + +Link: http://lkml.kernel.org/r/20190613070854.10434-1-shuaibinglu@126.com +Signed-off-by: Lu Shuaibing +[dominique.martinet@cea.fr: grouped the added init with the others] +Signed-off-by: Dominique Martinet +Signed-off-by: Sasha Levin +--- + net/9p/client.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/9p/client.c b/net/9p/client.c +index b615aae5a0f81..d62f83f93d7bb 100644 +--- a/net/9p/client.c ++++ b/net/9p/client.c +@@ -296,6 +296,7 @@ p9_tag_alloc(struct p9_client *c, int8_t type, unsigned int max_size) + + p9pdu_reset(&req->tc); + p9pdu_reset(&req->rc); ++ req->t_err = 0; + req->status = REQ_STATUS_ALLOC; + init_waitqueue_head(&req->wq); + INIT_LIST_HEAD(&req->req_list); +-- +2.20.1 + diff --git a/queue-4.19/ceph-fix-directories-inode-i_blkbits-initialization.patch b/queue-4.19/ceph-fix-directories-inode-i_blkbits-initialization.patch new file mode 100644 index 00000000000..e9e4c9284bf --- /dev/null +++ b/queue-4.19/ceph-fix-directories-inode-i_blkbits-initialization.patch @@ -0,0 +1,50 @@ +From 90ca7799e53e0f20879ea17ae43dc77d790612fc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 23 Jul 2019 16:50:20 +0100 +Subject: ceph: fix directories inode i_blkbits initialization + +From: Luis Henriques + +[ Upstream commit 750670341a24cb714e624e0fd7da30900ad93752 ] + +When filling an inode with info from the MDS, i_blkbits is being +initialized using fl_stripe_unit, which contains the stripe unit in +bytes. Unfortunately, this doesn't make sense for directories as they +have fl_stripe_unit set to '0'. This means that i_blkbits will be set +to 0xff, causing an UBSAN undefined behaviour in i_blocksize(): + + UBSAN: Undefined behaviour in ./include/linux/fs.h:731:12 + shift exponent 255 is too large for 32-bit type 'int' + +Fix this by initializing i_blkbits to CEPH_BLOCK_SHIFT if fl_stripe_unit +is zero. + +Signed-off-by: Luis Henriques +Reviewed-by: Jeff Layton +Signed-off-by: Ilya Dryomov +Signed-off-by: Sasha Levin +--- + fs/ceph/inode.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c +index c06845237cbaa..8196c21d8623c 100644 +--- a/fs/ceph/inode.c ++++ b/fs/ceph/inode.c +@@ -807,7 +807,12 @@ static int fill_inode(struct inode *inode, struct page *locked_page, + + /* update inode */ + inode->i_rdev = le32_to_cpu(info->rdev); +- inode->i_blkbits = fls(le32_to_cpu(info->layout.fl_stripe_unit)) - 1; ++ /* directories have fl_stripe_unit set to zero */ ++ if (le32_to_cpu(info->layout.fl_stripe_unit)) ++ inode->i_blkbits = ++ fls(le32_to_cpu(info->layout.fl_stripe_unit)) - 1; ++ else ++ inode->i_blkbits = CEPH_BLOCK_SHIFT; + + __ceph_update_quota(ci, iinfo->max_bytes, iinfo->max_files); + +-- +2.20.1 + diff --git a/queue-4.19/ceph-reconnect-connection-if-session-hang-in-opening.patch b/queue-4.19/ceph-reconnect-connection-if-session-hang-in-opening.patch new file mode 100644 index 00000000000..f84cccb77f0 --- /dev/null +++ b/queue-4.19/ceph-reconnect-connection-if-session-hang-in-opening.patch @@ -0,0 +1,46 @@ +From a69773a9c5d136cce594a5496ae02f0866814d27 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 28 Aug 2019 21:22:45 +0800 +Subject: ceph: reconnect connection if session hang in opening state + +From: Erqi Chen + +[ Upstream commit 71a228bc8d65900179e37ac309e678f8c523f133 ] + +If client mds session is evicted in CEPH_MDS_SESSION_OPENING state, +mds won't send session msg to client, and delayed_work skip +CEPH_MDS_SESSION_OPENING state session, the session hang forever. + +Allow ceph_con_keepalive to reconnect a session in OPENING to avoid +session hang. Also, ensure that we skip sessions in RESTARTING and +REJECTED states since those states can't be resurrected by issuing +a keepalive. + +Link: https://tracker.ceph.com/issues/41551 +Signed-off-by: Erqi Chen chenerqi@gmail.com +Reviewed-by: "Yan, Zheng" +Signed-off-by: Jeff Layton +Signed-off-by: Ilya Dryomov +Signed-off-by: Sasha Levin +--- + fs/ceph/mds_client.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c +index bfcf11c70bfad..09db6d08614d2 100644 +--- a/fs/ceph/mds_client.c ++++ b/fs/ceph/mds_client.c +@@ -3640,7 +3640,9 @@ static void delayed_work(struct work_struct *work) + pr_info("mds%d hung\n", s->s_mds); + } + } +- if (s->s_state < CEPH_MDS_SESSION_OPEN) { ++ if (s->s_state == CEPH_MDS_SESSION_NEW || ++ s->s_state == CEPH_MDS_SESSION_RESTARTING || ++ s->s_state == CEPH_MDS_SESSION_REJECTED) { + /* this mds is failed or recovering, just wait */ + ceph_put_mds_session(s); + continue; +-- +2.20.1 + diff --git a/queue-4.19/drm-amdgpu-check-for-valid-number-of-registers-to-re.patch b/queue-4.19/drm-amdgpu-check-for-valid-number-of-registers-to-re.patch new file mode 100644 index 00000000000..c7f11f4cf85 --- /dev/null +++ b/queue-4.19/drm-amdgpu-check-for-valid-number-of-registers-to-re.patch @@ -0,0 +1,39 @@ +From 83466bd4058b98d3427d794507adc5c4f44daee1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 31 Aug 2019 21:25:36 +0200 +Subject: drm/amdgpu: Check for valid number of registers to read + +From: Trek + +[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ] + +Do not try to allocate any amount of memory requested by the user. +Instead limit it to 128 registers. Actually the longest series of +consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and +mmGB_MACROTILE_MODE0-15 (0x2644-0x2673). + +Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273 +Signed-off-by: Trek +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c +index c0396e83f3526..fc93b103f7778 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c +@@ -562,6 +562,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file + if (sh_num == AMDGPU_INFO_MMR_SH_INDEX_MASK) + sh_num = 0xffffffff; + ++ if (info->read_mmr_reg.count > 128) ++ return -EINVAL; ++ + regs = kmalloc_array(info->read_mmr_reg.count, sizeof(*regs), GFP_KERNEL); + if (!regs) + return -ENOMEM; +-- +2.20.1 + diff --git a/queue-4.19/drm-amdgpu-fix-kfd-related-kernel-oops-on-hawaii.patch b/queue-4.19/drm-amdgpu-fix-kfd-related-kernel-oops-on-hawaii.patch new file mode 100644 index 00000000000..d3402199a57 --- /dev/null +++ b/queue-4.19/drm-amdgpu-fix-kfd-related-kernel-oops-on-hawaii.patch @@ -0,0 +1,41 @@ +From 147234c3fcc64aa1f9096daa9172a7b1bb8bb94d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 5 Sep 2019 19:22:02 -0400 +Subject: drm/amdgpu: Fix KFD-related kernel oops on Hawaii +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Felix Kuehling + +[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ] + +Hawaii needs to flush caches explicitly, submitting an IB in a user +VMID from kernel mode. There is no s_fence in this case. + +Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job") +Signed-off-by: Felix Kuehling +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c +index 51b5e977ca885..f4e9d1b10e3ed 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c +@@ -139,7 +139,8 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs, + /* ring tests don't use a job */ + if (job) { + vm = job->vm; +- fence_ctx = job->base.s_fence->scheduled.context; ++ fence_ctx = job->base.s_fence ? ++ job->base.s_fence->scheduled.context : 0; + } else { + vm = NULL; + fence_ctx = 0; +-- +2.20.1 + diff --git a/queue-4.19/drm-i915-userptr-acquire-the-page-lock-around-set_pa.patch b/queue-4.19/drm-i915-userptr-acquire-the-page-lock-around-set_pa.patch new file mode 100644 index 00000000000..44860fb1864 --- /dev/null +++ b/queue-4.19/drm-i915-userptr-acquire-the-page-lock-around-set_pa.patch @@ -0,0 +1,57 @@ +From 7d10a59723931ebad8f3e0bd819d72505d9fd7fd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 8 Jul 2019 15:03:27 +0100 +Subject: drm/i915/userptr: Acquire the page lock around set_page_dirty() + +From: Chris Wilson + +[ Upstream commit cb6d7c7dc7ff8cace666ddec66334117a6068ce2 ] + +set_page_dirty says: + + For pages with a mapping this should be done under the page lock + for the benefit of asynchronous memory errors who prefer a + consistent dirty state. This rule can be broken in some special + cases, but should be better not to. + +Under those rules, it is only safe for us to use the plain set_page_dirty +calls for shmemfs/anonymous memory. Userptr may be used with real +mappings and so needs to use the locked version (set_page_dirty_lock). + +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 +Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") +References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers") +Signed-off-by: Chris Wilson +Cc: Tvrtko Ursulin +Cc: stable@vger.kernel.org +Reviewed-by: Tvrtko Ursulin +Link: https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-chris@chris-wilson.co.uk +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c +index 2c9b284036d10..e13ea2ecd669c 100644 +--- a/drivers/gpu/drm/i915/i915_gem_userptr.c ++++ b/drivers/gpu/drm/i915/i915_gem_userptr.c +@@ -692,7 +692,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj, + + for_each_sgt_page(page, sgt_iter, pages) { + if (obj->mm.dirty) +- set_page_dirty(page); ++ /* ++ * As this may not be anonymous memory (e.g. shmem) ++ * but exist on a real mapping, we have to lock ++ * the page in order to dirty it -- holding ++ * the page reference is not sufficient to ++ * prevent the inode from being truncated. ++ * Play safe and take the lock. ++ */ ++ set_page_dirty_lock(page); + + mark_page_accessed(page); + put_page(page); +-- +2.20.1 + diff --git a/queue-4.19/drm-radeon-bail-earlier-when-radeon.cik_-si_support-.patch b/queue-4.19/drm-radeon-bail-earlier-when-radeon.cik_-si_support-.patch new file mode 100644 index 00000000000..e90757fb211 --- /dev/null +++ b/queue-4.19/drm-radeon-bail-earlier-when-radeon.cik_-si_support-.patch @@ -0,0 +1,119 @@ +From 18db8e6bba7c58ff7e0f0b8751da5d5fe30e123c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Sep 2019 22:32:38 +0200 +Subject: drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Hans de Goede + +[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ] + +Bail from the pci_driver probe function instead of from the drm_driver +load function. + +This avoid /dev/dri/card0 temporarily getting registered and then +unregistered again, sending unwanted add / remove udev events to +userspace. + +Specifically this avoids triggering the (userspace) bug fixed by this +plymouth merge-request: +https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 + +Note that despite that being an userspace bug, not sending unnecessary +udev events is a good idea in general. + +BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 +Reviewed-by: Michel Dänzer +Signed-off-by: Hans de Goede +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/radeon/radeon_drv.c | 31 +++++++++++++++++++++++++++++ + drivers/gpu/drm/radeon/radeon_kms.c | 25 ----------------------- + 2 files changed, 31 insertions(+), 25 deletions(-) + +diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c +index 25b5407c74b5a..d83310751a8e4 100644 +--- a/drivers/gpu/drm/radeon/radeon_drv.c ++++ b/drivers/gpu/drm/radeon/radeon_drv.c +@@ -340,8 +340,39 @@ static int radeon_kick_out_firmware_fb(struct pci_dev *pdev) + static int radeon_pci_probe(struct pci_dev *pdev, + const struct pci_device_id *ent) + { ++ unsigned long flags = 0; + int ret; + ++ if (!ent) ++ return -ENODEV; /* Avoid NULL-ptr deref in drm_get_pci_dev */ ++ ++ flags = ent->driver_data; ++ ++ if (!radeon_si_support) { ++ switch (flags & RADEON_FAMILY_MASK) { ++ case CHIP_TAHITI: ++ case CHIP_PITCAIRN: ++ case CHIP_VERDE: ++ case CHIP_OLAND: ++ case CHIP_HAINAN: ++ dev_info(&pdev->dev, ++ "SI support disabled by module param\n"); ++ return -ENODEV; ++ } ++ } ++ if (!radeon_cik_support) { ++ switch (flags & RADEON_FAMILY_MASK) { ++ case CHIP_KAVERI: ++ case CHIP_BONAIRE: ++ case CHIP_HAWAII: ++ case CHIP_KABINI: ++ case CHIP_MULLINS: ++ dev_info(&pdev->dev, ++ "CIK support disabled by module param\n"); ++ return -ENODEV; ++ } ++ } ++ + if (vga_switcheroo_client_probe_defer(pdev)) + return -EPROBE_DEFER; + +diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c +index 6a8fb6fd183c3..3ff835767ac58 100644 +--- a/drivers/gpu/drm/radeon/radeon_kms.c ++++ b/drivers/gpu/drm/radeon/radeon_kms.c +@@ -95,31 +95,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags) + struct radeon_device *rdev; + int r, acpi_status; + +- if (!radeon_si_support) { +- switch (flags & RADEON_FAMILY_MASK) { +- case CHIP_TAHITI: +- case CHIP_PITCAIRN: +- case CHIP_VERDE: +- case CHIP_OLAND: +- case CHIP_HAINAN: +- dev_info(dev->dev, +- "SI support disabled by module param\n"); +- return -ENODEV; +- } +- } +- if (!radeon_cik_support) { +- switch (flags & RADEON_FAMILY_MASK) { +- case CHIP_KAVERI: +- case CHIP_BONAIRE: +- case CHIP_HAWAII: +- case CHIP_KABINI: +- case CHIP_MULLINS: +- dev_info(dev->dev, +- "CIK support disabled by module param\n"); +- return -ENODEV; +- } +- } +- + rdev = kzalloc(sizeof(struct radeon_device), GFP_KERNEL); + if (rdev == NULL) { + return -ENOMEM; +-- +2.20.1 + diff --git a/queue-4.19/fs-nfs-fix-possible-null-pointer-dereferences-in-enc.patch b/queue-4.19/fs-nfs-fix-possible-null-pointer-dereferences-in-enc.patch new file mode 100644 index 00000000000..be91daeda3f --- /dev/null +++ b/queue-4.19/fs-nfs-fix-possible-null-pointer-dereferences-in-enc.patch @@ -0,0 +1,46 @@ +From be360e009fd1c39c36a8e78bf9994d4944e724c1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 26 Jul 2019 15:48:53 +0800 +Subject: fs: nfs: Fix possible null-pointer dereferences in encode_attrs() + +From: Jia-Ju Bai + +[ Upstream commit e2751463eaa6f9fec8fea80abbdc62dbc487b3c5 ] + +In encode_attrs(), there is an if statement on line 1145 to check +whether label is NULL: + if (label && (attrmask[2] & FATTR4_WORD2_SECURITY_LABEL)) + +When label is NULL, it is used on lines 1178-1181: + *p++ = cpu_to_be32(label->lfs); + *p++ = cpu_to_be32(label->pi); + *p++ = cpu_to_be32(label->len); + p = xdr_encode_opaque_fixed(p, label->label, label->len); + +To fix these bugs, label is checked before being used. + +These bugs are found by a static analysis tool STCheck written by us. + +Signed-off-by: Jia-Ju Bai +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs4xdr.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c +index b7bde12d8cd51..1c0227c78a7bc 100644 +--- a/fs/nfs/nfs4xdr.c ++++ b/fs/nfs/nfs4xdr.c +@@ -1171,7 +1171,7 @@ static void encode_attrs(struct xdr_stream *xdr, const struct iattr *iap, + } else + *p++ = cpu_to_be32(NFS4_SET_TO_SERVER_TIME); + } +- if (bmval[2] & FATTR4_WORD2_SECURITY_LABEL) { ++ if (label && (bmval[2] & FATTR4_WORD2_SECURITY_LABEL)) { + *p++ = cpu_to_be32(label->lfs); + *p++ = cpu_to_be32(label->pi); + *p++ = cpu_to_be32(label->len); +-- +2.20.1 + diff --git a/queue-4.19/fuse-fix-memleak-in-cuse_channel_open.patch b/queue-4.19/fuse-fix-memleak-in-cuse_channel_open.patch new file mode 100644 index 00000000000..0f36e02d26f --- /dev/null +++ b/queue-4.19/fuse-fix-memleak-in-cuse_channel_open.patch @@ -0,0 +1,39 @@ +From 7e1fc6e583846c43e9e6150200559a230f06639e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 14 Aug 2019 15:59:09 +0800 +Subject: fuse: fix memleak in cuse_channel_open + +From: zhengbin + +[ Upstream commit 9ad09b1976c562061636ff1e01bfc3a57aebe56b ] + +If cuse_send_init fails, need to fuse_conn_put cc->fc. + +cuse_channel_open->fuse_conn_init->refcount_set(&fc->count, 1) + ->fuse_dev_alloc->fuse_conn_get + ->fuse_dev_free->fuse_conn_put + +Fixes: cc080e9e9be1 ("fuse: introduce per-instance fuse_dev structure") +Reported-by: Hulk Robot +Signed-off-by: zhengbin +Signed-off-by: Miklos Szeredi +Signed-off-by: Sasha Levin +--- + fs/fuse/cuse.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c +index 8f68181256c00..f057c213c453a 100644 +--- a/fs/fuse/cuse.c ++++ b/fs/fuse/cuse.c +@@ -518,6 +518,7 @@ static int cuse_channel_open(struct inode *inode, struct file *file) + rc = cuse_send_init(cc); + if (rc) { + fuse_dev_free(fud); ++ fuse_conn_put(&cc->fc); + return rc; + } + file->private_data = fud; +-- +2.20.1 + diff --git a/queue-4.19/ima-always-return-negative-code-for-error.patch b/queue-4.19/ima-always-return-negative-code-for-error.patch new file mode 100644 index 00000000000..85e9bc5f5f7 --- /dev/null +++ b/queue-4.19/ima-always-return-negative-code-for-error.patch @@ -0,0 +1,44 @@ +From be240385baabbdd3620ab96657f290beeb979152 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 2 Jul 2019 10:00:40 +0200 +Subject: ima: always return negative code for error + +From: Sascha Hauer + +[ Upstream commit f5e1040196dbfe14c77ce3dfe3b7b08d2d961e88 ] + +integrity_kernel_read() returns the number of bytes read. If this is +a short read then this positive value is returned from +ima_calc_file_hash_atfm(). Currently this is only indirectly called from +ima_calc_file_hash() and this function only tests for the return value +being zero or nonzero and also doesn't forward the return value. +Nevertheless there's no point in returning a positive value as an error, +so translate a short read into -EINVAL. + +Signed-off-by: Sascha Hauer +Signed-off-by: Mimi Zohar +Signed-off-by: Sasha Levin +--- + security/integrity/ima/ima_crypto.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c +index d9e7728027c6c..b7822d2b79736 100644 +--- a/security/integrity/ima/ima_crypto.c ++++ b/security/integrity/ima/ima_crypto.c +@@ -271,8 +271,11 @@ static int ima_calc_file_hash_atfm(struct file *file, + rbuf_len = min_t(loff_t, i_size - offset, rbuf_size[active]); + rc = integrity_kernel_read(file, offset, rbuf[active], + rbuf_len); +- if (rc != rbuf_len) ++ if (rc != rbuf_len) { ++ if (rc >= 0) ++ rc = -EINVAL; + goto out3; ++ } + + if (rbuf[1] && offset) { + /* Using two buffers, and it is not the first +-- +2.20.1 + diff --git a/queue-4.19/ima-fix-freeing-ongoing-ahash_request.patch b/queue-4.19/ima-fix-freeing-ongoing-ahash_request.patch new file mode 100644 index 00000000000..589ef18ae8e --- /dev/null +++ b/queue-4.19/ima-fix-freeing-ongoing-ahash_request.patch @@ -0,0 +1,42 @@ +From 3421e0c811bc0b48ea45ea9a479299c2deb6874d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 2 Jul 2019 10:00:41 +0200 +Subject: ima: fix freeing ongoing ahash_request + +From: Sascha Hauer + +[ Upstream commit 4ece3125f21b1d42b84896c5646dbf0e878464e1 ] + +integrity_kernel_read() can fail in which case we forward to call +ahash_request_free() on a currently running request. We have to wait +for its completion before we can free the request. + +This was observed by interrupting a "find / -type f -xdev -print0 | xargs -0 +cat 1>/dev/null" with ctrl-c on an IMA enabled filesystem. + +Signed-off-by: Sascha Hauer +Signed-off-by: Mimi Zohar +Signed-off-by: Sasha Levin +--- + security/integrity/ima/ima_crypto.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c +index b7822d2b79736..f63b4bd45d60e 100644 +--- a/security/integrity/ima/ima_crypto.c ++++ b/security/integrity/ima/ima_crypto.c +@@ -274,6 +274,11 @@ static int ima_calc_file_hash_atfm(struct file *file, + if (rc != rbuf_len) { + if (rc >= 0) + rc = -EINVAL; ++ /* ++ * Forward current rc, do not overwrite with return value ++ * from ahash_wait() ++ */ ++ ahash_wait(ahash_rc, &wait); + goto out3; + } + +-- +2.20.1 + diff --git a/queue-4.19/kernel-elfcore.c-include-proper-prototypes.patch b/queue-4.19/kernel-elfcore.c-include-proper-prototypes.patch new file mode 100644 index 00000000000..1bc44b0c25c --- /dev/null +++ b/queue-4.19/kernel-elfcore.c-include-proper-prototypes.patch @@ -0,0 +1,51 @@ +From 730e5962a66210267d4aee02daf68c6f680490c8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 25 Sep 2019 16:45:59 -0700 +Subject: kernel/elfcore.c: include proper prototypes + +From: Valdis Kletnieks + +[ Upstream commit 0f74914071ab7e7b78731ed62bf350e3a344e0a5 ] + +When building with W=1, gcc properly complains that there's no prototypes: + + CC kernel/elfcore.o +kernel/elfcore.c:7:17: warning: no previous prototype for 'elf_core_extra_phdrs' [-Wmissing-prototypes] + 7 | Elf_Half __weak elf_core_extra_phdrs(void) + | ^~~~~~~~~~~~~~~~~~~~ +kernel/elfcore.c:12:12: warning: no previous prototype for 'elf_core_write_extra_phdrs' [-Wmissing-prototypes] + 12 | int __weak elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset) + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +kernel/elfcore.c:17:12: warning: no previous prototype for 'elf_core_write_extra_data' [-Wmissing-prototypes] + 17 | int __weak elf_core_write_extra_data(struct coredump_params *cprm) + | ^~~~~~~~~~~~~~~~~~~~~~~~~ +kernel/elfcore.c:22:15: warning: no previous prototype for 'elf_core_extra_data_size' [-Wmissing-prototypes] + 22 | size_t __weak elf_core_extra_data_size(void) + | ^~~~~~~~~~~~~~~~~~~~~~~~ + +Provide the include file so gcc is happy, and we don't have potential code drift + +Link: http://lkml.kernel.org/r/29875.1565224705@turing-police +Signed-off-by: Valdis Kletnieks +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + kernel/elfcore.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/kernel/elfcore.c b/kernel/elfcore.c +index fc482c8e0bd88..57fb4dcff4349 100644 +--- a/kernel/elfcore.c ++++ b/kernel/elfcore.c +@@ -3,6 +3,7 @@ + #include + #include + #include ++#include + + Elf_Half __weak elf_core_extra_phdrs(void) + { +-- +2.20.1 + diff --git a/queue-4.19/kvm-nvmx-fix-consistency-check-on-injected-exception.patch b/queue-4.19/kvm-nvmx-fix-consistency-check-on-injected-exception.patch new file mode 100644 index 00000000000..2b8bcab822b --- /dev/null +++ b/queue-4.19/kvm-nvmx-fix-consistency-check-on-injected-exception.patch @@ -0,0 +1,48 @@ +From 5e0e6683a457dd26b4a16cd0553f232ff733cb51 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Oct 2019 09:21:23 -0700 +Subject: KVM: nVMX: Fix consistency check on injected exception error code + +From: Sean Christopherson + +[ Upstream commit 567926cca99ba1750be8aae9c4178796bf9bb90b ] + +Current versions of Intel's SDM incorrectly state that "bits 31:15 of +the VM-Entry exception error-code field" must be zero. In reality, bits +31:16 must be zero, i.e. error codes are 16-bit values. + +The bogus error code check manifests as an unexpected VM-Entry failure +due to an invalid code field (error number 7) in L1, e.g. when injecting +a #GP with error_code=0x9f00. + +Nadav previously reported the bug[*], both to KVM and Intel, and fixed +the associated kvm-unit-test. + +[*] https://patchwork.kernel.org/patch/11124749/ + +Reported-by: Nadav Amit +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Reviewed-by: Jim Mattson +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/x86/kvm/vmx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c +index d3a900a4fa0e7..6f7b3acdab263 100644 +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -12574,7 +12574,7 @@ static int check_vmentry_prereqs(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12) + + /* VM-entry exception error code */ + if (has_error_code && +- vmcs12->vm_entry_exception_error_code & GENMASK(31, 15)) ++ vmcs12->vm_entry_exception_error_code & GENMASK(31, 16)) + return VMXERR_ENTRY_INVALID_CONTROL_FIELD; + + /* VM-entry interruption-info field: reserved bits */ +-- +2.20.1 + diff --git a/queue-4.19/kvm-ppc-book3s-hv-xive-free-escalation-interrupts-be.patch b/queue-4.19/kvm-ppc-book3s-hv-xive-free-escalation-interrupts-be.patch new file mode 100644 index 00000000000..969929da1ef --- /dev/null +++ b/queue-4.19/kvm-ppc-book3s-hv-xive-free-escalation-interrupts-be.patch @@ -0,0 +1,86 @@ +From eb3d10a4e89ad025ddaaa1e223e666c4c2d702c7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 6 Aug 2019 19:25:38 +0200 +Subject: KVM: PPC: Book3S HV: XIVE: Free escalation interrupts before + disabling the VP +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Cédric Le Goater + +[ Upstream commit 237aed48c642328ff0ab19b63423634340224a06 ] + +When a vCPU is brought done, the XIVE VP (Virtual Processor) is first +disabled and then the event notification queues are freed. When freeing +the queues, we check for possible escalation interrupts and free them +also. + +But when a XIVE VP is disabled, the underlying XIVE ENDs also are +disabled in OPAL. When an END (Event Notification Descriptor) is +disabled, its ESB pages (ESn and ESe) are disabled and loads return all +1s. Which means that any access on the ESB page of the escalation +interrupt will return invalid values. + +When an interrupt is freed, the shutdown handler computes a 'saved_p' +field from the value returned by a load in xive_do_source_set_mask(). +This value is incorrect for escalation interrupts for the reason +described above. + +This has no impact on Linux/KVM today because we don't make use of it +but we will introduce in future changes a xive_get_irqchip_state() +handler. This handler will use the 'saved_p' field to return the state +of an interrupt and 'saved_p' being incorrect, softlockup will occur. + +Fix the vCPU cleanup sequence by first freeing the escalation interrupts +if any, then disable the XIVE VP and last free the queues. + +Fixes: 90c73795afa2 ("KVM: PPC: Book3S HV: Add a new KVM device for the XIVE native exploitation mode") +Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller") +Cc: stable@vger.kernel.org # v4.12+ +Signed-off-by: Cédric Le Goater +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20190806172538.5087-1-clg@kaod.org +Signed-off-by: Sasha Levin +--- + arch/powerpc/kvm/book3s_xive.c | 18 ++++++++++-------- + 1 file changed, 10 insertions(+), 8 deletions(-) + +diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c +index aae34f218ab45..031f07f048afd 100644 +--- a/arch/powerpc/kvm/book3s_xive.c ++++ b/arch/powerpc/kvm/book3s_xive.c +@@ -1037,20 +1037,22 @@ void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu) + /* Mask the VP IPI */ + xive_vm_esb_load(&xc->vp_ipi_data, XIVE_ESB_SET_PQ_01); + +- /* Disable the VP */ +- xive_native_disable_vp(xc->vp_id); +- +- /* Free the queues & associated interrupts */ ++ /* Free escalations */ + for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) { +- struct xive_q *q = &xc->queues[i]; +- +- /* Free the escalation irq */ + if (xc->esc_virq[i]) { + free_irq(xc->esc_virq[i], vcpu); + irq_dispose_mapping(xc->esc_virq[i]); + kfree(xc->esc_virq_names[i]); + } +- /* Free the queue */ ++ } ++ ++ /* Disable the VP */ ++ xive_native_disable_vp(xc->vp_id); ++ ++ /* Free the queues */ ++ for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) { ++ struct xive_q *q = &xc->queues[i]; ++ + xive_native_disable_queue(xc->vp_id, q, i); + if (q->qpage) { + free_pages((unsigned long)q->qpage, +-- +2.20.1 + diff --git a/queue-4.19/libnvdimm-nfit_test-fix-acpi_handle-redefinition.patch b/queue-4.19/libnvdimm-nfit_test-fix-acpi_handle-redefinition.patch new file mode 100644 index 00000000000..51a003fcacc --- /dev/null +++ b/queue-4.19/libnvdimm-nfit_test-fix-acpi_handle-redefinition.patch @@ -0,0 +1,70 @@ +From b4240915ad25a5ccad36391c5ee8378b29e52bd7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 17 Sep 2019 21:21:49 -0700 +Subject: libnvdimm/nfit_test: Fix acpi_handle redefinition + +From: Nathan Chancellor + +[ Upstream commit 59f08896f058a92f03a0041b397a1a227c5e8529 ] + +After commit 62974fc389b3 ("libnvdimm: Enable unit test infrastructure +compile checks"), clang warns: + +In file included from +../drivers/nvdimm/../../tools/testing/nvdimm/test/iomap.c:15: +../drivers/nvdimm/../../tools/testing/nvdimm/test/nfit_test.h:206:15: +warning: redefinition of typedef 'acpi_handle' is a C11 feature +[-Wtypedef-redefinition] +typedef void *acpi_handle; + ^ +../include/acpi/actypes.h:424:15: note: previous definition is here +typedef void *acpi_handle; /* Actually a ptr to a NS Node */ + ^ +1 warning generated. + +The include chain: + +iomap.c -> + linux/acpi.h -> + acpi/acpi.h -> + acpi/actypes.h + nfit_test.h + +Avoid this by including linux/acpi.h in nfit_test.h, which allows us to +remove both the typedef and the forward declaration of acpi_object. + +Link: https://github.com/ClangBuiltLinux/linux/issues/660 +Signed-off-by: Nathan Chancellor +Reviewed-by: Ira Weiny +Link: https://lore.kernel.org/r/20190918042148.77553-1-natechancellor@gmail.com +Signed-off-by: Dan Williams +Signed-off-by: Sasha Levin +--- + tools/testing/nvdimm/test/nfit_test.h | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +diff --git a/tools/testing/nvdimm/test/nfit_test.h b/tools/testing/nvdimm/test/nfit_test.h +index 33752e06ff8d0..3de57cc8716b9 100644 +--- a/tools/testing/nvdimm/test/nfit_test.h ++++ b/tools/testing/nvdimm/test/nfit_test.h +@@ -12,6 +12,7 @@ + */ + #ifndef __NFIT_TEST_H__ + #define __NFIT_TEST_H__ ++#include + #include + #include + #include +@@ -234,9 +235,6 @@ struct nd_intel_lss { + __u32 status; + } __packed; + +-union acpi_object; +-typedef void *acpi_handle; +- + typedef struct nfit_test_resource *(*nfit_test_lookup_fn)(resource_size_t); + typedef union acpi_object *(*nfit_test_evaluate_dsm_fn)(acpi_handle handle, + const guid_t *guid, u64 rev, u64 func, +-- +2.20.1 + diff --git a/queue-4.19/libnvdimm-region-initialize-bad-block-for-volatile-n.patch b/queue-4.19/libnvdimm-region-initialize-bad-block-for-volatile-n.patch new file mode 100644 index 00000000000..9c23353cde5 --- /dev/null +++ b/queue-4.19/libnvdimm-region-initialize-bad-block-for-volatile-n.patch @@ -0,0 +1,110 @@ +From 3bbcd4c76bcb12882463be97b4b00500395ad92e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Sep 2019 14:03:55 +0530 +Subject: libnvdimm/region: Initialize bad block for volatile namespaces + +From: Aneesh Kumar K.V + +[ Upstream commit c42adf87e4e7ed77f6ffe288dc90f980d07d68df ] + +We do check for a bad block during namespace init and that use +region bad block list. We need to initialize the bad block +for volatile regions for this to work. We also observe a lockdep +warning as below because the lock is not initialized correctly +since we skip bad block init for volatile regions. + + INFO: trying to register non-static key. + the code is fine but needs lockdep annotation. + turning off the locking correctness validator. + CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc1-15699-g3dee241c937e #149 + Call Trace: + [c0000000f95cb250] [c00000000147dd84] dump_stack+0xe8/0x164 (unreliable) + [c0000000f95cb2a0] [c00000000022ccd8] register_lock_class+0x308/0xa60 + [c0000000f95cb3a0] [c000000000229cc0] __lock_acquire+0x170/0x1ff0 + [c0000000f95cb4c0] [c00000000022c740] lock_acquire+0x220/0x270 + [c0000000f95cb580] [c000000000a93230] badblocks_check+0xc0/0x290 + [c0000000f95cb5f0] [c000000000d97540] nd_pfn_validate+0x5c0/0x7f0 + [c0000000f95cb6d0] [c000000000d98300] nd_dax_probe+0xd0/0x1f0 + [c0000000f95cb760] [c000000000d9b66c] nd_pmem_probe+0x10c/0x160 + [c0000000f95cb790] [c000000000d7f5ec] nvdimm_bus_probe+0x10c/0x240 + [c0000000f95cb820] [c000000000d0f844] really_probe+0x254/0x4e0 + [c0000000f95cb8b0] [c000000000d0fdfc] driver_probe_device+0x16c/0x1e0 + [c0000000f95cb930] [c000000000d10238] device_driver_attach+0x68/0xa0 + [c0000000f95cb970] [c000000000d1040c] __driver_attach+0x19c/0x1c0 + [c0000000f95cb9f0] [c000000000d0c4c4] bus_for_each_dev+0x94/0x130 + [c0000000f95cba50] [c000000000d0f014] driver_attach+0x34/0x50 + [c0000000f95cba70] [c000000000d0e208] bus_add_driver+0x178/0x2f0 + [c0000000f95cbb00] [c000000000d117c8] driver_register+0x108/0x170 + [c0000000f95cbb70] [c000000000d7edb0] __nd_driver_register+0xe0/0x100 + [c0000000f95cbbd0] [c000000001a6baa4] nd_pmem_driver_init+0x34/0x48 + [c0000000f95cbbf0] [c0000000000106f4] do_one_initcall+0x1d4/0x4b0 + [c0000000f95cbcd0] [c0000000019f499c] kernel_init_freeable+0x544/0x65c + [c0000000f95cbdb0] [c000000000010d6c] kernel_init+0x2c/0x180 + [c0000000f95cbe20] [c00000000000b954] ret_from_kernel_thread+0x5c/0x68 + +Signed-off-by: Aneesh Kumar K.V +Link: https://lore.kernel.org/r/20190919083355.26340-1-aneesh.kumar@linux.ibm.com +Signed-off-by: Dan Williams +Signed-off-by: Sasha Levin +--- + drivers/nvdimm/bus.c | 2 +- + drivers/nvdimm/region.c | 4 ++-- + drivers/nvdimm/region_devs.c | 4 ++-- + 3 files changed, 5 insertions(+), 5 deletions(-) + +diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c +index 2ba22cd1331b0..54a633e8cb5d2 100644 +--- a/drivers/nvdimm/bus.c ++++ b/drivers/nvdimm/bus.c +@@ -189,7 +189,7 @@ static int nvdimm_clear_badblocks_region(struct device *dev, void *data) + sector_t sector; + + /* make sure device is a region */ +- if (!is_nd_pmem(dev)) ++ if (!is_memory(dev)) + return 0; + + nd_region = to_nd_region(dev); +diff --git a/drivers/nvdimm/region.c b/drivers/nvdimm/region.c +index f9130cc157e83..22224b21c34df 100644 +--- a/drivers/nvdimm/region.c ++++ b/drivers/nvdimm/region.c +@@ -42,7 +42,7 @@ static int nd_region_probe(struct device *dev) + if (rc) + return rc; + +- if (is_nd_pmem(&nd_region->dev)) { ++ if (is_memory(&nd_region->dev)) { + struct resource ndr_res; + + if (devm_init_badblocks(dev, &nd_region->bb)) +@@ -131,7 +131,7 @@ static void nd_region_notify(struct device *dev, enum nvdimm_event event) + struct nd_region *nd_region = to_nd_region(dev); + struct resource res; + +- if (is_nd_pmem(&nd_region->dev)) { ++ if (is_memory(&nd_region->dev)) { + res.start = nd_region->ndr_start; + res.end = nd_region->ndr_start + + nd_region->ndr_size - 1; +diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c +index 0303296e6d5b6..609fc450522a1 100644 +--- a/drivers/nvdimm/region_devs.c ++++ b/drivers/nvdimm/region_devs.c +@@ -633,11 +633,11 @@ static umode_t region_visible(struct kobject *kobj, struct attribute *a, int n) + if (!is_memory(dev) && a == &dev_attr_dax_seed.attr) + return 0; + +- if (!is_nd_pmem(dev) && a == &dev_attr_badblocks.attr) ++ if (!is_memory(dev) && a == &dev_attr_badblocks.attr) + return 0; + + if (a == &dev_attr_resource.attr) { +- if (is_nd_pmem(dev)) ++ if (is_memory(dev)) + return 0400; + else + return 0; +-- +2.20.1 + diff --git a/queue-4.19/nbd-fix-crash-when-the-blksize-is-zero.patch b/queue-4.19/nbd-fix-crash-when-the-blksize-is-zero.patch new file mode 100644 index 00000000000..1927df7d9c8 --- /dev/null +++ b/queue-4.19/nbd-fix-crash-when-the-blksize-is-zero.patch @@ -0,0 +1,87 @@ +From 5e5d558fb1ead1a84238b4461d890471b8cec235 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 29 May 2019 15:16:05 -0500 +Subject: nbd: fix crash when the blksize is zero + +From: Xiubo Li + +[ Upstream commit 553768d1169a48c0cd87c4eb4ab57534ee663415 ] + +This will allow the blksize to be set zero and then use 1024 as +default. + +Reviewed-by: Josef Bacik +Signed-off-by: Xiubo Li +[fix to use goto out instead of return in genl_connect] +Signed-off-by: Mike Christie +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + drivers/block/nbd.c | 23 ++++++++++++++++++++--- + 1 file changed, 20 insertions(+), 3 deletions(-) + +diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c +index 21f54c7946a0e..bc2fa4e85f0ca 100644 +--- a/drivers/block/nbd.c ++++ b/drivers/block/nbd.c +@@ -133,6 +133,8 @@ static struct dentry *nbd_dbg_dir; + + #define NBD_MAGIC 0x68797548 + ++#define NBD_DEF_BLKSIZE 1024 ++ + static unsigned int nbds_max = 16; + static int max_part = 16; + static int part_shift; +@@ -1241,6 +1243,14 @@ static void nbd_clear_sock_ioctl(struct nbd_device *nbd, + nbd_config_put(nbd); + } + ++static bool nbd_is_valid_blksize(unsigned long blksize) ++{ ++ if (!blksize || !is_power_of_2(blksize) || blksize < 512 || ++ blksize > PAGE_SIZE) ++ return false; ++ return true; ++} ++ + /* Must be called with config_lock held */ + static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd, + unsigned int cmd, unsigned long arg) +@@ -1256,8 +1266,9 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd, + case NBD_SET_SOCK: + return nbd_add_socket(nbd, arg, false); + case NBD_SET_BLKSIZE: +- if (!arg || !is_power_of_2(arg) || arg < 512 || +- arg > PAGE_SIZE) ++ if (!arg) ++ arg = NBD_DEF_BLKSIZE; ++ if (!nbd_is_valid_blksize(arg)) + return -EINVAL; + nbd_size_set(nbd, arg, + div_s64(config->bytesize, arg)); +@@ -1337,7 +1348,7 @@ static struct nbd_config *nbd_alloc_config(void) + atomic_set(&config->recv_threads, 0); + init_waitqueue_head(&config->recv_wq); + init_waitqueue_head(&config->conn_wait); +- config->blksize = 1024; ++ config->blksize = NBD_DEF_BLKSIZE; + atomic_set(&config->live_connections, 0); + try_module_get(THIS_MODULE); + return config; +@@ -1773,6 +1784,12 @@ static int nbd_genl_connect(struct sk_buff *skb, struct genl_info *info) + if (info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES]) { + u64 bsize = + nla_get_u64(info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES]); ++ if (!bsize) ++ bsize = NBD_DEF_BLKSIZE; ++ if (!nbd_is_valid_blksize(bsize)) { ++ ret = -EINVAL; ++ goto out; ++ } + nbd_size_set(nbd, bsize, div64_u64(config->bytesize, bsize)); + } + if (info->attrs[NBD_ATTR_TIMEOUT]) { +-- +2.20.1 + diff --git a/queue-4.19/netfilter-nf_tables-allow-lookups-in-dynamic-sets.patch b/queue-4.19/netfilter-nf_tables-allow-lookups-in-dynamic-sets.patch new file mode 100644 index 00000000000..53a76538f78 --- /dev/null +++ b/queue-4.19/netfilter-nf_tables-allow-lookups-in-dynamic-sets.patch @@ -0,0 +1,107 @@ +From c45ffbaadf60d9ef77f8f1e4d05d05e736d7a466 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Sep 2019 16:56:44 +0200 +Subject: netfilter: nf_tables: allow lookups in dynamic sets + +From: Florian Westphal + +[ Upstream commit acab713177377d9e0889c46bac7ff0cfb9a90c4d ] + +This un-breaks lookups in sets that have the 'dynamic' flag set. +Given this active example configuration: + +table filter { + set set1 { + type ipv4_addr + size 64 + flags dynamic,timeout + timeout 1m + } + + chain input { + type filter hook input priority 0; policy accept; + } +} + +... this works: +nft add rule ip filter input add @set1 { ip saddr } + +-> whenever rule is triggered, the source ip address is inserted +into the set (if it did not exist). + +This won't work: +nft add rule ip filter input ip saddr @set1 counter +Error: Could not process rule: Operation not supported + +In other words, we can add entries to the set, but then can't make +matching decision based on that set. + +That is just wrong -- all set backends support lookups (else they would +not be very useful). +The failure comes from an explicit rejection in nft_lookup.c. + +Looking at the history, it seems like NFT_SET_EVAL used to mean +'set contains expressions' (aka. "is a meter"), for instance something like + + nft add rule ip filter input meter example { ip saddr limit rate 10/second } + or + nft add rule ip filter input meter example { ip saddr counter } + +The actual meaning of NFT_SET_EVAL however, is +'set can be updated from the packet path'. + +'meters' and packet-path insertions into sets, such as +'add @set { ip saddr }' use exactly the same kernel code (nft_dynset.c) +and thus require a set backend that provides the ->update() function. + +The only set that provides this also is the only one that has the +NFT_SET_EVAL feature flag. + +Removing the wrong check makes the above example work. +While at it, also fix the flag check during set instantiation to +allow supported combinations only. + +Fixes: 8aeff920dcc9b3f ("netfilter: nf_tables: add stateful object reference to set elements") +Signed-off-by: Florian Westphal +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/nf_tables_api.c | 7 +++++-- + net/netfilter/nft_lookup.c | 3 --- + 2 files changed, 5 insertions(+), 5 deletions(-) + +diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c +index 2145581d7b3dc..24fddf0322790 100644 +--- a/net/netfilter/nf_tables_api.c ++++ b/net/netfilter/nf_tables_api.c +@@ -3429,8 +3429,11 @@ static int nf_tables_newset(struct net *net, struct sock *nlsk, + NFT_SET_OBJECT)) + return -EINVAL; + /* Only one of these operations is supported */ +- if ((flags & (NFT_SET_MAP | NFT_SET_EVAL | NFT_SET_OBJECT)) == +- (NFT_SET_MAP | NFT_SET_EVAL | NFT_SET_OBJECT)) ++ if ((flags & (NFT_SET_MAP | NFT_SET_OBJECT)) == ++ (NFT_SET_MAP | NFT_SET_OBJECT)) ++ return -EOPNOTSUPP; ++ if ((flags & (NFT_SET_EVAL | NFT_SET_OBJECT)) == ++ (NFT_SET_EVAL | NFT_SET_OBJECT)) + return -EOPNOTSUPP; + } + +diff --git a/net/netfilter/nft_lookup.c b/net/netfilter/nft_lookup.c +index 161c3451a747a..55754d9939b50 100644 +--- a/net/netfilter/nft_lookup.c ++++ b/net/netfilter/nft_lookup.c +@@ -76,9 +76,6 @@ static int nft_lookup_init(const struct nft_ctx *ctx, + if (IS_ERR(set)) + return PTR_ERR(set); + +- if (set->flags & NFT_SET_EVAL) +- return -EOPNOTSUPP; +- + priv->sreg = nft_parse_register(tb[NFTA_LOOKUP_SREG]); + err = nft_validate_register_load(priv->sreg, set->klen); + if (err < 0) +-- +2.20.1 + diff --git a/queue-4.19/nfp-flower-fix-memory-leak-in-nfp_flower_spawn_vnic_.patch b/queue-4.19/nfp-flower-fix-memory-leak-in-nfp_flower_spawn_vnic_.patch new file mode 100644 index 00000000000..4d353229fc6 --- /dev/null +++ b/queue-4.19/nfp-flower-fix-memory-leak-in-nfp_flower_spawn_vnic_.patch @@ -0,0 +1,36 @@ +From aa8bca3369089ac2264b86564564dbe38007d447 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 25 Sep 2019 14:05:09 -0500 +Subject: nfp: flower: fix memory leak in nfp_flower_spawn_vnic_reprs + +From: Navid Emamdoost + +[ Upstream commit 8ce39eb5a67aee25d9f05b40b673c95b23502e3e ] + +In nfp_flower_spawn_vnic_reprs in the loop if initialization or the +allocations fail memory is leaked. Appropriate releases are added. + +Fixes: b94524529741 ("nfp: flower: add per repr private data for LAG offload") +Signed-off-by: Navid Emamdoost +Acked-by: Jakub Kicinski +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/netronome/nfp/flower/main.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/ethernet/netronome/nfp/flower/main.c b/drivers/net/ethernet/netronome/nfp/flower/main.c +index 22c572a09b320..c19e88efe958d 100644 +--- a/drivers/net/ethernet/netronome/nfp/flower/main.c ++++ b/drivers/net/ethernet/netronome/nfp/flower/main.c +@@ -272,6 +272,7 @@ nfp_flower_spawn_vnic_reprs(struct nfp_app *app, + port = nfp_port_alloc(app, port_type, repr); + if (IS_ERR(port)) { + err = PTR_ERR(port); ++ kfree(repr_priv); + nfp_repr_free(repr); + goto err_reprs_clean; + } +-- +2.20.1 + diff --git a/queue-4.19/ntb-point-to-right-memory-window-index.patch b/queue-4.19/ntb-point-to-right-memory-window-index.patch new file mode 100644 index 00000000000..7697ecca517 --- /dev/null +++ b/queue-4.19/ntb-point-to-right-memory-window-index.patch @@ -0,0 +1,53 @@ +From 75c8a2b14865785369ef4f219d35654080179450 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 29 Mar 2019 11:32:50 +0000 +Subject: ntb: point to right memory window index + +From: Sanjay R Mehta + +[ Upstream commit ae89339b08f3fe02457ec9edd512ddc3d246d0f8 ] + +second parameter of ntb_peer_mw_get_addr is pointing to wrong memory +window index by passing "peer gidx" instead of "local gidx". + +For ex, "local gidx" value is '0' and "peer gidx" value is '1', then + +on peer side ntb_mw_set_trans() api is used as below with gidx pointing to +local side gidx which is '0', so memroy window '0' is chosen and XLAT '0' +will be programmed by peer side. + + ntb_mw_set_trans(perf->ntb, peer->pidx, peer->gidx, peer->inbuf_xlat, + peer->inbuf_size); + +Now, on local side ntb_peer_mw_get_addr() is been used as below with gidx +pointing to "peer gidx" which is '1', so pointing to memory window '1' +instead of memory window '0'. + + ntb_peer_mw_get_addr(perf->ntb, peer->gidx, &phys_addr, + &peer->outbuf_size); + +So this patch pass "local gidx" as parameter to ntb_peer_mw_get_addr(). + +Signed-off-by: Sanjay R Mehta +Signed-off-by: Jon Mason +Signed-off-by: Sasha Levin +--- + drivers/ntb/test/ntb_perf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c +index 2a9d6b0d1f193..80508da3c8b5c 100644 +--- a/drivers/ntb/test/ntb_perf.c ++++ b/drivers/ntb/test/ntb_perf.c +@@ -1373,7 +1373,7 @@ static int perf_setup_peer_mw(struct perf_peer *peer) + int ret; + + /* Get outbound MW parameters and map it */ +- ret = ntb_peer_mw_get_addr(perf->ntb, peer->gidx, &phys_addr, ++ ret = ntb_peer_mw_get_addr(perf->ntb, perf->gidx, &phys_addr, + &peer->outbuf_size); + if (ret) + return ret; +-- +2.20.1 + diff --git a/queue-4.19/perf-build-add-detection-of-java-11-openjdk-devel-pa.patch b/queue-4.19/perf-build-add-detection-of-java-11-openjdk-devel-pa.patch new file mode 100644 index 00000000000..f488738d77f --- /dev/null +++ b/queue-4.19/perf-build-add-detection-of-java-11-openjdk-devel-pa.patch @@ -0,0 +1,62 @@ +From 8bc7d2c084cd68c0022f357f58d37c7a99d043ce Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Sep 2019 13:41:16 +0200 +Subject: perf build: Add detection of java-11-openjdk-devel package + +From: Thomas Richter + +[ Upstream commit 815c1560bf8fd522b8d93a1d727868b910c1cc24 ] + +With Java 11 there is no seperate JRE anymore. + +Details: + + https://coderanch.com/t/701603/java/JRE-JDK + +Therefore the detection of the JRE needs to be adapted. + +This change works for s390 and x86. I have not tested other platforms. + +Committer testing: + +Continues to work with the OpenJDK 8: + + $ rm -f ~acme/lib64/libperf-jvmti.so + $ rpm -qa | grep jdk-devel + java-1.8.0-openjdk-devel-1.8.0.222.b10-0.fc30.x86_64 + $ git log --oneline -1 + a51937170f33 (HEAD -> perf/core) perf build: Add detection of java-11-openjdk-devel package + $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; make -C tools/perf O=/tmp/build/perf install > /dev/null 2>1 + $ ls -la ~acme/lib64/libperf-jvmti.so + -rwxr-xr-x. 1 acme acme 230744 Sep 24 16:46 /home/acme/lib64/libperf-jvmti.so + $ + +Suggested-by: Andreas Krebbel +Signed-off-by: Thomas Richter +Tested-by: Arnaldo Carvalho de Melo +Cc: Heiko Carstens +Cc: Hendrik Brueckner +Cc: Vasily Gorbik +Link: http://lore.kernel.org/lkml/20190909114116.50469-4-tmricht@linux.ibm.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/perf/Makefile.config | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config +index 849b3be15bd89..510caedd73194 100644 +--- a/tools/perf/Makefile.config ++++ b/tools/perf/Makefile.config +@@ -837,7 +837,7 @@ ifndef NO_JVMTI + JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | awk '{print $$3}') + else + ifneq (,$(wildcard /usr/sbin/alternatives)) +- JDIR=$(shell /usr/sbin/alternatives --display java | tail -1 | cut -d' ' -f 5 | sed 's%/jre/bin/java.%%g') ++ JDIR=$(shell /usr/sbin/alternatives --display java | tail -1 | cut -d' ' -f 5 | sed -e 's%/jre/bin/java.%%g' -e 's%/bin/java.%%g') + endif + endif + ifndef JDIR +-- +2.20.1 + diff --git a/queue-4.19/perf-stat-reset-previous-counts-on-repeat-with-inter.patch b/queue-4.19/perf-stat-reset-previous-counts-on-repeat-with-inter.patch new file mode 100644 index 00000000000..21c539a9107 --- /dev/null +++ b/queue-4.19/perf-stat-reset-previous-counts-on-repeat-with-inter.patch @@ -0,0 +1,168 @@ +From f9dff7025ec1c7f6edafd91942e8de9fddf85603 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Sep 2019 15:17:37 +0530 +Subject: perf stat: Reset previous counts on repeat with interval + +From: Srikar Dronamraju + +[ Upstream commit b63fd11cced17fcb8e133def29001b0f6aaa5e06 ] + +When using 'perf stat' with repeat and interval option, it shows wrong +values for events. + +The wrong values will be shown for the first interval on the second and +subsequent repetitions. + +Without the fix: + + # perf stat -r 3 -I 2000 -e faults -e sched:sched_switch -a sleep 5 + + 2.000282489 53 faults + 2.000282489 513 sched:sched_switch + 4.005478208 3,721 faults + 4.005478208 2,666 sched:sched_switch + 5.025470933 395 faults + 5.025470933 1,307 sched:sched_switch + 2.009602825 1,84,46,74,40,73,70,95,47,520 faults <------ + 2.009602825 1,84,46,74,40,73,70,95,49,568 sched:sched_switch <------ + 4.019612206 4,730 faults + 4.019612206 2,746 sched:sched_switch + 5.039615484 3,953 faults + 5.039615484 1,496 sched:sched_switch + 2.000274620 1,84,46,74,40,73,70,95,47,520 faults <------ + 2.000274620 1,84,46,74,40,73,70,95,47,520 sched:sched_switch <------ + 4.000480342 4,282 faults + 4.000480342 2,303 sched:sched_switch + 5.000916811 1,322 faults + 5.000916811 1,064 sched:sched_switch + # + +prev_raw_counts is allocated when using intervals. This is used when +calculating the difference in the counts of events when using interval. + +The current counts are stored in prev_raw_counts to calculate the +differences in the next iteration. + +On the first interval of the second and subsequent repetitions, +prev_raw_counts would be the values stored in the last interval of the +previous repetitions, while the current counts will only be for the +first interval of the current repetition. + +Hence there is a possibility of events showing up as big number. + +Fix this by resetting prev_raw_counts whenever perf stat repeats the +command. + +With the fix: + + # perf stat -r 3 -I 2000 -e faults -e sched:sched_switch -a sleep 5 + + 2.019349347 2,597 faults + 2.019349347 2,753 sched:sched_switch + 4.019577372 3,098 faults + 4.019577372 2,532 sched:sched_switch + 5.019415481 1,879 faults + 5.019415481 1,356 sched:sched_switch + 2.000178813 8,468 faults + 2.000178813 2,254 sched:sched_switch + 4.000404621 7,440 faults + 4.000404621 1,266 sched:sched_switch + 5.040196079 2,458 faults + 5.040196079 556 sched:sched_switch + 2.000191939 6,870 faults + 2.000191939 1,170 sched:sched_switch + 4.000414103 541 faults + 4.000414103 902 sched:sched_switch + 5.000809863 450 faults + 5.000809863 364 sched:sched_switch + # + +Committer notes: + +This was broken since the cset introducing the --interval feature, i.e. +--repeat + --interval wasn't tested at that point, add the Fixes tag so +that automatic scripts can pick this up. + +Fixes: 13370a9b5bb8 ("perf stat: Add interval printing") +Signed-off-by: Srikar Dronamraju +Acked-by: Jiri Olsa +Tested-by: Arnaldo Carvalho de Melo +Tested-by: Ravi Bangoria +Cc: Namhyung Kim +Cc: Naveen N. Rao +Cc: Stephane Eranian +Cc: stable@vger.kernel.org # v3.9+ +Link: http://lore.kernel.org/lkml/20190904094738.9558-2-srikar@linux.vnet.ibm.com +[ Fixed up conflicts with libperf, i.e. some perf_{evsel,evlist} lost the 'perf' prefix ] +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/perf/builtin-stat.c | 3 +++ + tools/perf/util/stat.c | 17 +++++++++++++++++ + tools/perf/util/stat.h | 1 + + 3 files changed, 21 insertions(+) + +diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c +index 11650910e089a..6aae10ff954c7 100644 +--- a/tools/perf/builtin-stat.c ++++ b/tools/perf/builtin-stat.c +@@ -3090,6 +3090,9 @@ int cmd_stat(int argc, const char **argv) + fprintf(output, "[ perf stat: executing run #%d ... ]\n", + run_idx + 1); + ++ if (run_idx != 0) ++ perf_evlist__reset_prev_raw_counts(evsel_list); ++ + status = run_perf_stat(argc, argv, run_idx); + if (forever && status != -1 && !interval) { + print_counters(NULL, argc, argv); +diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c +index a0061e0b0fade..6917ba8a00240 100644 +--- a/tools/perf/util/stat.c ++++ b/tools/perf/util/stat.c +@@ -154,6 +154,15 @@ static void perf_evsel__free_prev_raw_counts(struct perf_evsel *evsel) + evsel->prev_raw_counts = NULL; + } + ++static void perf_evsel__reset_prev_raw_counts(struct perf_evsel *evsel) ++{ ++ if (evsel->prev_raw_counts) { ++ evsel->prev_raw_counts->aggr.val = 0; ++ evsel->prev_raw_counts->aggr.ena = 0; ++ evsel->prev_raw_counts->aggr.run = 0; ++ } ++} ++ + static int perf_evsel__alloc_stats(struct perf_evsel *evsel, bool alloc_raw) + { + int ncpus = perf_evsel__nr_cpus(evsel); +@@ -204,6 +213,14 @@ void perf_evlist__reset_stats(struct perf_evlist *evlist) + } + } + ++void perf_evlist__reset_prev_raw_counts(struct perf_evlist *evlist) ++{ ++ struct perf_evsel *evsel; ++ ++ evlist__for_each_entry(evlist, evsel) ++ perf_evsel__reset_prev_raw_counts(evsel); ++} ++ + static void zero_per_pkg(struct perf_evsel *counter) + { + if (counter->per_pkg_mask) +diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h +index 36efb986f7fc6..e19abb1635c4e 100644 +--- a/tools/perf/util/stat.h ++++ b/tools/perf/util/stat.h +@@ -158,6 +158,7 @@ void perf_stat__collect_metric_expr(struct perf_evlist *); + int perf_evlist__alloc_stats(struct perf_evlist *evlist, bool alloc_raw); + void perf_evlist__free_stats(struct perf_evlist *evlist); + void perf_evlist__reset_stats(struct perf_evlist *evlist); ++void perf_evlist__reset_prev_raw_counts(struct perf_evlist *evlist); + + int perf_stat_process_counter(struct perf_stat_config *config, + struct perf_evsel *counter); +-- +2.20.1 + diff --git a/queue-4.19/perf-tools-fix-segfault-in-cpu_cache_level__read.patch b/queue-4.19/perf-tools-fix-segfault-in-cpu_cache_level__read.patch new file mode 100644 index 00000000000..caa89d491c8 --- /dev/null +++ b/queue-4.19/perf-tools-fix-segfault-in-cpu_cache_level__read.patch @@ -0,0 +1,63 @@ +From fd5e773aaed35e42f82f7a1e87b4990d9fa4b5c1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 12 Sep 2019 12:52:35 +0200 +Subject: perf tools: Fix segfault in cpu_cache_level__read() + +From: Jiri Olsa + +[ Upstream commit 0216234c2eed1367a318daeb9f4a97d8217412a0 ] + +We release wrong pointer on error path in cpu_cache_level__read +function, leading to segfault: + + (gdb) r record ls + Starting program: /root/perf/tools/perf/perf record ls + ... + [ perf record: Woken up 1 times to write data ] + double free or corruption (out) + + Thread 1 "perf" received signal SIGABRT, Aborted. + 0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6 + (gdb) bt + #0 0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6 + #1 0x00007ffff7443bac in abort () from /lib64/power9/libc.so.6 + #2 0x00007ffff74af8bc in __libc_message () from /lib64/power9/libc.so.6 + #3 0x00007ffff74b92b8 in malloc_printerr () from /lib64/power9/libc.so.6 + #4 0x00007ffff74bb874 in _int_free () from /lib64/power9/libc.so.6 + #5 0x0000000010271260 in __zfree (ptr=0x7fffffffa0b0) at ../../lib/zalloc.. + #6 0x0000000010139340 in cpu_cache_level__read (cache=0x7fffffffa090, cac.. + #7 0x0000000010143c90 in build_caches (cntp=0x7fffffffa118, size= +Cc: Alexander Shishkin +Cc: Michael Petlan +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org: # v4.6+ +Link: http://lore.kernel.org/lkml/20190912105235.10689-1-jolsa@kernel.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/perf/util/header.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c +index 0c70788593c8d..3c0d74fc1ff26 100644 +--- a/tools/perf/util/header.c ++++ b/tools/perf/util/header.c +@@ -1114,7 +1114,7 @@ static int cpu_cache_level__read(struct cpu_cache_level *cache, u32 cpu, u16 lev + + scnprintf(file, PATH_MAX, "%s/shared_cpu_list", path); + if (sysfs__read_str(file, &cache->map, &len)) { +- free(cache->map); ++ free(cache->size); + free(cache->type); + return -1; + } +-- +2.20.1 + diff --git a/queue-4.19/perf-unwind-fix-libunwind-build-failure-on-i386-syst.patch b/queue-4.19/perf-unwind-fix-libunwind-build-failure-on-i386-syst.patch new file mode 100644 index 00000000000..af1fc9b3aec --- /dev/null +++ b/queue-4.19/perf-unwind-fix-libunwind-build-failure-on-i386-syst.patch @@ -0,0 +1,51 @@ +From d7de3a8e62888e22465a9b21a38faaf8c35da18c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Sep 2019 14:36:48 -0300 +Subject: perf unwind: Fix libunwind build failure on i386 systems + +From: Arnaldo Carvalho de Melo + +[ Upstream commit 26acf400d2dcc72c7e713e1f55db47ad92010cc2 ] + +Naresh Kamboju reported, that on the i386 build pr_err() +doesn't get defined properly due to header ordering: + + perf-in.o: In function `libunwind__x86_reg_id': + tools/perf/util/libunwind/../../arch/x86/util/unwind-libunwind.c:109: + undefined reference to `pr_err' + +Reported-by: Naresh Kamboju +Signed-off-by: Arnaldo Carvalho de Melo +Cc: David Ahern +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + tools/perf/arch/x86/util/unwind-libunwind.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tools/perf/arch/x86/util/unwind-libunwind.c b/tools/perf/arch/x86/util/unwind-libunwind.c +index 05920e3edf7a7..47357973b55b2 100644 +--- a/tools/perf/arch/x86/util/unwind-libunwind.c ++++ b/tools/perf/arch/x86/util/unwind-libunwind.c +@@ -1,11 +1,11 @@ + // SPDX-License-Identifier: GPL-2.0 + + #include ++#include "../../util/debug.h" + #ifndef REMOTE_UNWIND_LIBUNWIND + #include + #include "perf_regs.h" + #include "../../util/unwind.h" +-#include "../../util/debug.h" + #endif + + #ifdef HAVE_ARCH_X86_64_SUPPORT +-- +2.20.1 + diff --git a/queue-4.19/pnfs-ensure-we-do-clear-the-return-on-close-layout-s.patch b/queue-4.19/pnfs-ensure-we-do-clear-the-return-on-close-layout-s.patch new file mode 100644 index 00000000000..72985fd29af --- /dev/null +++ b/queue-4.19/pnfs-ensure-we-do-clear-the-return-on-close-layout-s.patch @@ -0,0 +1,48 @@ +From 70c91c4767b2de864aae7bf66ae5dbe271f621fc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 20 Sep 2019 07:23:40 -0400 +Subject: pNFS: Ensure we do clear the return-on-close layout stateid on fatal + errors + +From: Trond Myklebust + +[ Upstream commit 9c47b18cf722184f32148784189fca945a7d0561 ] + +IF the server rejected our layout return with a state error such as +NFS4ERR_BAD_STATEID, or even a stale inode error, then we do want +to clear out all the remaining layout segments and mark that stateid +as invalid. + +Fixes: 1c5bd76d17cca ("pNFS: Enable layoutreturn operation for...") +Signed-off-by: Trond Myklebust +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/pnfs.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c +index 4931c3a75f038..c818f9886f618 100644 +--- a/fs/nfs/pnfs.c ++++ b/fs/nfs/pnfs.c +@@ -1426,10 +1426,15 @@ void pnfs_roc_release(struct nfs4_layoutreturn_args *args, + const nfs4_stateid *res_stateid = NULL; + struct nfs4_xdr_opaque_data *ld_private = args->ld_private; + +- if (ret == 0) { +- arg_stateid = &args->stateid; ++ switch (ret) { ++ case -NFS4ERR_NOMATCHING_LAYOUT: ++ break; ++ case 0: + if (res->lrs_present) + res_stateid = &res->stateid; ++ /* Fallthrough */ ++ default: ++ arg_stateid = &args->stateid; + } + pnfs_layoutreturn_free_lsegs(lo, arg_stateid, &args->range, + res_stateid); +-- +2.20.1 + diff --git a/queue-4.19/powerpc-book3s64-radix-rename-cpu_ftr_p9_tlbie_bug-f.patch b/queue-4.19/powerpc-book3s64-radix-rename-cpu_ftr_p9_tlbie_bug-f.patch new file mode 100644 index 00000000000..92291fc91da --- /dev/null +++ b/queue-4.19/powerpc-book3s64-radix-rename-cpu_ftr_p9_tlbie_bug-f.patch @@ -0,0 +1,119 @@ +From 539ad4342a8b3d1b496a5421f2ea298025d7c6e7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 24 Sep 2019 09:22:52 +0530 +Subject: powerpc/book3s64/radix: Rename CPU_FTR_P9_TLBIE_BUG feature flag + +From: Aneesh Kumar K.V + +Rename the #define to indicate this is related to store vs tlbie +ordering issue. In the next patch, we will be adding another feature +flag that is used to handles ERAT flush vs tlbie ordering issue. + +Fixes: a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9") +Cc: stable@vger.kernel.org # v4.16+ +Signed-off-by: Aneesh Kumar K.V +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20190924035254.24612-2-aneesh.kumar@linux.ibm.com +--- + arch/powerpc/include/asm/cputable.h | 4 ++-- + arch/powerpc/kernel/dt_cpu_ftrs.c | 6 +++--- + arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +- + arch/powerpc/mm/hash_native_64.c | 2 +- + arch/powerpc/mm/tlb-radix.c | 4 ++-- + 5 files changed, 9 insertions(+), 9 deletions(-) + +diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h +index 29f49a35d6eec..6a6804c2e1b08 100644 +--- a/arch/powerpc/include/asm/cputable.h ++++ b/arch/powerpc/include/asm/cputable.h +@@ -212,7 +212,7 @@ static inline void cpu_feature_keys_init(void) { } + #define CPU_FTR_POWER9_DD2_1 LONG_ASM_CONST(0x0000080000000000) + #define CPU_FTR_P9_TM_HV_ASSIST LONG_ASM_CONST(0x0000100000000000) + #define CPU_FTR_P9_TM_XER_SO_BUG LONG_ASM_CONST(0x0000200000000000) +-#define CPU_FTR_P9_TLBIE_BUG LONG_ASM_CONST(0x0000400000000000) ++#define CPU_FTR_P9_TLBIE_STQ_BUG LONG_ASM_CONST(0x0000400000000000) + #define CPU_FTR_P9_TIDR LONG_ASM_CONST(0x0000800000000000) + + #ifndef __ASSEMBLY__ +@@ -460,7 +460,7 @@ static inline void cpu_feature_keys_init(void) { } + CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \ + CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \ + CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \ +- CPU_FTR_P9_TLBIE_BUG | CPU_FTR_P9_TIDR) ++ CPU_FTR_P9_TLBIE_STQ_BUG | CPU_FTR_P9_TIDR) + #define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9 + #define CPU_FTRS_POWER9_DD2_1 (CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD2_1) + #define CPU_FTRS_POWER9_DD2_2 (CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD2_1 | \ +diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c +index 2fdc08ab6b9e2..f3b8e04eca9c3 100644 +--- a/arch/powerpc/kernel/dt_cpu_ftrs.c ++++ b/arch/powerpc/kernel/dt_cpu_ftrs.c +@@ -708,14 +708,14 @@ static __init void update_tlbie_feature_flag(unsigned long pvr) + if ((pvr & 0xe000) == 0) { + /* Nimbus */ + if ((pvr & 0xfff) < 0x203) +- cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG; ++ cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_STQ_BUG; + } else if ((pvr & 0xc000) == 0) { + /* Cumulus */ + if ((pvr & 0xfff) < 0x103) +- cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG; ++ cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_STQ_BUG; + } else { + WARN_ONCE(1, "Unknown PVR"); +- cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG; ++ cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_STQ_BUG; + } + } + } +diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c +index a67cf1cdeda40..7c68d834c94a7 100644 +--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c ++++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c +@@ -452,7 +452,7 @@ static void do_tlbies(struct kvm *kvm, unsigned long *rbvalues, + "r" (rbvalues[i]), "r" (kvm->arch.lpid)); + } + +- if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG)) { ++ if (cpu_has_feature(CPU_FTR_P9_TLBIE_STQ_BUG)) { + /* + * Need the extra ptesync to make sure we don't + * re-order the tlbie +diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c +index aaa28fd918fe4..0c13561d8b807 100644 +--- a/arch/powerpc/mm/hash_native_64.c ++++ b/arch/powerpc/mm/hash_native_64.c +@@ -203,7 +203,7 @@ static inline unsigned long ___tlbie(unsigned long vpn, int psize, + + static inline void fixup_tlbie(unsigned long vpn, int psize, int apsize, int ssize) + { +- if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG)) { ++ if (cpu_has_feature(CPU_FTR_P9_TLBIE_STQ_BUG)) { + /* Need the extra ptesync to ensure we don't reorder tlbie*/ + asm volatile("ptesync": : :"memory"); + ___tlbie(vpn, psize, apsize, ssize); +diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c +index fef3e1eb3a199..0cddae4263f96 100644 +--- a/arch/powerpc/mm/tlb-radix.c ++++ b/arch/powerpc/mm/tlb-radix.c +@@ -220,7 +220,7 @@ static inline void fixup_tlbie(void) + unsigned long pid = 0; + unsigned long va = ((1UL << 52) - 1); + +- if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG)) { ++ if (cpu_has_feature(CPU_FTR_P9_TLBIE_STQ_BUG)) { + asm volatile("ptesync": : :"memory"); + __tlbie_va(va, pid, mmu_get_ap(MMU_PAGE_64K), RIC_FLUSH_TLB); + } +@@ -230,7 +230,7 @@ static inline void fixup_tlbie_lpid(unsigned long lpid) + { + unsigned long va = ((1UL << 52) - 1); + +- if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG)) { ++ if (cpu_has_feature(CPU_FTR_P9_TLBIE_STQ_BUG)) { + asm volatile("ptesync": : :"memory"); + __tlbie_lpid_va(va, lpid, mmu_get_ap(MMU_PAGE_64K), RIC_FLUSH_TLB); + } +-- +2.20.1 + diff --git a/queue-4.19/powerpc-pseries-fix-cpu_hotplug_lock-acquisition-in-.patch b/queue-4.19/powerpc-pseries-fix-cpu_hotplug_lock-acquisition-in-.patch new file mode 100644 index 00000000000..b7349a268ef --- /dev/null +++ b/queue-4.19/powerpc-pseries-fix-cpu_hotplug_lock-acquisition-in-.patch @@ -0,0 +1,176 @@ +From aca7848ddbf2ccf24dc7bf1a13245fe81b5b563a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 15 May 2019 13:15:52 +0530 +Subject: powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt() + +From: Gautham R. Shenoy + +[ Upstream commit c784be435d5dae28d3b03db31753dd7a18733f0c ] + +The calls to arch_add_memory()/arch_remove_memory() are always made +with the read-side cpu_hotplug_lock acquired via memory_hotplug_begin(). +On pSeries, arch_add_memory()/arch_remove_memory() eventually call +resize_hpt() which in turn calls stop_machine() which acquires the +read-side cpu_hotplug_lock again, thereby resulting in the recursive +acquisition of this lock. + +In the absence of CONFIG_PROVE_LOCKING, we hadn't observed a system +lockup during a memory hotplug operation because cpus_read_lock() is a +per-cpu rwsem read, which, in the fast-path (in the absence of the +writer, which in our case is a CPU-hotplug operation) simply +increments the read_count on the semaphore. Thus a recursive read in +the fast-path doesn't cause any problems. + +However, we can hit this problem in practice if there is a concurrent +CPU-Hotplug operation in progress which is waiting to acquire the +write-side of the lock. This will cause the second recursive read to +block until the writer finishes. While the writer is blocked since the +first read holds the lock. Thus both the reader as well as the writers +fail to make any progress thereby blocking both CPU-Hotplug as well as +Memory Hotplug operations. + +Memory-Hotplug CPU-Hotplug +CPU 0 CPU 1 +------ ------ + +1. down_read(cpu_hotplug_lock.rw_sem) + [memory_hotplug_begin] + 2. down_write(cpu_hotplug_lock.rw_sem) + [cpu_up/cpu_down] +3. down_read(cpu_hotplug_lock.rw_sem) + [stop_machine()] + +Lockdep complains as follows in these code-paths. + + swapper/0/1 is trying to acquire lock: + (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: stop_machine+0x2c/0x60 + +but task is already holding lock: +(____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: mem_hotplug_begin+0x20/0x50 + + other info that might help us debug this: + Possible unsafe locking scenario: + + CPU0 + ---- + lock(cpu_hotplug_lock.rw_sem); + lock(cpu_hotplug_lock.rw_sem); + + *** DEADLOCK *** + + May be due to missing lock nesting notation + + 3 locks held by swapper/0/1: + #0: (____ptrval____) (&dev->mutex){....}, at: __driver_attach+0x12c/0x1b0 + #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: mem_hotplug_begin+0x20/0x50 + #2: (____ptrval____) (mem_hotplug_lock.rw_sem){++++}, at: percpu_down_write+0x54/0x1a0 + +stack backtrace: + CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc5-58373-gbc99402235f3-dirty #166 + Call Trace: + dump_stack+0xe8/0x164 (unreliable) + __lock_acquire+0x1110/0x1c70 + lock_acquire+0x240/0x290 + cpus_read_lock+0x64/0xf0 + stop_machine+0x2c/0x60 + pseries_lpar_resize_hpt+0x19c/0x2c0 + resize_hpt_for_hotplug+0x70/0xd0 + arch_add_memory+0x58/0xfc + devm_memremap_pages+0x5e8/0x8f0 + pmem_attach_disk+0x764/0x830 + nvdimm_bus_probe+0x118/0x240 + really_probe+0x230/0x4b0 + driver_probe_device+0x16c/0x1e0 + __driver_attach+0x148/0x1b0 + bus_for_each_dev+0x90/0x130 + driver_attach+0x34/0x50 + bus_add_driver+0x1a8/0x360 + driver_register+0x108/0x170 + __nd_driver_register+0xd0/0xf0 + nd_pmem_driver_init+0x34/0x48 + do_one_initcall+0x1e0/0x45c + kernel_init_freeable+0x540/0x64c + kernel_init+0x2c/0x160 + ret_from_kernel_thread+0x5c/0x68 + +Fix this issue by + 1) Requiring all the calls to pseries_lpar_resize_hpt() be made + with cpu_hotplug_lock held. + + 2) In pseries_lpar_resize_hpt() invoke stop_machine_cpuslocked() + as a consequence of 1) + + 3) To satisfy 1), in hpt_order_set(), call mmu_hash_ops.resize_hpt() + with cpu_hotplug_lock held. + +Fixes: dbcf929c0062 ("powerpc/pseries: Add support for hash table resizing") +Cc: stable@vger.kernel.org # v4.11+ +Reported-by: Aneesh Kumar K.V +Signed-off-by: Gautham R. Shenoy +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/1557906352-29048-1-git-send-email-ego@linux.vnet.ibm.com +Signed-off-by: Sasha Levin +--- + arch/powerpc/mm/hash_utils_64.c | 9 ++++++++- + arch/powerpc/platforms/pseries/lpar.c | 8 ++++++-- + 2 files changed, 14 insertions(+), 3 deletions(-) + +diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c +index 29fd8940867e5..b1007e9a31ba7 100644 +--- a/arch/powerpc/mm/hash_utils_64.c ++++ b/arch/powerpc/mm/hash_utils_64.c +@@ -37,6 +37,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -1891,10 +1892,16 @@ static int hpt_order_get(void *data, u64 *val) + + static int hpt_order_set(void *data, u64 val) + { ++ int ret; ++ + if (!mmu_hash_ops.resize_hpt) + return -ENODEV; + +- return mmu_hash_ops.resize_hpt(val); ++ cpus_read_lock(); ++ ret = mmu_hash_ops.resize_hpt(val); ++ cpus_read_unlock(); ++ ++ return ret; + } + + DEFINE_SIMPLE_ATTRIBUTE(fops_hpt_order, hpt_order_get, hpt_order_set, "%llu\n"); +diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c +index 9e52b686a8fa4..ea602f7f97ce1 100644 +--- a/arch/powerpc/platforms/pseries/lpar.c ++++ b/arch/powerpc/platforms/pseries/lpar.c +@@ -647,7 +647,10 @@ static int pseries_lpar_resize_hpt_commit(void *data) + return 0; + } + +-/* Must be called in user context */ ++/* ++ * Must be called in process context. The caller must hold the ++ * cpus_lock. ++ */ + static int pseries_lpar_resize_hpt(unsigned long shift) + { + struct hpt_resize_state state = { +@@ -699,7 +702,8 @@ static int pseries_lpar_resize_hpt(unsigned long shift) + + t1 = ktime_get(); + +- rc = stop_machine(pseries_lpar_resize_hpt_commit, &state, NULL); ++ rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit, ++ &state, NULL); + + t2 = ktime_get(); + +-- +2.20.1 + diff --git a/queue-4.19/pwm-stm32-lp-add-check-in-case-requested-period-cann.patch b/queue-4.19/pwm-stm32-lp-add-check-in-case-requested-period-cann.patch new file mode 100644 index 00000000000..b6e8f026c67 --- /dev/null +++ b/queue-4.19/pwm-stm32-lp-add-check-in-case-requested-period-cann.patch @@ -0,0 +1,49 @@ +From a8845e5daf0370390b9f861b10219ec4babd8fa6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 18 Sep 2019 16:54:21 +0200 +Subject: pwm: stm32-lp: Add check in case requested period cannot be achieved +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Fabrice Gasnier + +[ Upstream commit c91e3234c6035baf5a79763cb4fcd5d23ce75c2b ] + +LPTimer can use a 32KHz clock for counting. It depends on clock tree +configuration. In such a case, PWM output frequency range is limited. +Although unlikely, nothing prevents user from requesting a PWM frequency +above counting clock (32KHz for instance): +- This causes (prd - 1) = 0xffff to be written in ARR register later in +the apply() routine. +This results in badly configured PWM period (and also duty_cycle). +Add a check to report an error is such a case. + +Signed-off-by: Fabrice Gasnier +Reviewed-by: Uwe Kleine-König +Signed-off-by: Thierry Reding +Signed-off-by: Sasha Levin +--- + drivers/pwm/pwm-stm32-lp.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c +index 0059b24cfdc3c..28e1f64134763 100644 +--- a/drivers/pwm/pwm-stm32-lp.c ++++ b/drivers/pwm/pwm-stm32-lp.c +@@ -58,6 +58,12 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm, + /* Calculate the period and prescaler value */ + div = (unsigned long long)clk_get_rate(priv->clk) * state->period; + do_div(div, NSEC_PER_SEC); ++ if (!div) { ++ /* Clock is too slow to achieve requested period. */ ++ dev_dbg(priv->chip.dev, "Can't reach %u ns\n", state->period); ++ return -EINVAL; ++ } ++ + prd = div; + while (div > STM32_LPTIM_MAX_ARR) { + presc++; +-- +2.20.1 + diff --git a/queue-4.19/riscv-avoid-interrupts-being-erroneously-enabled-in-.patch b/queue-4.19/riscv-avoid-interrupts-being-erroneously-enabled-in-.patch new file mode 100644 index 00000000000..dd1134176c9 --- /dev/null +++ b/queue-4.19/riscv-avoid-interrupts-being-erroneously-enabled-in-.patch @@ -0,0 +1,62 @@ +From 2a3a4d3797da24bb3c9f12a404825d908ae618cc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 16 Sep 2019 16:47:41 +0800 +Subject: riscv: Avoid interrupts being erroneously enabled in + handle_exception() + +From: Vincent Chen + +[ Upstream commit c82dd6d078a2bb29d41eda032bb96d05699a524d ] + +When the handle_exception function addresses an exception, the interrupts +will be unconditionally enabled after finishing the context save. However, +It may erroneously enable the interrupts if the interrupts are disabled +before entering the handle_exception. + +For example, one of the WARN_ON() condition is satisfied in the scheduling +where the interrupt is disabled and rq.lock is locked. The WARN_ON will +trigger a break exception and the handle_exception function will enable the +interrupts before entering do_trap_break function. During the procedure, if +a timer interrupt is pending, it will be taken when interrupts are enabled. +In this case, it may cause a deadlock problem if the rq.lock is locked +again in the timer ISR. + +Hence, the handle_exception() can only enable interrupts when the state of +sstatus.SPIE is 1. + +This patch is tested on HiFive Unleashed board. + +Signed-off-by: Vincent Chen +Reviewed-by: Palmer Dabbelt +[paul.walmsley@sifive.com: updated to apply] +Fixes: bcae803a21317 ("RISC-V: Enable IRQ during exception handling") +Cc: David Abdurachmanov +Cc: stable@vger.kernel.org +Signed-off-by: Paul Walmsley +Signed-off-by: Sasha Levin +--- + arch/riscv/kernel/entry.S | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S +index fa2c08e3c05e6..a03821b2656aa 100644 +--- a/arch/riscv/kernel/entry.S ++++ b/arch/riscv/kernel/entry.S +@@ -171,9 +171,13 @@ ENTRY(handle_exception) + move a1, s4 /* scause */ + tail do_IRQ + 1: +- /* Exceptions run with interrupts enabled */ ++ /* Exceptions run with interrupts enabled or disabled ++ depending on the state of sstatus.SR_SPIE */ ++ andi t0, s1, SR_SPIE ++ beqz t0, 1f + csrs sstatus, SR_SIE + ++1: + /* Handle syscalls */ + li t0, EXC_SYSCALL + beq s4, t0, handle_syscall +-- +2.20.1 + diff --git a/queue-4.19/sched-core-fix-migration-to-invalid-cpu-in-__set_cpu.patch b/queue-4.19/sched-core-fix-migration-to-invalid-cpu-in-__set_cpu.patch new file mode 100644 index 00000000000..26f994f2ea1 --- /dev/null +++ b/queue-4.19/sched-core-fix-migration-to-invalid-cpu-in-__set_cpu.patch @@ -0,0 +1,85 @@ +From cba311118dcfb009ba67f015c719ffbc5fb43e89 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 16 Sep 2019 06:53:28 +0000 +Subject: sched/core: Fix migration to invalid CPU in __set_cpus_allowed_ptr() + +From: KeMeng Shi + +[ Upstream commit 714e501e16cd473538b609b3e351b2cc9f7f09ed ] + +An oops can be triggered in the scheduler when running qemu on arm64: + + Unable to handle kernel paging request at virtual address ffff000008effe40 + Internal error: Oops: 96000007 [#1] SMP + Process migration/0 (pid: 12, stack limit = 0x00000000084e3736) + pstate: 20000085 (nzCv daIf -PAN -UAO) + pc : __ll_sc___cmpxchg_case_acq_4+0x4/0x20 + lr : move_queued_task.isra.21+0x124/0x298 + ... + Call trace: + __ll_sc___cmpxchg_case_acq_4+0x4/0x20 + __migrate_task+0xc8/0xe0 + migration_cpu_stop+0x170/0x180 + cpu_stopper_thread+0xec/0x178 + smpboot_thread_fn+0x1ac/0x1e8 + kthread+0x134/0x138 + ret_from_fork+0x10/0x18 + +__set_cpus_allowed_ptr() will choose an active dest_cpu in affinity mask to +migrage the process if process is not currently running on any one of the +CPUs specified in affinity mask. __set_cpus_allowed_ptr() will choose an +invalid dest_cpu (dest_cpu >= nr_cpu_ids, 1024 in my virtual machine) if +CPUS in an affinity mask are deactived by cpu_down after cpumask_intersects +check. cpumask_test_cpu() of dest_cpu afterwards is overflown and may pass if +corresponding bit is coincidentally set. As a consequence, kernel will +access an invalid rq address associate with the invalid CPU in +migration_cpu_stop->__migrate_task->move_queued_task and the Oops occurs. + +The reproduce the crash: + + 1) A process repeatedly binds itself to cpu0 and cpu1 in turn by calling + sched_setaffinity. + + 2) A shell script repeatedly does "echo 0 > /sys/devices/system/cpu/cpu1/online" + and "echo 1 > /sys/devices/system/cpu/cpu1/online" in turn. + + 3) Oops appears if the invalid CPU is set in memory after tested cpumask. + +Signed-off-by: KeMeng Shi +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Valentin Schneider +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Link: https://lkml.kernel.org/r/1568616808-16808-1-git-send-email-shikemeng@huawei.com +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + kernel/sched/core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/kernel/sched/core.c b/kernel/sched/core.c +index f4e050681ba1c..78ecdfae25b69 100644 +--- a/kernel/sched/core.c ++++ b/kernel/sched/core.c +@@ -1077,7 +1077,8 @@ static int __set_cpus_allowed_ptr(struct task_struct *p, + if (cpumask_equal(&p->cpus_allowed, new_mask)) + goto out; + +- if (!cpumask_intersects(new_mask, cpu_valid_mask)) { ++ dest_cpu = cpumask_any_and(cpu_valid_mask, new_mask); ++ if (dest_cpu >= nr_cpu_ids) { + ret = -EINVAL; + goto out; + } +@@ -1098,7 +1099,6 @@ static int __set_cpus_allowed_ptr(struct task_struct *p, + if (cpumask_test_cpu(task_cpu(p), new_mask)) + goto out; + +- dest_cpu = cpumask_any_and(cpu_valid_mask, new_mask); + if (task_running(rq, p) || p->state == TASK_WAKING) { + struct migration_arg arg = { p, dest_cpu }; + /* Need help from migration thread: drop lock and wait. */ +-- +2.20.1 + diff --git a/queue-4.19/sched-membarrier-call-sync_core-only-before-usermode.patch b/queue-4.19/sched-membarrier-call-sync_core-only-before-usermode.patch new file mode 100644 index 00000000000..290762c1d92 --- /dev/null +++ b/queue-4.19/sched-membarrier-call-sync_core-only-before-usermode.patch @@ -0,0 +1,50 @@ +From 668a08662aed8061f657a571afe75191d7b80f2a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Sep 2019 13:37:01 -0400 +Subject: sched/membarrier: Call sync_core only before usermode for same mm + +From: Mathieu Desnoyers + +[ Upstream commit 2840cf02fae627860156737e83326df354ee4ec6 ] + +When the prev and next task's mm change, switch_mm() provides the core +serializing guarantees before returning to usermode. The only case +where an explicit core serialization is needed is when the scheduler +keeps the same mm for prev and next. + +Suggested-by: Oleg Nesterov +Signed-off-by: Mathieu Desnoyers +Signed-off-by: Peter Zijlstra (Intel) +Cc: Chris Metcalf +Cc: Christoph Lameter +Cc: Eric W. Biederman +Cc: Kirill Tkhai +Cc: Linus Torvalds +Cc: Mike Galbraith +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Russell King - ARM Linux admin +Cc: Thomas Gleixner +Link: https://lkml.kernel.org/r/20190919173705.2181-4-mathieu.desnoyers@efficios.com +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + include/linux/sched/mm.h | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h +index 0d10b7ce0da74..e9d4e389aed93 100644 +--- a/include/linux/sched/mm.h ++++ b/include/linux/sched/mm.h +@@ -330,6 +330,8 @@ enum { + + static inline void membarrier_mm_sync_core_before_usermode(struct mm_struct *mm) + { ++ if (current->mm != mm) ++ return; + if (likely(!(atomic_read(&mm->membarrier_state) & + MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE))) + return; +-- +2.20.1 + diff --git a/queue-4.19/sched-membarrier-fix-private-expedited-registration-.patch b/queue-4.19/sched-membarrier-fix-private-expedited-registration-.patch new file mode 100644 index 00000000000..b2df6c652bd --- /dev/null +++ b/queue-4.19/sched-membarrier-fix-private-expedited-registration-.patch @@ -0,0 +1,53 @@ +From d02c2390dd9ae681f1d91ea3869552a036ba953b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 19 Sep 2019 13:36:59 -0400 +Subject: sched/membarrier: Fix private expedited registration check + +From: Mathieu Desnoyers + +[ Upstream commit fc0d77387cb5ae883fd774fc559e056a8dde024c ] + +Fix a logic flaw in the way membarrier_register_private_expedited() +handles ready state checks for private expedited sync core and private +expedited registrations. + +If a private expedited membarrier registration is first performed, and +then a private expedited sync_core registration is performed, the ready +state check will skip the second registration when it really should not. + +Signed-off-by: Mathieu Desnoyers +Signed-off-by: Peter Zijlstra (Intel) +Cc: Chris Metcalf +Cc: Christoph Lameter +Cc: Eric W. Biederman +Cc: Kirill Tkhai +Cc: Linus Torvalds +Cc: Mike Galbraith +Cc: Oleg Nesterov +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Russell King - ARM Linux admin +Cc: Thomas Gleixner +Link: https://lkml.kernel.org/r/20190919173705.2181-2-mathieu.desnoyers@efficios.com +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + kernel/sched/membarrier.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c +index 76e0eaf4654e0..dd27e632b1bab 100644 +--- a/kernel/sched/membarrier.c ++++ b/kernel/sched/membarrier.c +@@ -235,7 +235,7 @@ static int membarrier_register_private_expedited(int flags) + * groups, which use the same mm. (CLONE_VM but not + * CLONE_THREAD). + */ +- if (atomic_read(&mm->membarrier_state) & state) ++ if ((atomic_read(&mm->membarrier_state) & state) == state) + return 0; + atomic_or(MEMBARRIER_STATE_PRIVATE_EXPEDITED, &mm->membarrier_state); + if (flags & MEMBARRIER_FLAG_SYNC_CORE) +-- +2.20.1 + diff --git a/queue-4.19/series b/queue-4.19/series index 819102de3c3..9432a37f059 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -46,3 +46,43 @@ ieee802154-atusb-fix-use-after-free-at-disconnect.patch s390-cio-avoid-calling-strlen-on-null-pointer.patch cfg80211-initialize-on-stack-chandefs.patch arm64-cpufeature-detect-ssbs-and-advertise-to-userspace.patch +ima-always-return-negative-code-for-error.patch +ima-fix-freeing-ongoing-ahash_request.patch +fs-nfs-fix-possible-null-pointer-dereferences-in-enc.patch +9p-transport-error-uninitialized.patch +9p-avoid-attaching-writeback_fid-on-mmap-with-type-p.patch +xen-pci-reserve-mcfg-areas-earlier.patch +ceph-fix-directories-inode-i_blkbits-initialization.patch +ceph-reconnect-connection-if-session-hang-in-opening.patch +watchdog-aspeed-add-support-for-ast2600.patch +netfilter-nf_tables-allow-lookups-in-dynamic-sets.patch +drm-amdgpu-fix-kfd-related-kernel-oops-on-hawaii.patch +drm-amdgpu-check-for-valid-number-of-registers-to-re.patch +pnfs-ensure-we-do-clear-the-return-on-close-layout-s.patch +pwm-stm32-lp-add-check-in-case-requested-period-cann.patch +x86-purgatory-disable-the-stackleak-gcc-plugin-for-t.patch +ntb-point-to-right-memory-window-index.patch +thermal-fix-use-after-free-when-unregistering-therma.patch +thermal_hwmon-sanitize-thermal_zone-type.patch +libnvdimm-region-initialize-bad-block-for-volatile-n.patch +fuse-fix-memleak-in-cuse_channel_open.patch +libnvdimm-nfit_test-fix-acpi_handle-redefinition.patch +sched-membarrier-call-sync_core-only-before-usermode.patch +sched-membarrier-fix-private-expedited-registration-.patch +sched-core-fix-migration-to-invalid-cpu-in-__set_cpu.patch +perf-build-add-detection-of-java-11-openjdk-devel-pa.patch +kernel-elfcore.c-include-proper-prototypes.patch +perf-unwind-fix-libunwind-build-failure-on-i386-syst.patch +nfp-flower-fix-memory-leak-in-nfp_flower_spawn_vnic_.patch +drm-radeon-bail-earlier-when-radeon.cik_-si_support-.patch +kvm-ppc-book3s-hv-xive-free-escalation-interrupts-be.patch +kvm-nvmx-fix-consistency-check-on-injected-exception.patch +nbd-fix-crash-when-the-blksize-is-zero.patch +powerpc-pseries-fix-cpu_hotplug_lock-acquisition-in-.patch +powerpc-book3s64-radix-rename-cpu_ftr_p9_tlbie_bug-f.patch +tools-lib-traceevent-do-not-free-tep-cmdlines-in-add.patch +tick-broadcast-hrtimer-fix-a-race-in-bc_set_next.patch +perf-tools-fix-segfault-in-cpu_cache_level__read.patch +perf-stat-reset-previous-counts-on-repeat-with-inter.patch +drm-i915-userptr-acquire-the-page-lock-around-set_pa.patch +riscv-avoid-interrupts-being-erroneously-enabled-in-.patch diff --git a/queue-4.19/thermal-fix-use-after-free-when-unregistering-therma.patch b/queue-4.19/thermal-fix-use-after-free-when-unregistering-therma.patch new file mode 100644 index 00000000000..291a5a965a1 --- /dev/null +++ b/queue-4.19/thermal-fix-use-after-free-when-unregistering-therma.patch @@ -0,0 +1,134 @@ +From 76f916140bded5382ef265fc33758e84c6e589f1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 10 Jul 2019 13:14:52 +0300 +Subject: thermal: Fix use-after-free when unregistering thermal zone device + +From: Ido Schimmel + +[ Upstream commit 1851799e1d2978f68eea5d9dff322e121dcf59c1 ] + +thermal_zone_device_unregister() cancels the delayed work that polls the +thermal zone, but it does not wait for it to finish. This is racy with +respect to the freeing of the thermal zone device, which can result in a +use-after-free [1]. + +Fix this by waiting for the delayed work to finish before freeing the +thermal zone device. Note that thermal_zone_device_set_polling() is +never invoked from an atomic context, so it is safe to call +cancel_delayed_work_sync() that can block. + +[1] +[ +0.002221] ================================================================== +[ +0.000064] BUG: KASAN: use-after-free in __mutex_lock+0x1076/0x11c0 +[ +0.000016] Read of size 8 at addr ffff8881e48e0450 by task kworker/1:0/17 + +[ +0.000023] CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.2.0-rc6-custom-02495-g8e73ca3be4af #1701 +[ +0.000010] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016 +[ +0.000016] Workqueue: events_freezable_power_ thermal_zone_device_check +[ +0.000012] Call Trace: +[ +0.000021] dump_stack+0xa9/0x10e +[ +0.000020] print_address_description.cold.2+0x9/0x25e +[ +0.000018] __kasan_report.cold.3+0x78/0x9d +[ +0.000016] kasan_report+0xe/0x20 +[ +0.000016] __mutex_lock+0x1076/0x11c0 +[ +0.000014] step_wise_throttle+0x72/0x150 +[ +0.000018] handle_thermal_trip+0x167/0x760 +[ +0.000019] thermal_zone_device_update+0x19e/0x5f0 +[ +0.000019] process_one_work+0x969/0x16f0 +[ +0.000017] worker_thread+0x91/0xc40 +[ +0.000014] kthread+0x33d/0x400 +[ +0.000015] ret_from_fork+0x3a/0x50 + +[ +0.000020] Allocated by task 1: +[ +0.000015] save_stack+0x19/0x80 +[ +0.000015] __kasan_kmalloc.constprop.4+0xc1/0xd0 +[ +0.000014] kmem_cache_alloc_trace+0x152/0x320 +[ +0.000015] thermal_zone_device_register+0x1b4/0x13a0 +[ +0.000015] mlxsw_thermal_init+0xc92/0x23d0 +[ +0.000014] __mlxsw_core_bus_device_register+0x659/0x11b0 +[ +0.000013] mlxsw_core_bus_device_register+0x3d/0x90 +[ +0.000013] mlxsw_pci_probe+0x355/0x4b0 +[ +0.000014] local_pci_probe+0xc3/0x150 +[ +0.000013] pci_device_probe+0x280/0x410 +[ +0.000013] really_probe+0x26a/0xbb0 +[ +0.000013] driver_probe_device+0x208/0x2e0 +[ +0.000013] device_driver_attach+0xfe/0x140 +[ +0.000013] __driver_attach+0x110/0x310 +[ +0.000013] bus_for_each_dev+0x14b/0x1d0 +[ +0.000013] driver_register+0x1c0/0x400 +[ +0.000015] mlxsw_sp_module_init+0x5d/0xd3 +[ +0.000014] do_one_initcall+0x239/0x4dd +[ +0.000013] kernel_init_freeable+0x42b/0x4e8 +[ +0.000012] kernel_init+0x11/0x18b +[ +0.000013] ret_from_fork+0x3a/0x50 + +[ +0.000015] Freed by task 581: +[ +0.000013] save_stack+0x19/0x80 +[ +0.000014] __kasan_slab_free+0x125/0x170 +[ +0.000013] kfree+0xf3/0x310 +[ +0.000013] thermal_release+0xc7/0xf0 +[ +0.000014] device_release+0x77/0x200 +[ +0.000014] kobject_put+0x1a8/0x4c0 +[ +0.000014] device_unregister+0x38/0xc0 +[ +0.000014] thermal_zone_device_unregister+0x54e/0x6a0 +[ +0.000014] mlxsw_thermal_fini+0x184/0x35a +[ +0.000014] mlxsw_core_bus_device_unregister+0x10a/0x640 +[ +0.000013] mlxsw_devlink_core_bus_device_reload+0x92/0x210 +[ +0.000015] devlink_nl_cmd_reload+0x113/0x1f0 +[ +0.000014] genl_family_rcv_msg+0x700/0xee0 +[ +0.000013] genl_rcv_msg+0xca/0x170 +[ +0.000013] netlink_rcv_skb+0x137/0x3a0 +[ +0.000012] genl_rcv+0x29/0x40 +[ +0.000013] netlink_unicast+0x49b/0x660 +[ +0.000013] netlink_sendmsg+0x755/0xc90 +[ +0.000013] __sys_sendto+0x3de/0x430 +[ +0.000013] __x64_sys_sendto+0xe2/0x1b0 +[ +0.000013] do_syscall_64+0xa4/0x4d0 +[ +0.000013] entry_SYSCALL_64_after_hwframe+0x49/0xbe + +[ +0.000017] The buggy address belongs to the object at ffff8881e48e0008 + which belongs to the cache kmalloc-2k of size 2048 +[ +0.000012] The buggy address is located 1096 bytes inside of + 2048-byte region [ffff8881e48e0008, ffff8881e48e0808) +[ +0.000007] The buggy address belongs to the page: +[ +0.000012] page:ffffea0007923800 refcount:1 mapcount:0 mapping:ffff88823680d0c0 index:0x0 compound_mapcount: 0 +[ +0.000020] flags: 0x200000000010200(slab|head) +[ +0.000019] raw: 0200000000010200 ffffea0007682008 ffffea00076ab808 ffff88823680d0c0 +[ +0.000016] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000 +[ +0.000007] page dumped because: kasan: bad access detected + +[ +0.000012] Memory state around the buggy address: +[ +0.000012] ffff8881e48e0300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ +0.000012] ffff8881e48e0380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ +0.000012] >ffff8881e48e0400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ +0.000008] ^ +[ +0.000012] ffff8881e48e0480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ +0.000012] ffff8881e48e0500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ +0.000007] ================================================================== + +Fixes: b1569e99c795 ("ACPI: move thermal trip handling to generic thermal layer") +Reported-by: Jiri Pirko +Signed-off-by: Ido Schimmel +Acked-by: Jiri Pirko +Signed-off-by: Zhang Rui +Signed-off-by: Sasha Levin +--- + drivers/thermal/thermal_core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c +index bf9721fc2824e..be3eafc7682ba 100644 +--- a/drivers/thermal/thermal_core.c ++++ b/drivers/thermal/thermal_core.c +@@ -296,7 +296,7 @@ static void thermal_zone_device_set_polling(struct thermal_zone_device *tz, + mod_delayed_work(system_freezable_wq, &tz->poll_queue, + msecs_to_jiffies(delay)); + else +- cancel_delayed_work(&tz->poll_queue); ++ cancel_delayed_work_sync(&tz->poll_queue); + } + + static void monitor_thermal_zone(struct thermal_zone_device *tz) +-- +2.20.1 + diff --git a/queue-4.19/thermal_hwmon-sanitize-thermal_zone-type.patch b/queue-4.19/thermal_hwmon-sanitize-thermal_zone-type.patch new file mode 100644 index 00000000000..ff68b79fbc7 --- /dev/null +++ b/queue-4.19/thermal_hwmon-sanitize-thermal_zone-type.patch @@ -0,0 +1,53 @@ +From 0fca02ba7a685f9fc50598e8ed5d68cbe30b075c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 26 Jul 2019 16:32:36 +0300 +Subject: thermal_hwmon: Sanitize thermal_zone type + +From: Stefan Mavrodiev + +[ Upstream commit 8c7aa184281c01fc26f319059efb94725012921d ] + +When calling thermal_add_hwmon_sysfs(), the device type is sanitized by +replacing '-' with '_'. However tz->type remains unsanitized. Thus +calling thermal_hwmon_lookup_by_type() returns no device. And if there is +no device, thermal_remove_hwmon_sysfs() fails with "hwmon device lookup +failed!". + +The result is unregisted hwmon devices in the sysfs. + +Fixes: 409ef0bacacf ("thermal_hwmon: Sanitize attribute name passed to hwmon") + +Signed-off-by: Stefan Mavrodiev +Signed-off-by: Zhang Rui +Signed-off-by: Sasha Levin +--- + drivers/thermal/thermal_hwmon.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c +index 40c69a533b240..dd5d8ee379287 100644 +--- a/drivers/thermal/thermal_hwmon.c ++++ b/drivers/thermal/thermal_hwmon.c +@@ -87,13 +87,17 @@ static struct thermal_hwmon_device * + thermal_hwmon_lookup_by_type(const struct thermal_zone_device *tz) + { + struct thermal_hwmon_device *hwmon; ++ char type[THERMAL_NAME_LENGTH]; + + mutex_lock(&thermal_hwmon_list_lock); +- list_for_each_entry(hwmon, &thermal_hwmon_list, node) +- if (!strcmp(hwmon->type, tz->type)) { ++ list_for_each_entry(hwmon, &thermal_hwmon_list, node) { ++ strcpy(type, tz->type); ++ strreplace(type, '-', '_'); ++ if (!strcmp(hwmon->type, type)) { + mutex_unlock(&thermal_hwmon_list_lock); + return hwmon; + } ++ } + mutex_unlock(&thermal_hwmon_list_lock); + + return NULL; +-- +2.20.1 + diff --git a/queue-4.19/tick-broadcast-hrtimer-fix-a-race-in-bc_set_next.patch b/queue-4.19/tick-broadcast-hrtimer-fix-a-race-in-bc_set_next.patch new file mode 100644 index 00000000000..327621f848b --- /dev/null +++ b/queue-4.19/tick-broadcast-hrtimer-fix-a-race-in-bc_set_next.patch @@ -0,0 +1,173 @@ +From c605f9eb76b6f21a9fede25cbbc42a744be6b51b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Sep 2019 15:51:01 +0200 +Subject: tick: broadcast-hrtimer: Fix a race in bc_set_next + +From: Balasubramani Vivekanandan + +[ Upstream commit b9023b91dd020ad7e093baa5122b6968c48cc9e0 ] + +When a cpu requests broadcasting, before starting the tick broadcast +hrtimer, bc_set_next() checks if the timer callback (bc_handler) is active +using hrtimer_try_to_cancel(). But hrtimer_try_to_cancel() does not provide +the required synchronization when the callback is active on other core. + +The callback could have already executed tick_handle_oneshot_broadcast() +and could have also returned. But still there is a small time window where +the hrtimer_try_to_cancel() returns -1. In that case bc_set_next() returns +without doing anything, but the next_event of the tick broadcast clock +device is already set to a timeout value. + +In the race condition diagram below, CPU #1 is running the timer callback +and CPU #2 is entering idle state and so calls bc_set_next(). + +In the worst case, the next_event will contain an expiry time, but the +hrtimer will not be started which happens when the racing callback returns +HRTIMER_NORESTART. The hrtimer might never recover if all further requests +from the CPUs to subscribe to tick broadcast have timeout greater than the +next_event of tick broadcast clock device. This leads to cascading of +failures and finally noticed as rcu stall warnings + +Here is a depiction of the race condition + +CPU #1 (Running timer callback) CPU #2 (Enter idle + and subscribe to + tick broadcast) +--------------------- --------------------- + +__run_hrtimer() tick_broadcast_enter() + + bc_handler() __tick_broadcast_oneshot_control() + + tick_handle_oneshot_broadcast() + + raw_spin_lock(&tick_broadcast_lock); + + dev->next_event = KTIME_MAX; //wait for tick_broadcast_lock + //next_event for tick broadcast clock + set to KTIME_MAX since no other cores + subscribed to tick broadcasting + + raw_spin_unlock(&tick_broadcast_lock); + + if (dev->next_event == KTIME_MAX) + return HRTIMER_NORESTART + // callback function exits without + restarting the hrtimer //tick_broadcast_lock acquired + raw_spin_lock(&tick_broadcast_lock); + + tick_broadcast_set_event() + + clockevents_program_event() + + dev->next_event = expires; + + bc_set_next() + + hrtimer_try_to_cancel() + //returns -1 since the timer + callback is active. Exits without + restarting the timer + cpu_base->running = NULL; + +The comment that hrtimer cannot be armed from within the callback is +wrong. It is fine to start the hrtimer from within the callback. Also it is +safe to start the hrtimer from the enter/exit idle code while the broadcast +handler is active. The enter/exit idle code and the broadcast handler are +synchronized using tick_broadcast_lock. So there is no need for the +existing try to cancel logic. All this can be removed which will eliminate +the race condition as well. + +Fixes: 5d1638acb9f6 ("tick: Introduce hrtimer based broadcast") +Originally-by: Thomas Gleixner +Signed-off-by: Balasubramani Vivekanandan +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20190926135101.12102-2-balasubramani_vivekanandan@mentor.com +Signed-off-by: Sasha Levin +--- + kernel/time/tick-broadcast-hrtimer.c | 57 ++++++++++++++-------------- + 1 file changed, 29 insertions(+), 28 deletions(-) + +diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c +index a59641fb88b69..a836efd345895 100644 +--- a/kernel/time/tick-broadcast-hrtimer.c ++++ b/kernel/time/tick-broadcast-hrtimer.c +@@ -44,34 +44,39 @@ static int bc_shutdown(struct clock_event_device *evt) + */ + static int bc_set_next(ktime_t expires, struct clock_event_device *bc) + { +- int bc_moved; + /* +- * We try to cancel the timer first. If the callback is on +- * flight on some other cpu then we let it handle it. If we +- * were able to cancel the timer nothing can rearm it as we +- * own broadcast_lock. ++ * This is called either from enter/exit idle code or from the ++ * broadcast handler. In all cases tick_broadcast_lock is held. + * +- * However we can also be called from the event handler of +- * ce_broadcast_hrtimer itself when it expires. We cannot +- * restart the timer because we are in the callback, but we +- * can set the expiry time and let the callback return +- * HRTIMER_RESTART. ++ * hrtimer_cancel() cannot be called here neither from the ++ * broadcast handler nor from the enter/exit idle code. The idle ++ * code can run into the problem described in bc_shutdown() and the ++ * broadcast handler cannot wait for itself to complete for obvious ++ * reasons. + * +- * Since we are in the idle loop at this point and because +- * hrtimer_{start/cancel} functions call into tracing, +- * calls to these functions must be bound within RCU_NONIDLE. ++ * Each caller tries to arm the hrtimer on its own CPU, but if the ++ * hrtimer callbback function is currently running, then ++ * hrtimer_start() cannot move it and the timer stays on the CPU on ++ * which it is assigned at the moment. ++ * ++ * As this can be called from idle code, the hrtimer_start() ++ * invocation has to be wrapped with RCU_NONIDLE() as ++ * hrtimer_start() can call into tracing. + */ +- RCU_NONIDLE({ +- bc_moved = hrtimer_try_to_cancel(&bctimer) >= 0; +- if (bc_moved) +- hrtimer_start(&bctimer, expires, +- HRTIMER_MODE_ABS_PINNED);}); +- if (bc_moved) { +- /* Bind the "device" to the cpu */ +- bc->bound_on = smp_processor_id(); +- } else if (bc->bound_on == smp_processor_id()) { +- hrtimer_set_expires(&bctimer, expires); +- } ++ RCU_NONIDLE( { ++ hrtimer_start(&bctimer, expires, HRTIMER_MODE_ABS_PINNED); ++ /* ++ * The core tick broadcast mode expects bc->bound_on to be set ++ * correctly to prevent a CPU which has the broadcast hrtimer ++ * armed from going deep idle. ++ * ++ * As tick_broadcast_lock is held, nothing can change the cpu ++ * base which was just established in hrtimer_start() above. So ++ * the below access is safe even without holding the hrtimer ++ * base lock. ++ */ ++ bc->bound_on = bctimer.base->cpu_base->cpu; ++ } ); + return 0; + } + +@@ -97,10 +102,6 @@ static enum hrtimer_restart bc_handler(struct hrtimer *t) + { + ce_broadcast_hrtimer.event_handler(&ce_broadcast_hrtimer); + +- if (clockevent_state_oneshot(&ce_broadcast_hrtimer)) +- if (ce_broadcast_hrtimer.next_event != KTIME_MAX) +- return HRTIMER_RESTART; +- + return HRTIMER_NORESTART; + } + +-- +2.20.1 + diff --git a/queue-4.19/tools-lib-traceevent-do-not-free-tep-cmdlines-in-add.patch b/queue-4.19/tools-lib-traceevent-do-not-free-tep-cmdlines-in-add.patch new file mode 100644 index 00000000000..81fb4f0517b --- /dev/null +++ b/queue-4.19/tools-lib-traceevent-do-not-free-tep-cmdlines-in-add.patch @@ -0,0 +1,57 @@ +From 250ca103eed36f687cc889f12e8711a854e2fbe7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 28 Aug 2019 15:05:28 -0400 +Subject: tools lib traceevent: Do not free tep->cmdlines in add_new_comm() on + failure + +From: Steven Rostedt (VMware) + +[ Upstream commit e0d2615856b2046c2e8d5bfd6933f37f69703b0b ] + +If the re-allocation of tep->cmdlines succeeds, then the previous +allocation of tep->cmdlines will be freed. If we later fail in +add_new_comm(), we must not free cmdlines, and also should assign +tep->cmdlines to the new allocation. Otherwise when freeing tep, the +tep->cmdlines will be pointing to garbage. + +Fixes: a6d2a61ac653a ("tools lib traceevent: Remove some die() calls") +Signed-off-by: Steven Rostedt (VMware) +Cc: Andrew Morton +Cc: Jiri Olsa +Cc: Namhyung Kim +Cc: linux-trace-devel@vger.kernel.org +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/20190828191819.970121417@goodmis.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/lib/traceevent/event-parse.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c +index 6ccfd13d5cf9c..382e476629fb1 100644 +--- a/tools/lib/traceevent/event-parse.c ++++ b/tools/lib/traceevent/event-parse.c +@@ -254,10 +254,10 @@ static int add_new_comm(struct tep_handle *pevent, const char *comm, int pid) + errno = ENOMEM; + return -1; + } ++ pevent->cmdlines = cmdlines; + + cmdlines[pevent->cmdline_count].comm = strdup(comm); + if (!cmdlines[pevent->cmdline_count].comm) { +- free(cmdlines); + errno = ENOMEM; + return -1; + } +@@ -268,7 +268,6 @@ static int add_new_comm(struct tep_handle *pevent, const char *comm, int pid) + pevent->cmdline_count++; + + qsort(cmdlines, pevent->cmdline_count, sizeof(*cmdlines), cmdline_cmp); +- pevent->cmdlines = cmdlines; + + return 0; + } +-- +2.20.1 + diff --git a/queue-4.19/watchdog-aspeed-add-support-for-ast2600.patch b/queue-4.19/watchdog-aspeed-add-support-for-ast2600.patch new file mode 100644 index 00000000000..be5abaf0406 --- /dev/null +++ b/queue-4.19/watchdog-aspeed-add-support-for-ast2600.patch @@ -0,0 +1,47 @@ +From 2aca8cc7a57a90dae5ac8f32d1f4d0a8d73df865 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 19 Aug 2019 14:47:38 +0930 +Subject: watchdog: aspeed: Add support for AST2600 + +From: Ryan Chen + +[ Upstream commit b3528b4874480818e38e4da019d655413c233e6a ] + +The ast2600 can be supported by the same code as the ast2500. + +Signed-off-by: Ryan Chen +Signed-off-by: Joel Stanley +Reviewed-by: Guenter Roeck +Link: https://lore.kernel.org/r/20190819051738.17370-3-joel@jms.id.au +Signed-off-by: Guenter Roeck +Signed-off-by: Wim Van Sebroeck +Signed-off-by: Sasha Levin +--- + drivers/watchdog/aspeed_wdt.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c +index 1abe4d021fd27..ffde179a9bb2c 100644 +--- a/drivers/watchdog/aspeed_wdt.c ++++ b/drivers/watchdog/aspeed_wdt.c +@@ -38,6 +38,7 @@ static const struct aspeed_wdt_config ast2500_config = { + static const struct of_device_id aspeed_wdt_of_table[] = { + { .compatible = "aspeed,ast2400-wdt", .data = &ast2400_config }, + { .compatible = "aspeed,ast2500-wdt", .data = &ast2500_config }, ++ { .compatible = "aspeed,ast2600-wdt", .data = &ast2500_config }, + { }, + }; + MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table); +@@ -264,7 +265,8 @@ static int aspeed_wdt_probe(struct platform_device *pdev) + set_bit(WDOG_HW_RUNNING, &wdt->wdd.status); + } + +- if (of_device_is_compatible(np, "aspeed,ast2500-wdt")) { ++ if ((of_device_is_compatible(np, "aspeed,ast2500-wdt")) || ++ (of_device_is_compatible(np, "aspeed,ast2600-wdt"))) { + u32 reg = readl(wdt->base + WDT_RESET_WIDTH); + + reg &= config->ext_pulse_width_mask; +-- +2.20.1 + diff --git a/queue-4.19/x86-purgatory-disable-the-stackleak-gcc-plugin-for-t.patch b/queue-4.19/x86-purgatory-disable-the-stackleak-gcc-plugin-for-t.patch new file mode 100644 index 00000000000..bfa8620b4b4 --- /dev/null +++ b/queue-4.19/x86-purgatory-disable-the-stackleak-gcc-plugin-for-t.patch @@ -0,0 +1,53 @@ +From 26d965bdd3834582e9a4617dbe418c36f1897faa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 23 Sep 2019 13:17:54 -0400 +Subject: x86/purgatory: Disable the stackleak GCC plugin for the purgatory + +From: Arvind Sankar + +[ Upstream commit ca14c996afe7228ff9b480cf225211cc17212688 ] + +Since commit: + + b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS") + +kexec breaks if GCC_PLUGIN_STACKLEAK=y is enabled, as the purgatory +contains undefined references to stackleak_track_stack. + +Attempting to load a kexec kernel results in this failure: + + kexec: Undefined symbol: stackleak_track_stack + kexec-bzImage64: Loading purgatory failed + +Fix this by disabling the stackleak plugin for the purgatory. + +Signed-off-by: Arvind Sankar +Reviewed-by: Nick Desaulniers +Cc: Borislav Petkov +Cc: H. Peter Anvin +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS") +Link: https://lkml.kernel.org/r/20190923171753.GA2252517@rani.riverdale.lan +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + arch/x86/purgatory/Makefile | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile +index 10fb42da0007e..b81b5172cf994 100644 +--- a/arch/x86/purgatory/Makefile ++++ b/arch/x86/purgatory/Makefile +@@ -23,6 +23,7 @@ KCOV_INSTRUMENT := n + + PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel + PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss ++PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) + + # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That + # in turn leaves some undefined symbols like __fentry__ in purgatory and not +-- +2.20.1 + diff --git a/queue-4.19/xen-pci-reserve-mcfg-areas-earlier.patch b/queue-4.19/xen-pci-reserve-mcfg-areas-earlier.patch new file mode 100644 index 00000000000..63f5909cc8c --- /dev/null +++ b/queue-4.19/xen-pci-reserve-mcfg-areas-earlier.patch @@ -0,0 +1,90 @@ +From 2702edd41f37118526aa9ceadb4ecb8088dd64fe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 12 Sep 2019 19:31:51 +0100 +Subject: xen/pci: reserve MCFG areas earlier + +From: Igor Druzhinin + +[ Upstream commit a4098bc6eed5e31e0391bcc068e61804c98138df ] + +If MCFG area is not reserved in E820, Xen by default will defer its usage +until Dom0 registers it explicitly after ACPI parser recognizes it as +a reserved resource in DSDT. Having it reserved in E820 is not +mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2) +and firmware is free to keep a hole in E820 in that place. Xen doesn't know +what exactly is inside this hole since it lacks full ACPI view of the +platform therefore it's potentially harmful to access MCFG region +without additional checks as some machines are known to provide +inconsistent information on the size of the region. + +Now xen_mcfg_late() runs after acpi_init() which is too late as some basic +PCI enumeration starts exactly there as well. Trying to register a device +prior to MCFG reservation causes multiple problems with PCIe extended +capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are +no convenient hooks for us to subscribe to so register MCFG areas earlier +upon the first invocation of xen_add_device(). It should be safe to do once +since all the boot time buses must have their MCFG areas in MCFG table +already and we don't support PCI bus hot-plug. + +Signed-off-by: Igor Druzhinin +Reviewed-by: Boris Ostrovsky +Signed-off-by: Boris Ostrovsky +Signed-off-by: Sasha Levin +--- + drivers/xen/pci.c | 21 +++++++++++++++------ + 1 file changed, 15 insertions(+), 6 deletions(-) + +diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c +index 7494dbeb4409c..db58aaa4dc598 100644 +--- a/drivers/xen/pci.c ++++ b/drivers/xen/pci.c +@@ -29,6 +29,8 @@ + #include "../pci/pci.h" + #ifdef CONFIG_PCI_MMCONFIG + #include ++ ++static int xen_mcfg_late(void); + #endif + + static bool __read_mostly pci_seg_supported = true; +@@ -40,7 +42,18 @@ static int xen_add_device(struct device *dev) + #ifdef CONFIG_PCI_IOV + struct pci_dev *physfn = pci_dev->physfn; + #endif +- ++#ifdef CONFIG_PCI_MMCONFIG ++ static bool pci_mcfg_reserved = false; ++ /* ++ * Reserve MCFG areas in Xen on first invocation due to this being ++ * potentially called from inside of acpi_init immediately after ++ * MCFG table has been finally parsed. ++ */ ++ if (!pci_mcfg_reserved) { ++ xen_mcfg_late(); ++ pci_mcfg_reserved = true; ++ } ++#endif + if (pci_seg_supported) { + struct { + struct physdev_pci_device_add add; +@@ -213,7 +226,7 @@ static int __init register_xen_pci_notifier(void) + arch_initcall(register_xen_pci_notifier); + + #ifdef CONFIG_PCI_MMCONFIG +-static int __init xen_mcfg_late(void) ++static int xen_mcfg_late(void) + { + struct pci_mmcfg_region *cfg; + int rc; +@@ -252,8 +265,4 @@ static int __init xen_mcfg_late(void) + } + return 0; + } +-/* +- * Needs to be done after acpi_init which are subsys_initcall. +- */ +-subsys_initcall_sync(xen_mcfg_late); + #endif +-- +2.20.1 + -- 2.47.2