--- /dev/null
+From 289fe560726c6456029e541f227c709b701a4afc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 20 Aug 2019 18:03:25 +0800
+Subject: 9p: avoid attaching writeback_fid on mmap with type PRIVATE
+
+From: Chengguang Xu <cgxu519@zoho.com.cn>
+
+[ 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 <cgxu519@zoho.com.cn>
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From f58c7c171a08db471e3d1ec4b7ea6122cdf66a42 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 13 Jun 2019 15:08:54 +0800
+Subject: 9p: Transport error uninitialized
+
+From: Lu Shuaibing <shuaibinglu@126.com>
+
+[ 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 <shuaibinglu@126.com>
+[dominique.martinet@cea.fr: grouped the added init with the others]
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 90ca7799e53e0f20879ea17ae43dc77d790612fc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Jul 2019 16:50:20 +0100
+Subject: ceph: fix directories inode i_blkbits initialization
+
+From: Luis Henriques <lhenriques@suse.com>
+
+[ 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 <lhenriques@suse.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From a69773a9c5d136cce594a5496ae02f0866814d27 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 28 Aug 2019 21:22:45 +0800
+Subject: ceph: reconnect connection if session hang in opening state
+
+From: Erqi Chen <chenerqi@gmail.com>
+
+[ 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" <zyan@redhat.com>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 83466bd4058b98d3427d794507adc5c4f44daee1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 31 Aug 2019 21:25:36 +0200
+Subject: drm/amdgpu: Check for valid number of registers to read
+
+From: Trek <trek00@inbox.ru>
+
+[ 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 <trek00@inbox.ru>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 147234c3fcc64aa1f9096daa9172a7b1bb8bb94d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <Felix.Kuehling@amd.com>
+
+[ 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 <Felix.Kuehling@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 7d10a59723931ebad8f3e0bd819d72505d9fd7fd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Jul 2019 15:03:27 +0100
+Subject: drm/i915/userptr: Acquire the page lock around set_page_dirty()
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+[ 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 <chris@chris-wilson.co.uk>
+Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-chris@chris-wilson.co.uk
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 18db8e6bba7c58ff7e0f0b8751da5d5fe30e123c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <hdegoede@redhat.com>
+
+[ 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 <mdaenzer@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From be360e009fd1c39c36a8e78bf9994d4944e724c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 26 Jul 2019 15:48:53 +0800
+Subject: fs: nfs: Fix possible null-pointer dereferences in encode_attrs()
+
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+
+[ 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 <baijiaju1990@gmail.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 7e1fc6e583846c43e9e6150200559a230f06639e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Aug 2019 15:59:09 +0800
+Subject: fuse: fix memleak in cuse_channel_open
+
+From: zhengbin <zhengbin13@huawei.com>
+
+[ 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 <hulkci@huawei.com>
+Signed-off-by: zhengbin <zhengbin13@huawei.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From be240385baabbdd3620ab96657f290beeb979152 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Jul 2019 10:00:40 +0200
+Subject: ima: always return negative code for error
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+[ 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 <s.hauer@pengutronix.de>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 3421e0c811bc0b48ea45ea9a479299c2deb6874d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Jul 2019 10:00:41 +0200
+Subject: ima: fix freeing ongoing ahash_request
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+[ 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 <s.hauer@pengutronix.de>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 730e5962a66210267d4aee02daf68c6f680490c8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Sep 2019 16:45:59 -0700
+Subject: kernel/elfcore.c: include proper prototypes
+
+From: Valdis Kletnieks <valdis.kletnieks@vt.edu>
+
+[ 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 <valdis.kletnieks@vt.edu>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 <linux/fs.h>
+ #include <linux/mm.h>
+ #include <linux/binfmts.h>
++#include <linux/elfcore.h>
+
+ Elf_Half __weak elf_core_extra_phdrs(void)
+ {
+--
+2.20.1
+
--- /dev/null
+From 5e0e6683a457dd26b4a16cd0553f232ff733cb51 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Oct 2019 09:21:23 -0700
+Subject: KVM: nVMX: Fix consistency check on injected exception error code
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+[ 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 <namit@vmware.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From eb3d10a4e89ad025ddaaa1e223e666c4c2d702c7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <clg@kaod.org>
+
+[ 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 <clg@kaod.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190806172538.5087-1-clg@kaod.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From b4240915ad25a5ccad36391c5ee8378b29e52bd7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 17 Sep 2019 21:21:49 -0700
+Subject: libnvdimm/nfit_test: Fix acpi_handle redefinition
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+[ 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 <natechancellor@gmail.com>
+Reviewed-by: Ira Weiny <ira.weiny@intel.com>
+Link: https://lore.kernel.org/r/20190918042148.77553-1-natechancellor@gmail.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 <linux/acpi.h>
+ #include <linux/list.h>
+ #include <linux/uuid.h>
+ #include <linux/ioport.h>
+@@ -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
+
--- /dev/null
+From 3bbcd4c76bcb12882463be97b4b00500395ad92e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Sep 2019 14:03:55 +0530
+Subject: libnvdimm/region: Initialize bad block for volatile namespaces
+
+From: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+
+[ 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 <aneesh.kumar@linux.ibm.com>
+Link: https://lore.kernel.org/r/20190919083355.26340-1-aneesh.kumar@linux.ibm.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 5e5d558fb1ead1a84238b4461d890471b8cec235 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 29 May 2019 15:16:05 -0500
+Subject: nbd: fix crash when the blksize is zero
+
+From: Xiubo Li <xiubli@redhat.com>
+
+[ Upstream commit 553768d1169a48c0cd87c4eb4ab57534ee663415 ]
+
+This will allow the blksize to be set zero and then use 1024 as
+default.
+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Xiubo Li <xiubli@redhat.com>
+[fix to use goto out instead of return in genl_connect]
+Signed-off-by: Mike Christie <mchristi@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From c45ffbaadf60d9ef77f8f1e4d05d05e736d7a466 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Sep 2019 16:56:44 +0200
+Subject: netfilter: nf_tables: allow lookups in dynamic sets
+
+From: Florian Westphal <fw@strlen.de>
+
+[ 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 <fw@strlen.de>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From aa8bca3369089ac2264b86564564dbe38007d447 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Sep 2019 14:05:09 -0500
+Subject: nfp: flower: fix memory leak in nfp_flower_spawn_vnic_reprs
+
+From: Navid Emamdoost <navid.emamdoost@gmail.com>
+
+[ 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 <navid.emamdoost@gmail.com>
+Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 75c8a2b14865785369ef4f219d35654080179450 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 Mar 2019 11:32:50 +0000
+Subject: ntb: point to right memory window index
+
+From: Sanjay R Mehta <sanju.mehta@amd.com>
+
+[ 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 <sanju.mehta@amd.com>
+Signed-off-by: Jon Mason <jdmason@kudzu.us>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 8bc7d2c084cd68c0022f357f58d37c7a99d043ce Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Sep 2019 13:41:16 +0200
+Subject: perf build: Add detection of java-11-openjdk-devel package
+
+From: Thomas Richter <tmricht@linux.ibm.com>
+
+[ 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 <krebbel@linux.ibm.com>
+Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
+Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
+Cc: Vasily Gorbik <gor@linux.ibm.com>
+Link: http://lore.kernel.org/lkml/20190909114116.50469-4-tmricht@linux.ibm.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From f9dff7025ec1c7f6edafd91942e8de9fddf85603 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Sep 2019 15:17:37 +0530
+Subject: perf stat: Reset previous counts on repeat with interval
+
+From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
+
+[ 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 <srikar@linux.vnet.ibm.com>
+Acked-by: Jiri Olsa <jolsa@kernel.org>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Cc: Stephane Eranian <eranian@google.com>
+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 <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From fd5e773aaed35e42f82f7a1e87b4990d9fa4b5c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Sep 2019 12:52:35 +0200
+Subject: perf tools: Fix segfault in cpu_cache_level__read()
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+[ 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=<optimiz..
+ ...
+
+Releasing the proper pointer.
+
+Fixes: 720e98b5faf1 ("perf tools: Add perf data cache feature")
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Michael Petlan <mpetlan@redhat.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+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 <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From d7de3a8e62888e22465a9b21a38faaf8c35da18c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Sep 2019 14:36:48 -0300
+Subject: perf unwind: Fix libunwind build failure on i386 systems
+
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+
+[ 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 <naresh.kamboju@linaro.org>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: David Ahern <dsahern@gmail.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 <errno.h>
++#include "../../util/debug.h"
+ #ifndef REMOTE_UNWIND_LIBUNWIND
+ #include <libunwind.h>
+ #include "perf_regs.h"
+ #include "../../util/unwind.h"
+-#include "../../util/debug.h"
+ #endif
+
+ #ifdef HAVE_ARCH_X86_64_SUPPORT
+--
+2.20.1
+
--- /dev/null
+From 70c91c4767b2de864aae7bf66ae5dbe271f621fc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <trondmy@gmail.com>
+
+[ 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 <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 539ad4342a8b3d1b496a5421f2ea298025d7c6e7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <aneesh.kumar@linux.ibm.com>
+
+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 <aneesh.kumar@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+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
+
--- /dev/null
+From aca7848ddbf2ccf24dc7bf1a13245fe81b5b563a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 May 2019 13:15:52 +0530
+Subject: powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt()
+
+From: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+
+[ 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 <aneesh.kumar@linux.ibm.com>
+Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/1557906352-29048-1-git-send-email-ego@linux.vnet.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 <linux/context_tracking.h>
+ #include <linux/libfdt.h>
+ #include <linux/pkeys.h>
++#include <linux/cpu.h>
+
+ #include <asm/debugfs.h>
+ #include <asm/processor.h>
+@@ -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
+
--- /dev/null
+From a8845e5daf0370390b9f861b10219ec4babd8fa6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <fabrice.gasnier@st.com>
+
+[ 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 <fabrice.gasnier@st.com>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 2a3a4d3797da24bb3c9f12a404825d908ae618cc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 16 Sep 2019 16:47:41 +0800
+Subject: riscv: Avoid interrupts being erroneously enabled in
+ handle_exception()
+
+From: Vincent Chen <vincent.chen@sifive.com>
+
+[ 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 <vincent.chen@sifive.com>
+Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
+[paul.walmsley@sifive.com: updated to apply]
+Fixes: bcae803a21317 ("RISC-V: Enable IRQ during exception handling")
+Cc: David Abdurachmanov <david.abdurachmanov@sifive.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From cba311118dcfb009ba67f015c719ffbc5fb43e89 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <shikemeng@huawei.com>
+
+[ 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 <shikemeng@huawei.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/1568616808-16808-1-git-send-email-shikemeng@huawei.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 668a08662aed8061f657a571afe75191d7b80f2a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Sep 2019 13:37:01 -0400
+Subject: sched/membarrier: Call sync_core only before usermode for same mm
+
+From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+
+[ 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 <oleg@redhat.com>
+Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Chris Metcalf <cmetcalf@ezchip.com>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Cc: Kirill Tkhai <tkhai@yandex.ru>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mike Galbraith <efault@gmx.de>
+Cc: Paul E. McKenney <paulmck@linux.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/20190919173705.2181-4-mathieu.desnoyers@efficios.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From d02c2390dd9ae681f1d91ea3869552a036ba953b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Sep 2019 13:36:59 -0400
+Subject: sched/membarrier: Fix private expedited registration check
+
+From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+
+[ 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 <mathieu.desnoyers@efficios.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Chris Metcalf <cmetcalf@ezchip.com>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Cc: Kirill Tkhai <tkhai@yandex.ru>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mike Galbraith <efault@gmx.de>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Paul E. McKenney <paulmck@linux.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/20190919173705.2181-2-mathieu.desnoyers@efficios.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From 76f916140bded5382ef265fc33758e84c6e589f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Jul 2019 13:14:52 +0300
+Subject: thermal: Fix use-after-free when unregistering thermal zone device
+
+From: Ido Schimmel <idosch@mellanox.com>
+
+[ 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 <jiri@mellanox.com>
+Signed-off-by: Ido Schimmel <idosch@mellanox.com>
+Acked-by: Jiri Pirko <jiri@mellanox.com>
+Signed-off-by: Zhang Rui <rui.zhang@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 0fca02ba7a685f9fc50598e8ed5d68cbe30b075c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 26 Jul 2019 16:32:36 +0300
+Subject: thermal_hwmon: Sanitize thermal_zone type
+
+From: Stefan Mavrodiev <stefan@olimex.com>
+
+[ 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 <stefan@olimex.com>
+Signed-off-by: Zhang Rui <rui.zhang@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From c605f9eb76b6f21a9fede25cbbc42a744be6b51b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Sep 2019 15:51:01 +0200
+Subject: tick: broadcast-hrtimer: Fix a race in bc_set_next
+
+From: Balasubramani Vivekanandan <balasubramani_vivekanandan@mentor.com>
+
+[ 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 <tglx@linutronix.de>
+Signed-off-by: Balasubramani Vivekanandan <balasubramani_vivekanandan@mentor.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20190926135101.12102-2-balasubramani_vivekanandan@mentor.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 250ca103eed36f687cc889f12e8711a854e2fbe7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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) <rostedt@goodmis.org>
+
+[ 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) <rostedt@goodmis.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+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 <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 2aca8cc7a57a90dae5ac8f32d1f4d0a8d73df865 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 19 Aug 2019 14:47:38 +0930
+Subject: watchdog: aspeed: Add support for AST2600
+
+From: Ryan Chen <ryan_chen@aspeedtech.com>
+
+[ Upstream commit b3528b4874480818e38e4da019d655413c233e6a ]
+
+The ast2600 can be supported by the same code as the ast2500.
+
+Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
+Signed-off-by: Joel Stanley <joel@jms.id.au>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Link: https://lore.kernel.org/r/20190819051738.17370-3-joel@jms.id.au
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 26d965bdd3834582e9a4617dbe418c36f1897faa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 23 Sep 2019 13:17:54 -0400
+Subject: x86/purgatory: Disable the stackleak GCC plugin for the purgatory
+
+From: Arvind Sankar <nivedita@alum.mit.edu>
+
+[ 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 <nivedita@alum.mit.edu>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+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 <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 2702edd41f37118526aa9ceadb4ecb8088dd64fe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Sep 2019 19:31:51 +0100
+Subject: xen/pci: reserve MCFG areas earlier
+
+From: Igor Druzhinin <igor.druzhinin@citrix.com>
+
+[ 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 <igor.druzhinin@citrix.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 <asm/pci_x86.h>
++
++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
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
