--- /dev/null
+From 7ee06ddc4038f936b0d4459d37a7d4d844fb03db Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Fri, 7 May 2021 11:38:10 -0400
+Subject: dm snapshot: fix a crash when an origin has no snapshots
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 7ee06ddc4038f936b0d4459d37a7d4d844fb03db upstream.
+
+If an origin target has no snapshots, o->split_boundary is set to 0.
+This causes BUG_ON(sectors <= 0) in block/bio.c:bio_split().
+
+Fix this by initializing chunk_size, and in turn split_boundary, to
+rounddown_pow_of_two(UINT_MAX) -- the largest power of two that fits
+into "unsigned" type.
+
+Reported-by: Michael Tokarev <mjt@tls.msk.ru>
+Tested-by: Michael Tokarev <mjt@tls.msk.ru>
+Cc: stable@vger.kernel.org
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-snap.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm-snap.c
++++ b/drivers/md/dm-snap.c
+@@ -854,12 +854,11 @@ static int dm_add_exception(void *contex
+ static uint32_t __minimum_chunk_size(struct origin *o)
+ {
+ struct dm_snapshot *snap;
+- unsigned chunk_size = 0;
++ unsigned chunk_size = rounddown_pow_of_two(UINT_MAX);
+
+ if (o)
+ list_for_each_entry(snap, &o->snapshots, list)
+- chunk_size = min_not_zero(chunk_size,
+- snap->store->chunk_size);
++ chunk_size = min(chunk_size, snap->store->chunk_size);
+
+ return (uint32_t) chunk_size;
+ }
--- /dev/null
+From c699a0db2d62e3bbb7f0bf35c87edbc8d23e3062 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 10 May 2021 14:49:05 -0400
+Subject: dm snapshot: fix crash with transient storage and zero chunk size
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit c699a0db2d62e3bbb7f0bf35c87edbc8d23e3062 upstream.
+
+The following commands will crash the kernel:
+
+modprobe brd rd_size=1048576
+dmsetup create o --table "0 `blockdev --getsize /dev/ram0` snapshot-origin /dev/ram0"
+dmsetup create s --table "0 `blockdev --getsize /dev/ram0` snapshot /dev/ram0 /dev/ram1 N 0"
+
+The reason is that when we test for zero chunk size, we jump to the label
+bad_read_metadata without setting the "r" variable. The function
+snapshot_ctr destroys all the structures and then exits with "r == 0". The
+kernel then crashes because it falsely believes that snapshot_ctr
+succeeded.
+
+In order to fix the bug, we set the variable "r" to -EINVAL.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-snap.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/md/dm-snap.c
++++ b/drivers/md/dm-snap.c
+@@ -1407,6 +1407,7 @@ static int snapshot_ctr(struct dm_target
+
+ if (!s->store->chunk_size) {
+ ti->error = "Chunk size not set";
++ r = -EINVAL;
+ goto bad_read_metadata;
+ }
+
--- /dev/null
+From 7e008b02557ccece4d2c31fb0eaf6243cbc87121 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+Date: Mon, 17 May 2021 13:20:17 +0200
+Subject: dma-buf: fix unintended pin/unpin warnings
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Christian König <christian.koenig@amd.com>
+
+commit 7e008b02557ccece4d2c31fb0eaf6243cbc87121 upstream.
+
+DMA-buf internal users call the pin/unpin functions without having a
+dynamic attachment. Avoid the warning and backtrace in the logs.
+
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Bugs: https://gitlab.freedesktop.org/drm/intel/-/issues/3481
+Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin")
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+CC: stable@kernel.org
+Link: https://patchwork.freedesktop.org/patch/msgid/20210517115705.2141-1-christian.koenig@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma-buf/dma-buf.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/dma-buf/dma-buf.c
++++ b/drivers/dma-buf/dma-buf.c
+@@ -760,7 +760,7 @@ dma_buf_dynamic_attach(struct dma_buf *d
+
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+- ret = dma_buf_pin(attach);
++ ret = dmabuf->ops->pin(attach);
+ if (ret)
+ goto err_unlock;
+ }
+@@ -786,7 +786,7 @@ err_attach:
+
+ err_unpin:
+ if (dma_buf_is_dynamic(attach->dmabuf))
+- dma_buf_unpin(attach);
++ dmabuf->ops->unpin(attach);
+
+ err_unlock:
+ if (dma_buf_is_dynamic(attach->dmabuf))
+@@ -843,7 +843,7 @@ void dma_buf_detach(struct dma_buf *dmab
+ __unmap_dma_buf(attach, attach->sgt, attach->dir);
+
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
+- dma_buf_unpin(attach);
++ dmabuf->ops->unpin(attach);
+ dma_resv_unlock(attach->dmabuf->resv);
+ }
+ }
+@@ -956,7 +956,7 @@ struct sg_table *dma_buf_map_attachment(
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
+ dma_resv_assert_held(attach->dmabuf->resv);
+ if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
+- r = dma_buf_pin(attach);
++ r = attach->dmabuf->ops->pin(attach);
+ if (r)
+ return ERR_PTR(r);
+ }
+@@ -968,7 +968,7 @@ struct sg_table *dma_buf_map_attachment(
+
+ if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) &&
+ !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
+- dma_buf_unpin(attach);
++ attach->dmabuf->ops->unpin(attach);
+
+ if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
+ attach->sgt = sg_table;
--- /dev/null
+From dbd1003d1252db5973dddf20b24bb0106ac52aa2 Mon Sep 17 00:00:00 2001
+From: Changfeng <Changfeng.Zhu@amd.com>
+Date: Fri, 14 May 2021 15:28:25 +0800
+Subject: drm/amdgpu: disable 3DCGCG on picasso/raven1 to avoid compute hang
+
+From: Changfeng <Changfeng.Zhu@amd.com>
+
+commit dbd1003d1252db5973dddf20b24bb0106ac52aa2 upstream.
+
+There is problem with 3DCGCG firmware and it will cause compute test
+hang on picasso/raven1. It needs to disable 3DCGCG in driver to avoid
+compute hang.
+
+Signed-off-by: Changfeng <Changfeng.Zhu@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Huang Rui <ray.huang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10 +++++++---
+ drivers/gpu/drm/amd/amdgpu/soc15.c | 2 --
+ 2 files changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+@@ -4864,7 +4864,7 @@ static void gfx_v9_0_update_3d_clock_gat
+ amdgpu_gfx_rlc_enter_safe_mode(adev);
+
+ /* Enable 3D CGCG/CGLS */
+- if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_3D_CGCG)) {
++ if (enable) {
+ /* write cmd to clear cgcg/cgls ov */
+ def = data = RREG32_SOC15(GC, 0, mmRLC_CGTT_MGCG_OVERRIDE);
+ /* unset CGCG override */
+@@ -4876,8 +4876,12 @@ static void gfx_v9_0_update_3d_clock_gat
+ /* enable 3Dcgcg FSM(0x0000363f) */
+ def = RREG32_SOC15(GC, 0, mmRLC_CGCG_CGLS_CTRL_3D);
+
+- data = (0x36 << RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
+- RLC_CGCG_CGLS_CTRL_3D__CGCG_EN_MASK;
++ if (adev->cg_flags & AMD_CG_SUPPORT_GFX_3D_CGCG)
++ data = (0x36 << RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT) |
++ RLC_CGCG_CGLS_CTRL_3D__CGCG_EN_MASK;
++ else
++ data = 0x0 << RLC_CGCG_CGLS_CTRL_3D__CGCG_GFX_IDLE_THRESHOLD__SHIFT;
++
+ if (adev->cg_flags & AMD_CG_SUPPORT_GFX_3D_CGLS)
+ data |= (0x000F << RLC_CGCG_CGLS_CTRL_3D__CGLS_REP_COMPANSAT_DELAY__SHIFT) |
+ RLC_CGCG_CGLS_CTRL_3D__CGLS_EN_MASK;
+--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
++++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
+@@ -1151,7 +1151,6 @@ static int soc15_common_early_init(void
+ adev->cg_flags = AMD_CG_SUPPORT_GFX_MGCG |
+ AMD_CG_SUPPORT_GFX_MGLS |
+ AMD_CG_SUPPORT_GFX_CP_LS |
+- AMD_CG_SUPPORT_GFX_3D_CGCG |
+ AMD_CG_SUPPORT_GFX_3D_CGLS |
+ AMD_CG_SUPPORT_GFX_CGCG |
+ AMD_CG_SUPPORT_GFX_CGLS |
+@@ -1170,7 +1169,6 @@ static int soc15_common_early_init(void
+ AMD_CG_SUPPORT_GFX_MGLS |
+ AMD_CG_SUPPORT_GFX_RLC_LS |
+ AMD_CG_SUPPORT_GFX_CP_LS |
+- AMD_CG_SUPPORT_GFX_3D_CGCG |
+ AMD_CG_SUPPORT_GFX_3D_CGLS |
+ AMD_CG_SUPPORT_GFX_CGCG |
+ AMD_CG_SUPPORT_GFX_CGLS |
--- /dev/null
+From d53751568359e5b3ffb859b13cbd79dc77a571f1 Mon Sep 17 00:00:00 2001
+From: Yi Li <liyi@loongson.cn>
+Date: Fri, 14 May 2021 14:40:39 +0800
+Subject: drm/amdgpu: Fix GPU TLB update error when PAGE_SIZE > AMDGPU_PAGE_SIZE
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yi Li <liyi@loongson.cn>
+
+commit d53751568359e5b3ffb859b13cbd79dc77a571f1 upstream.
+
+When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB
+entries which need to update in amdgpu_map_buffer() should be multiplied
+by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE).
+
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Yi Li <liyi@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+@@ -267,7 +267,7 @@ static int amdgpu_ttm_map_buffer(struct
+ *addr += offset & ~PAGE_MASK;
+
+ num_dw = ALIGN(adev->mman.buffer_funcs->copy_num_dw, 8);
+- num_bytes = num_pages * 8;
++ num_bytes = num_pages * 8 * AMDGPU_GPU_PAGES_IN_CPU_PAGE;
+
+ r = amdgpu_job_alloc_with_ib(adev, num_dw * 4 + num_bytes,
+ AMDGPU_IB_POOL_DELAYED, &job);
--- /dev/null
+From 99c45ba5799d6b938bd9bd20edfeb6f3e3e039b9 Mon Sep 17 00:00:00 2001
+From: Guchun Chen <guchun.chen@amd.com>
+Date: Mon, 17 May 2021 16:35:40 +0800
+Subject: drm/amdgpu: update gc golden setting for Navi12
+
+From: Guchun Chen <guchun.chen@amd.com>
+
+commit 99c45ba5799d6b938bd9bd20edfeb6f3e3e039b9 upstream.
+
+Current golden setting is out of date.
+
+Signed-off-by: Guchun Chen <guchun.chen@amd.com>
+Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+@@ -1391,9 +1391,10 @@ static const struct soc15_reg_golden gol
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG, 0xffffffff, 0x20000000),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG2, 0xffffffff, 0x00000420),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG3, 0xffffffff, 0x00000200),
+- SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG4, 0xffffffff, 0x04800000),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DEBUG4, 0xffffffff, 0x04900000),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_DFSM_TILES_IN_FLIGHT, 0x0000ffff, 0x0000003f),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmDB_LAST_OF_BURST_CONFIG, 0xffffffff, 0x03860204),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGB_ADDR_CONFIG, 0x0c1800ff, 0x00000044),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGCR_GENERAL_CNTL, 0x1ff0ffff, 0x00000500),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGE_PRIV_CONTROL, 0x00007fff, 0x000001fe),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmGL1_PIPE_STEER, 0xffffffff, 0xe4e4e4e4),
+@@ -1411,12 +1412,13 @@ static const struct soc15_reg_golden gol
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmPA_SC_ENHANCE_2, 0x00000820, 0x00000820),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmPA_SC_LINE_STIPPLE_STATE, 0x0000ff0f, 0x00000000),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmRMI_SPARE, 0xffffffff, 0xffff3101),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSPI_CONFIG_CNTL_1, 0x001f0000, 0x00070104),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_ALU_CLK_CTRL, 0xffffffff, 0xffffffff),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_ARB_CONFIG, 0x00000133, 0x00000130),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSQ_LDS_CLK_CTRL, 0xffffffff, 0xffffffff),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmTA_CNTL_AUX, 0xfff7ffff, 0x01030000),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmTCP_CNTL, 0xffdf80ff, 0x479c0010),
+- SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0xffffffff, 0x00800000)
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmUTCL1_CTRL, 0xffffffff, 0x00c00000)
+ };
+
+ static void gfx_v10_rlcg_wreg(struct amdgpu_device *adev, u32 offset, u32 v)
--- /dev/null
+From 77194d8642dd4cb7ea8ced77bfaea55610574c38 Mon Sep 17 00:00:00 2001
+From: Guchun Chen <guchun.chen@amd.com>
+Date: Mon, 17 May 2021 16:38:00 +0800
+Subject: drm/amdgpu: update sdma golden setting for Navi12
+
+From: Guchun Chen <guchun.chen@amd.com>
+
+commit 77194d8642dd4cb7ea8ced77bfaea55610574c38 upstream.
+
+Current golden setting is out of date.
+
+Signed-off-by: Guchun Chen <guchun.chen@amd.com>
+Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
+@@ -123,6 +123,10 @@ static const struct soc15_reg_golden gol
+
+ static const struct soc15_reg_golden golden_settings_sdma_nv12[] = {
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA0_RLC3_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA0_GB_ADDR_CONFIG, 0x001877ff, 0x00000044),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA0_GB_ADDR_CONFIG_READ, 0x001877ff, 0x00000044),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA1_GB_ADDR_CONFIG, 0x001877ff, 0x00000044),
++ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA1_GB_ADDR_CONFIG_READ, 0x001877ff, 0x00000044),
+ SOC15_REG_GOLDEN_VALUE(GC, 0, mmSDMA1_RLC3_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000),
+ };
+
--- /dev/null
+From 0c8df343c200529e6b9820bdfed01814140f75e4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+Date: Wed, 12 May 2021 10:36:43 +0200
+Subject: drm/radeon: use the dummy page for GART if needed
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Christian König <christian.koenig@amd.com>
+
+commit 0c8df343c200529e6b9820bdfed01814140f75e4 upstream.
+
+Imported BOs don't have a pagelist any more.
+
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Fixes: 0575ff3d33cd ("drm/radeon: stop using pages with drm_prime_sg_to_page_addr_arrays v2")
+CC: stable@vger.kernel.org # 5.12
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/radeon/radeon_gart.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/radeon/radeon_gart.c
++++ b/drivers/gpu/drm/radeon/radeon_gart.c
+@@ -301,7 +301,8 @@ int radeon_gart_bind(struct radeon_devic
+ p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
+
+ for (i = 0; i < pages; i++, p++) {
+- rdev->gart.pages[p] = pagelist[i];
++ rdev->gart.pages[p] = pagelist ? pagelist[i] :
++ rdev->dummy_page.page;
+ page_base = dma_addr[i];
+ for (j = 0; j < (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); j++, t++) {
+ page_entry = radeon_gart_get_page_entry(page_base, flags);
--- /dev/null
+From bdbe871ef0caa660e16461a2a94579d9f9ef7ba4 Mon Sep 17 00:00:00 2001
+From: Jon Hunter <jonathanh@nvidia.com>
+Date: Fri, 7 May 2021 11:34:11 +0100
+Subject: gpio: tegra186: Don't set parent IRQ affinity
+
+From: Jon Hunter <jonathanh@nvidia.com>
+
+commit bdbe871ef0caa660e16461a2a94579d9f9ef7ba4 upstream.
+
+When hotplugging CPUs on Tegra186 and Tegra194 errors such as the
+following are seen ...
+
+ IRQ63: set affinity failed(-22).
+ IRQ65: set affinity failed(-22).
+ IRQ66: set affinity failed(-22).
+ IRQ67: set affinity failed(-22).
+
+Looking at the /proc/interrupts the above are all interrupts associated
+with GPIOs. The reason why these error messages occur is because there
+is no 'parent_data' associated with any of the GPIO interrupts and so
+tegra186_irq_set_affinity() simply returns -EINVAL.
+
+To understand why there is no 'parent_data' it is first necessary to
+understand that in addition to the GPIO interrupts being routed to the
+interrupt controller (GIC), the interrupts for some GPIOs are also
+routed to the Tegra Power Management Controller (PMC) to wake up the
+system from low power states. In order to configure GPIO events as
+wake events in the PMC, the PMC is configured as IRQ parent domain
+for the GPIO IRQ domain. Originally the GIC was the IRQ parent domain
+of the PMC and although this was working, this started causing issues
+once commit 64a267e9a41c ("irqchip/gic: Configure SGIs as standard
+interrupts") was added, because technically, the GIC is not a parent
+of the PMC. Commit c351ab7bf2a5 ("soc/tegra: pmc: Don't create fake
+interrupt hierarchy levels") fixed this by severing the IRQ domain
+hierarchy for the Tegra GPIOs and hence, there may be no IRQ parent
+domain for the GPIOs.
+
+The GPIO controllers on Tegra186 and Tegra194 have either one or six
+interrupt lines to the interrupt controller. For GPIO controllers with
+six interrupts, the mapping of the GPIO interrupt to the controller
+interrupt is configurable within the GPIO controller. Currently a
+default mapping is used, however, it could be possible to use the
+set affinity callback for the Tegra186 GPIO driver to do something a
+bit more interesting. Currently, because interrupts for all GPIOs are
+have the same mapping and any attempts to configure the affinity for
+a given GPIO can conflict with another that shares the same IRQ, for
+now it is simpler to just remove set affinity support and this avoids
+the above warnings being seen.
+
+Cc: <stable@vger.kernel.org>
+Fixes: c4e1f7d92cd6 ("gpio: tegra186: Set affinity callback to parent")
+Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-tegra186.c | 11 -----------
+ 1 file changed, 11 deletions(-)
+
+--- a/drivers/gpio/gpio-tegra186.c
++++ b/drivers/gpio/gpio-tegra186.c
+@@ -444,16 +444,6 @@ static int tegra186_irq_set_wake(struct
+ return 0;
+ }
+
+-static int tegra186_irq_set_affinity(struct irq_data *data,
+- const struct cpumask *dest,
+- bool force)
+-{
+- if (data->parent_data)
+- return irq_chip_set_affinity_parent(data, dest, force);
+-
+- return -EINVAL;
+-}
+-
+ static void tegra186_gpio_irq(struct irq_desc *desc)
+ {
+ struct tegra_gpio *gpio = irq_desc_get_handler_data(desc);
+@@ -700,7 +690,6 @@ static int tegra186_gpio_probe(struct pl
+ gpio->intc.irq_unmask = tegra186_irq_unmask;
+ gpio->intc.irq_set_type = tegra186_irq_set_type;
+ gpio->intc.irq_set_wake = tegra186_irq_set_wake;
+- gpio->intc.irq_set_affinity = tegra186_irq_set_affinity;
+
+ irq = &gpio->gpio.irq;
+ irq->chip = &gpio->intc;
--- /dev/null
+From a11ddb37bf367e6b5239b95ca759e5389bb46048 Mon Sep 17 00:00:00 2001
+From: Varad Gautam <varad.gautam@suse.com>
+Date: Sat, 22 May 2021 17:41:49 -0700
+Subject: ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry
+
+From: Varad Gautam <varad.gautam@suse.com>
+
+commit a11ddb37bf367e6b5239b95ca759e5389bb46048 upstream.
+
+do_mq_timedreceive calls wq_sleep with a stack local address. The
+sender (do_mq_timedsend) uses this address to later call pipelined_send.
+
+This leads to a very hard to trigger race where a do_mq_timedreceive
+call might return and leave do_mq_timedsend to rely on an invalid
+address, causing the following crash:
+
+ RIP: 0010:wake_q_add_safe+0x13/0x60
+ Call Trace:
+ __x64_sys_mq_timedsend+0x2a9/0x490
+ do_syscall_64+0x80/0x680
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ RIP: 0033:0x7f5928e40343
+
+The race occurs as:
+
+1. do_mq_timedreceive calls wq_sleep with the address of `struct
+ ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it
+ holds a valid `struct ext_wait_queue *` as long as the stack has not
+ been overwritten.
+
+2. `ewq_addr` gets added to info->e_wait_q[RECV].list in wq_add, and
+ do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call
+ __pipelined_op.
+
+3. Sender calls __pipelined_op::smp_store_release(&this->state,
+ STATE_READY). Here is where the race window begins. (`this` is
+ `ewq_addr`.)
+
+4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it
+ will see `state == STATE_READY` and break.
+
+5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed
+ to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive's
+ stack. (Although the address may not get overwritten until another
+ function happens to touch it, which means it can persist around for an
+ indefinite time.)
+
+6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a
+ `struct ext_wait_queue *`, and uses it to find a task_struct to pass to
+ the wake_q_add_safe call. In the lucky case where nothing has
+ overwritten `ewq_addr` yet, `ewq_addr->task` is the right task_struct.
+ In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a
+ bogus address as the receiver's task_struct causing the crash.
+
+do_mq_timedsend::__pipelined_op() should not dereference `this` after
+setting STATE_READY, as the receiver counterpart is now free to return.
+Change __pipelined_op to call wake_q_add_safe on the receiver's
+task_struct returned by get_task_struct, instead of dereferencing `this`
+which sits on the receiver's stack.
+
+As Manfred pointed out, the race potentially also exists in
+ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix
+those in the same way.
+
+Link: https://lkml.kernel.org/r/20210510102950.12551-1-varad.gautam@suse.com
+Fixes: c5b2cbdbdac563 ("ipc/mqueue.c: update/document memory barriers")
+Fixes: 8116b54e7e23ef ("ipc/sem.c: document and update memory barriers")
+Fixes: 0d97a82ba830d8 ("ipc/msg.c: update and document memory barriers")
+Signed-off-by: Varad Gautam <varad.gautam@suse.com>
+Reported-by: Matthias von Faber <matthias.vonfaber@aox-tech.de>
+Acked-by: Davidlohr Bueso <dbueso@suse.de>
+Acked-by: Manfred Spraul <manfred@colorfullife.com>
+Cc: Christian Brauner <christian.brauner@ubuntu.com>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ ipc/mqueue.c | 6 ++++--
+ ipc/msg.c | 6 ++++--
+ ipc/sem.c | 6 ++++--
+ 3 files changed, 12 insertions(+), 6 deletions(-)
+
+--- a/ipc/mqueue.c
++++ b/ipc/mqueue.c
+@@ -1004,12 +1004,14 @@ static inline void __pipelined_op(struct
+ struct mqueue_inode_info *info,
+ struct ext_wait_queue *this)
+ {
++ struct task_struct *task;
++
+ list_del(&this->list);
+- get_task_struct(this->task);
++ task = get_task_struct(this->task);
+
+ /* see MQ_BARRIER for purpose/pairing */
+ smp_store_release(&this->state, STATE_READY);
+- wake_q_add_safe(wake_q, this->task);
++ wake_q_add_safe(wake_q, task);
+ }
+
+ /* pipelined_send() - send a message directly to the task waiting in
+--- a/ipc/msg.c
++++ b/ipc/msg.c
+@@ -251,11 +251,13 @@ static void expunge_all(struct msg_queue
+ struct msg_receiver *msr, *t;
+
+ list_for_each_entry_safe(msr, t, &msq->q_receivers, r_list) {
+- get_task_struct(msr->r_tsk);
++ struct task_struct *r_tsk;
++
++ r_tsk = get_task_struct(msr->r_tsk);
+
+ /* see MSG_BARRIER for purpose/pairing */
+ smp_store_release(&msr->r_msg, ERR_PTR(res));
+- wake_q_add_safe(wake_q, msr->r_tsk);
++ wake_q_add_safe(wake_q, r_tsk);
+ }
+ }
+
+--- a/ipc/sem.c
++++ b/ipc/sem.c
+@@ -784,12 +784,14 @@ would_block:
+ static inline void wake_up_sem_queue_prepare(struct sem_queue *q, int error,
+ struct wake_q_head *wake_q)
+ {
+- get_task_struct(q->sleeper);
++ struct task_struct *sleeper;
++
++ sleeper = get_task_struct(q->sleeper);
+
+ /* see SEM_BARRIER_2 for purpuse/pairing */
+ smp_store_release(&q->status, error);
+
+- wake_q_add_safe(wake_q, q->sleeper);
++ wake_q_add_safe(wake_q, sleeper);
+ }
+
+ static void unlink_queue(struct sem_array *sma, struct sem_queue *q)
--- /dev/null
+From 976aac5f882989e4f6c1b3a7224819bf0e801c6a Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 14 May 2021 16:00:08 +0200
+Subject: kcsan: Fix debugfs initcall return type
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 976aac5f882989e4f6c1b3a7224819bf0e801c6a upstream.
+
+clang with CONFIG_LTO_CLANG points out that an initcall function should
+return an 'int' due to the changes made to the initcall macros in commit
+3578ad11f3fb ("init: lto: fix PREL32 relocations"):
+
+kernel/kcsan/debugfs.c:274:15: error: returning 'void' from a function with incompatible result type 'int'
+late_initcall(kcsan_debugfs_init);
+~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
+include/linux/init.h:292:46: note: expanded from macro 'late_initcall'
+ #define late_initcall(fn) __define_initcall(fn, 7)
+
+Fixes: e36299efe7d7 ("kcsan, debugfs: Move debugfs file creation out of early init")
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Reviewed-by: Marco Elver <elver@google.com>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/kcsan/debugfs.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/kcsan/debugfs.c
++++ b/kernel/kcsan/debugfs.c
+@@ -261,9 +261,10 @@ static const struct file_operations debu
+ .release = single_release
+ };
+
+-static void __init kcsan_debugfs_init(void)
++static int __init kcsan_debugfs_init(void)
+ {
+ debugfs_create_file("kcsan", 0644, NULL, NULL, &debugfs_ops);
++ return 0;
+ }
+
+ late_initcall(kcsan_debugfs_init);
--- /dev/null
+From 9b81354d7ebc1fd17f666a168dcabf27dae290bd Mon Sep 17 00:00:00 2001
+From: Neil Armstrong <narmstrong@baylibre.com>
+Date: Mon, 26 Apr 2021 19:55:59 +0200
+Subject: mmc: meson-gx: also check SD_IO_RW_EXTENDED for scatterlist size alignment
+
+From: Neil Armstrong <narmstrong@baylibre.com>
+
+commit 9b81354d7ebc1fd17f666a168dcabf27dae290bd upstream.
+
+The brcmfmac driver can generate a scatterlist from a skb with each packets
+not aligned to the block size. This is not supported by the Amlogic Descriptor
+dma engine where each descriptor must match a multiple of the block size.
+
+The sg list is valid, since the sum of the sg buffers is a multiple of the
+block size, but we must discard those when in SD_IO_RW_EXTENDED mode since
+SDIO block mode can be used under the hood even with data->blocks == 1.
+
+Those transfers are very rare, thus can be replaced by a bounce buffer
+without real performance loss.
+
+Fixes: 7412dee9f1fd ("mmc: meson-gx: replace WARN_ONCE with dev_warn_once about scatterlist size alignment in block mode")
+Cc: stable@vger.kernel.org
+Reported-by: Christian Hewitt <christianshewitt@gmail.com>
+Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
+Link: https://lore.kernel.org/r/20210426175559.3110575-2-narmstrong@baylibre.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/meson-gx-mmc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/meson-gx-mmc.c
++++ b/drivers/mmc/host/meson-gx-mmc.c
+@@ -236,7 +236,8 @@ static void meson_mmc_get_transfer_mode(
+ if (host->dram_access_quirk)
+ return;
+
+- if (data->blocks > 1) {
++ /* SD_IO_RW_EXTENDED (CMD53) can also use block mode under the hood */
++ if (data->blocks > 1 || mrq->cmd->opcode == SD_IO_RW_EXTENDED) {
+ /*
+ * In block mode DMA descriptor format, "length" field indicates
+ * number of blocks and there is no way to pass DMA size that
--- /dev/null
+From cabb1bb60e88ccaaa122ba01862403cd44e8e8f8 Mon Sep 17 00:00:00 2001
+From: Neil Armstrong <narmstrong@baylibre.com>
+Date: Mon, 26 Apr 2021 19:55:58 +0200
+Subject: mmc: meson-gx: make replace WARN_ONCE with dev_warn_once about scatterlist offset alignment
+
+From: Neil Armstrong <narmstrong@baylibre.com>
+
+commit cabb1bb60e88ccaaa122ba01862403cd44e8e8f8 upstream.
+
+Some drivers like ath10k can sometimg give an sg buffer with an offset whose alignment
+is not compatible with the Amlogic DMA descriptor engine requirements.
+
+Simply replace with dev_warn_once() to inform user this should be fixed to avoid
+degraded performance.
+
+This should be ultimately fixed in ath10k, but since it's only a performance issue
+the warning should be removed.
+
+Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode")
+Cc: stable@vger.kernel.org
+Reported-by: Christian Hewitt <christianshewitt@gmail.com>
+Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
+Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Link: https://lore.kernel.org/r/20210426175559.3110575-1-narmstrong@baylibre.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/meson-gx-mmc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/meson-gx-mmc.c
++++ b/drivers/mmc/host/meson-gx-mmc.c
+@@ -258,7 +258,9 @@ static void meson_mmc_get_transfer_mode(
+ for_each_sg(data->sg, sg, data->sg_len, i) {
+ /* check for 8 byte alignment */
+ if (sg->offset % 8) {
+- WARN_ONCE(1, "unaligned scatterlist buffer\n");
++ dev_warn_once(mmc_dev(mmc),
++ "unaligned sg offset %u, disabling descriptor DMA for transfer\n",
++ sg->offset);
+ return;
+ }
+ }
--- /dev/null
+From a1149a6c06ee094a6e62886b0c0e8e66967a728a Mon Sep 17 00:00:00 2001
+From: Daniel Beer <dlbeer@gmail.com>
+Date: Sat, 24 Apr 2021 20:16:52 +1200
+Subject: mmc: sdhci-pci-gli: increase 1.8V regulator wait
+
+From: Daniel Beer <dlbeer@gmail.com>
+
+commit a1149a6c06ee094a6e62886b0c0e8e66967a728a upstream.
+
+Inserting an SD-card on an Intel NUC10i3FNK4 (which contains a GL9755)
+results in the message:
+
+ mmc0: 1.8V regulator output did not become stable
+
+Following this message, some cards work (sometimes), but most cards fail
+with EILSEQ. This behaviour is observed on Debian 10 running kernel
+4.19.188, but also with 5.8.18 and 5.11.15.
+
+The driver currently waits 5ms after switching on the 1.8V regulator for
+it to become stable. Increasing this to 10ms gets rid of the warning
+about stability, but most cards still fail. Increasing it to 20ms gets
+some cards working (a 32GB Samsung micro SD works, a 128GB ADATA
+doesn't). At 50ms, the ADATA works most of the time, and at 100ms both
+cards work reliably.
+
+Signed-off-by: Daniel Beer <dlbeer@gmail.com>
+Acked-by: Ben Chuang <benchuanggli@gmail.com>
+Fixes: e51df6ce668a ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210424081652.GA16047@nyquist.nev
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pci-gli.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-pci-gli.c
++++ b/drivers/mmc/host/sdhci-pci-gli.c
+@@ -587,8 +587,13 @@ static void sdhci_gli_voltage_switch(str
+ *
+ * Wait 5ms after set 1.8V signal enable in Host Control 2 register
+ * to ensure 1.8V signal enable bit is set by GL9750/GL9755.
++ *
++ * ...however, the controller in the NUC10i3FNK4 (a 9755) requires
++ * slightly longer than 5ms before the control register reports that
++ * 1.8V is ready, and far longer still before the card will actually
++ * work reliably.
+ */
+- usleep_range(5000, 5500);
++ usleep_range(100000, 110000);
+ }
+
+ static void sdhci_gl9750_reset(struct sdhci_host *host, u8 mask)
--- /dev/null
+From d72500f992849d31ebae8f821a023660ddd0dcc2 Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Thu, 20 May 2021 21:19:31 +1000
+Subject: powerpc/64s/syscall: Fix ptrace syscall info with scv syscalls
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit d72500f992849d31ebae8f821a023660ddd0dcc2 upstream.
+
+The scv implementation missed updating syscall return value and error
+value get/set functions to deal with the changed register ABI. This
+broke ptrace PTRACE_GET_SYSCALL_INFO as well as some kernel auditing
+and tracing functions.
+
+Fix. tools/testing/selftests/ptrace/get_syscall_info now passes when
+scv is used.
+
+Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
+Cc: stable@vger.kernel.org # v5.9+
+Reported-by: "Dmitry V. Levin" <ldv@altlinux.org>
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Reviewed-by: Dmitry V. Levin <ldv@altlinux.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210520111931.2597127-2-npiggin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/include/asm/ptrace.h | 45 +++++++++++++++++++++----------------
+ arch/powerpc/include/asm/syscall.h | 42 +++++++++++++++++++++-------------
+ 2 files changed, 52 insertions(+), 35 deletions(-)
+
+--- a/arch/powerpc/include/asm/ptrace.h
++++ b/arch/powerpc/include/asm/ptrace.h
+@@ -19,6 +19,7 @@
+ #ifndef _ASM_POWERPC_PTRACE_H
+ #define _ASM_POWERPC_PTRACE_H
+
++#include <linux/err.h>
+ #include <uapi/asm/ptrace.h>
+ #include <asm/asm-const.h>
+
+@@ -152,25 +153,6 @@ extern unsigned long profile_pc(struct p
+ long do_syscall_trace_enter(struct pt_regs *regs);
+ void do_syscall_trace_leave(struct pt_regs *regs);
+
+-#define kernel_stack_pointer(regs) ((regs)->gpr[1])
+-static inline int is_syscall_success(struct pt_regs *regs)
+-{
+- return !(regs->ccr & 0x10000000);
+-}
+-
+-static inline long regs_return_value(struct pt_regs *regs)
+-{
+- if (is_syscall_success(regs))
+- return regs->gpr[3];
+- else
+- return -regs->gpr[3];
+-}
+-
+-static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
+-{
+- regs->gpr[3] = rc;
+-}
+-
+ #ifdef __powerpc64__
+ #define user_mode(regs) ((((regs)->msr) >> MSR_PR_LG) & 0x1)
+ #else
+@@ -252,6 +234,31 @@ static inline void set_trap_norestart(st
+ regs->trap |= 0x10;
+ }
+
++#define kernel_stack_pointer(regs) ((regs)->gpr[1])
++static inline int is_syscall_success(struct pt_regs *regs)
++{
++ if (trap_is_scv(regs))
++ return !IS_ERR_VALUE((unsigned long)regs->gpr[3]);
++ else
++ return !(regs->ccr & 0x10000000);
++}
++
++static inline long regs_return_value(struct pt_regs *regs)
++{
++ if (trap_is_scv(regs))
++ return regs->gpr[3];
++
++ if (is_syscall_success(regs))
++ return regs->gpr[3];
++ else
++ return -regs->gpr[3];
++}
++
++static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
++{
++ regs->gpr[3] = rc;
++}
++
+ #define arch_has_single_step() (1)
+ #define arch_has_block_step() (true)
+ #define ARCH_HAS_USER_SINGLE_STEP_REPORT
+--- a/arch/powerpc/include/asm/syscall.h
++++ b/arch/powerpc/include/asm/syscall.h
+@@ -41,11 +41,17 @@ static inline void syscall_rollback(stru
+ static inline long syscall_get_error(struct task_struct *task,
+ struct pt_regs *regs)
+ {
+- /*
+- * If the system call failed,
+- * regs->gpr[3] contains a positive ERRORCODE.
+- */
+- return (regs->ccr & 0x10000000UL) ? -regs->gpr[3] : 0;
++ if (trap_is_scv(regs)) {
++ unsigned long error = regs->gpr[3];
++
++ return IS_ERR_VALUE(error) ? error : 0;
++ } else {
++ /*
++ * If the system call failed,
++ * regs->gpr[3] contains a positive ERRORCODE.
++ */
++ return (regs->ccr & 0x10000000UL) ? -regs->gpr[3] : 0;
++ }
+ }
+
+ static inline long syscall_get_return_value(struct task_struct *task,
+@@ -58,18 +64,22 @@ static inline void syscall_set_return_va
+ struct pt_regs *regs,
+ int error, long val)
+ {
+- /*
+- * In the general case it's not obvious that we must deal with CCR
+- * here, as the syscall exit path will also do that for us. However
+- * there are some places, eg. the signal code, which check ccr to
+- * decide if the value in r3 is actually an error.
+- */
+- if (error) {
+- regs->ccr |= 0x10000000L;
+- regs->gpr[3] = error;
++ if (trap_is_scv(regs)) {
++ regs->gpr[3] = (long) error ?: val;
+ } else {
+- regs->ccr &= ~0x10000000L;
+- regs->gpr[3] = val;
++ /*
++ * In the general case it's not obvious that we must deal with
++ * CCR here, as the syscall exit path will also do that for us.
++ * However there are some places, eg. the signal code, which
++ * check ccr to decide if the value in r3 is actually an error.
++ */
++ if (error) {
++ regs->ccr |= 0x10000000L;
++ regs->gpr[3] = error;
++ } else {
++ regs->ccr &= ~0x10000000L;
++ regs->gpr[3] = val;
++ }
+ }
+ }
+
--- /dev/null
+From 5665bc35c1ed917ac8fd06cb651317bb47a65b10 Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Thu, 20 May 2021 21:19:30 +1000
+Subject: powerpc/64s/syscall: Use pt_regs.trap to distinguish syscall ABI difference between sc and scv syscalls
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit 5665bc35c1ed917ac8fd06cb651317bb47a65b10 upstream.
+
+The sc and scv 0 system calls have different ABI conventions, and
+ptracers need to know which system call type is being used if they want
+to look at the syscall registers.
+
+Document that pt_regs.trap can be used for this, and fix one in-tree user
+to work with scv 0 syscalls.
+
+Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
+Cc: stable@vger.kernel.org # v5.9+
+Reported-by: "Dmitry V. Levin" <ldv@altlinux.org>
+Suggested-by: "Dmitry V. Levin" <ldv@altlinux.org>
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210520111931.2597127-1-npiggin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/powerpc/syscall64-abi.rst | 10 +++++++++
+ tools/testing/selftests/seccomp/seccomp_bpf.c | 27 +++++++++++++++++---------
+ 2 files changed, 28 insertions(+), 9 deletions(-)
+
+--- a/Documentation/powerpc/syscall64-abi.rst
++++ b/Documentation/powerpc/syscall64-abi.rst
+@@ -109,6 +109,16 @@ auxiliary vector.
+
+ scv 0 syscalls will always behave as PPC_FEATURE2_HTM_NOSC.
+
++ptrace
++------
++When ptracing system calls (PTRACE_SYSCALL), the pt_regs.trap value contains
++the system call type that can be used to distinguish between sc and scv 0
++system calls, and the different register conventions can be accounted for.
++
++If the value of (pt_regs.trap & 0xfff0) is 0xc00 then the system call was
++performed with the sc instruction, if it is 0x3000 then the system call was
++performed with the scv 0 instruction.
++
+ vsyscall
+ ========
+
+--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
++++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
+@@ -1753,16 +1753,25 @@ TEST_F(TRACE_poke, getpid_runs_normally)
+ # define SYSCALL_RET_SET(_regs, _val) \
+ do { \
+ typeof(_val) _result = (_val); \
+- /* \
+- * A syscall error is signaled by CR0 SO bit \
+- * and the code is stored as a positive value. \
+- */ \
+- if (_result < 0) { \
+- SYSCALL_RET(_regs) = -_result; \
+- (_regs).ccr |= 0x10000000; \
+- } else { \
++ if ((_regs.trap & 0xfff0) == 0x3000) { \
++ /* \
++ * scv 0 system call uses -ve result \
++ * for error, so no need to adjust. \
++ */ \
+ SYSCALL_RET(_regs) = _result; \
+- (_regs).ccr &= ~0x10000000; \
++ } else { \
++ /* \
++ * A syscall error is signaled by the \
++ * CR0 SO bit and the code is stored as \
++ * a positive value. \
++ */ \
++ if (_result < 0) { \
++ SYSCALL_RET(_regs) = -_result; \
++ (_regs).ccr |= 0x10000000; \
++ } else { \
++ SYSCALL_RET(_regs) = _result; \
++ (_regs).ccr &= ~0x10000000; \
++ } \
+ } \
+ } while (0)
+ # define SYSCALL_RET_SET_ON_PTRACE_EXIT
--- /dev/null
+From f10628d2f613195132532e0fbda439eeed8d12a2 Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Sat, 22 May 2021 17:41:46 -0700
+Subject: Revert "mm/gup: check page posion status for coredump."
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit f10628d2f613195132532e0fbda439eeed8d12a2 upstream.
+
+While reviewing [1] I came across commit d3378e86d182 ("mm/gup: check
+page posion status for coredump.") and noticed that this patch is broken
+in two ways. First it doesn't really prevent hwpoison pages from being
+dumped because hwpoison pages can be marked asynchornously at any time
+after the check. Secondly, and more importantly, the patch introduces a
+ref count leak because get_dump_page takes a reference on the page which
+is not released.
+
+It also seems that the patch was merged incorrectly because there were
+follow up changes not included as well as discussions on how to address
+the underlying problem [2]
+
+Therefore revert the original patch.
+
+Link: http://lkml.kernel.org/r/20210429122519.15183-4-david@redhat.com [1]
+Link: http://lkml.kernel.org/r/57ac524c-b49a-99ec-c1e4-ef5027bfb61b@redhat.com [2]
+Link: https://lkml.kernel.org/r/20210505135407.31590-1-mhocko@kernel.org
+Fixes: d3378e86d182 ("mm/gup: check page posion status for coredump.")
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Cc: Aili Yao <yaoaili@kingsoft.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/gup.c | 4 ----
+ mm/internal.h | 20 --------------------
+ 2 files changed, 24 deletions(-)
+
+--- a/mm/gup.c
++++ b/mm/gup.c
+@@ -1535,10 +1535,6 @@ struct page *get_dump_page(unsigned long
+ FOLL_FORCE | FOLL_DUMP | FOLL_GET);
+ if (locked)
+ mmap_read_unlock(mm);
+-
+- if (ret == 1 && is_page_poisoned(page))
+- return NULL;
+-
+ return (ret == 1) ? page : NULL;
+ }
+ #endif /* CONFIG_ELF_CORE */
+--- a/mm/internal.h
++++ b/mm/internal.h
+@@ -97,26 +97,6 @@ static inline void set_page_refcounted(s
+ set_page_count(page, 1);
+ }
+
+-/*
+- * When kernel touch the user page, the user page may be have been marked
+- * poison but still mapped in user space, if without this page, the kernel
+- * can guarantee the data integrity and operation success, the kernel is
+- * better to check the posion status and avoid touching it, be good not to
+- * panic, coredump for process fatal signal is a sample case matching this
+- * scenario. Or if kernel can't guarantee the data integrity, it's better
+- * not to call this function, let kernel touch the poison page and get to
+- * panic.
+- */
+-static inline bool is_page_poisoned(struct page *page)
+-{
+- if (PageHWPoison(page))
+- return true;
+- else if (PageHuge(page) && PageHWPoison(compound_head(page)))
+- return true;
+-
+- return false;
+-}
+-
+ extern unsigned long highest_memmap_pfn;
+
+ /*
x86-sev-es-forward-page-faults-which-happen-during-emulation.patch
drm-i915-gem-pin-the-l-shape-quirked-object-as-unshrinkable.patch
drm-amd-display-use-the-correct-max-downscaling-value-for-dcn3.x-family.patch
+drm-radeon-use-the-dummy-page-for-gart-if-needed.patch
+drm-amdgpu-fix-gpu-tlb-update-error-when-page_size-amdgpu_page_size.patch
+drm-amdgpu-disable-3dcgcg-on-picasso-raven1-to-avoid-compute-hang.patch
+drm-amdgpu-update-gc-golden-setting-for-navi12.patch
+drm-amdgpu-update-sdma-golden-setting-for-navi12.patch
+dma-buf-fix-unintended-pin-unpin-warnings.patch
+powerpc-64s-syscall-use-pt_regs.trap-to-distinguish-syscall-abi-difference-between-sc-and-scv-syscalls.patch
+powerpc-64s-syscall-fix-ptrace-syscall-info-with-scv-syscalls.patch
+mmc-sdhci-pci-gli-increase-1.8v-regulator-wait.patch
+mmc-meson-gx-make-replace-warn_once-with-dev_warn_once-about-scatterlist-offset-alignment.patch
+mmc-meson-gx-also-check-sd_io_rw_extended-for-scatterlist-size-alignment.patch
+gpio-tegra186-don-t-set-parent-irq-affinity.patch
+xen-pciback-redo-vf-placement-in-the-virtual-topology.patch
+xen-pciback-reconfigure-also-from-backend-watch-handler.patch
+ipc-mqueue-msg-sem-avoid-relying-on-a-stack-reference-past-its-expiry.patch
+userfaultfd-hugetlbfs-fix-new-flag-usage-in-error-path.patch
+revert-mm-gup-check-page-posion-status-for-coredump.patch
+dm-snapshot-fix-a-crash-when-an-origin-has-no-snapshots.patch
+dm-snapshot-fix-crash-with-transient-storage-and-zero-chunk-size.patch
+kcsan-fix-debugfs-initcall-return-type.patch
--- /dev/null
+From e32905e57358fdfb82f9de024534f205b3af7dac Mon Sep 17 00:00:00 2001
+From: Mike Kravetz <mike.kravetz@oracle.com>
+Date: Sat, 22 May 2021 17:42:11 -0700
+Subject: userfaultfd: hugetlbfs: fix new flag usage in error path
+
+From: Mike Kravetz <mike.kravetz@oracle.com>
+
+commit e32905e57358fdfb82f9de024534f205b3af7dac upstream.
+
+In commit d6995da31122 ("hugetlb: use page.private for hugetlb specific
+page flags") the use of PagePrivate to indicate a reservation count
+should be restored at free time was changed to the hugetlb specific flag
+HPageRestoreReserve. Changes to a userfaultfd error path as well as a
+VM_BUG_ON() in remove_inode_hugepages() were overlooked.
+
+Users could see incorrect hugetlb reserve counts if they experience an
+error with a UFFDIO_COPY operation. Specifically, this would be the
+result of an unlikely copy_huge_page_from_user error. There is not an
+increased chance of hitting the VM_BUG_ON.
+
+Link: https://lkml.kernel.org/r/20210521233952.236434-1-mike.kravetz@oracle.com
+Fixes: d6995da31122 ("hugetlb: use page.private for hugetlb specific page flags")
+Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
+Reviewed-by: Mina Almasry <almasry.mina@google.com>
+Cc: Oscar Salvador <osalvador@suse.de>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Muchun Song <songmuchun@bytedance.com>
+Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Miaohe Lin <linmiaohe@huawei.com>
+Cc: Mina Almasry <almasrymina@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/hugetlbfs/inode.c | 2 +-
+ mm/userfaultfd.c | 28 ++++++++++++++--------------
+ 2 files changed, 15 insertions(+), 15 deletions(-)
+
+--- a/fs/hugetlbfs/inode.c
++++ b/fs/hugetlbfs/inode.c
+@@ -532,7 +532,7 @@ static void remove_inode_hugepages(struc
+ * the subpool and global reserve usage count can need
+ * to be adjusted.
+ */
+- VM_BUG_ON(PagePrivate(page));
++ VM_BUG_ON(HPageRestoreReserve(page));
+ remove_huge_page(page);
+ freed++;
+ if (!truncate_op) {
+--- a/mm/userfaultfd.c
++++ b/mm/userfaultfd.c
+@@ -362,38 +362,38 @@ out:
+ * If a reservation for the page existed in the reservation
+ * map of a private mapping, the map was modified to indicate
+ * the reservation was consumed when the page was allocated.
+- * We clear the PagePrivate flag now so that the global
++ * We clear the HPageRestoreReserve flag now so that the global
+ * reserve count will not be incremented in free_huge_page.
+ * The reservation map will still indicate the reservation
+ * was consumed and possibly prevent later page allocation.
+ * This is better than leaking a global reservation. If no
+- * reservation existed, it is still safe to clear PagePrivate
+- * as no adjustments to reservation counts were made during
+- * allocation.
++ * reservation existed, it is still safe to clear
++ * HPageRestoreReserve as no adjustments to reservation counts
++ * were made during allocation.
+ *
+ * The reservation map for shared mappings indicates which
+ * pages have reservations. When a huge page is allocated
+ * for an address with a reservation, no change is made to
+- * the reserve map. In this case PagePrivate will be set
+- * to indicate that the global reservation count should be
++ * the reserve map. In this case HPageRestoreReserve will be
++ * set to indicate that the global reservation count should be
+ * incremented when the page is freed. This is the desired
+ * behavior. However, when a huge page is allocated for an
+ * address without a reservation a reservation entry is added
+- * to the reservation map, and PagePrivate will not be set.
+- * When the page is freed, the global reserve count will NOT
+- * be incremented and it will appear as though we have leaked
+- * reserved page. In this case, set PagePrivate so that the
+- * global reserve count will be incremented to match the
+- * reservation map entry which was created.
++ * to the reservation map, and HPageRestoreReserve will not be
++ * set. When the page is freed, the global reserve count will
++ * NOT be incremented and it will appear as though we have
++ * leaked reserved page. In this case, set HPageRestoreReserve
++ * so that the global reserve count will be incremented to
++ * match the reservation map entry which was created.
+ *
+ * Note that vm_alloc_shared is based on the flags of the vma
+ * for which the page was originally allocated. dst_vma could
+ * be different or NULL on error.
+ */
+ if (vm_alloc_shared)
+- SetPagePrivate(page);
++ SetHPageRestoreReserve(page);
+ else
+- ClearPagePrivate(page);
++ ClearHPageRestoreReserve(page);
+ put_page(page);
+ }
+ BUG_ON(copied < 0);
--- /dev/null
+From c81d3d24602540f65256f98831d0a25599ea6b87 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <jbeulich@suse.com>
+Date: Tue, 18 May 2021 18:14:07 +0200
+Subject: xen-pciback: reconfigure also from backend watch handler
+
+From: Jan Beulich <jbeulich@suse.com>
+
+commit c81d3d24602540f65256f98831d0a25599ea6b87 upstream.
+
+When multiple PCI devices get assigned to a guest right at boot, libxl
+incrementally populates the backend tree. The writes for the first of
+the devices trigger the backend watch. In turn xen_pcibk_setup_backend()
+will set the XenBus state to Initialised, at which point no further
+reconfigures would happen unless a device got hotplugged. Arrange for
+reconfigure to also get triggered from the backend watch handler.
+
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Link: https://lore.kernel.org/r/2337cbd6-94b9-4187-9862-c03ea12e0c61@suse.com
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/xen/xen-pciback/xenbus.c | 22 +++++++++++++++++-----
+ 1 file changed, 17 insertions(+), 5 deletions(-)
+
+--- a/drivers/xen/xen-pciback/xenbus.c
++++ b/drivers/xen/xen-pciback/xenbus.c
+@@ -359,7 +359,8 @@ out:
+ return err;
+ }
+
+-static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev)
++static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev,
++ enum xenbus_state state)
+ {
+ int err = 0;
+ int num_devs;
+@@ -373,9 +374,7 @@ static int xen_pcibk_reconfigure(struct
+ dev_dbg(&pdev->xdev->dev, "Reconfiguring device ...\n");
+
+ mutex_lock(&pdev->dev_lock);
+- /* Make sure we only reconfigure once */
+- if (xenbus_read_driver_state(pdev->xdev->nodename) !=
+- XenbusStateReconfiguring)
++ if (xenbus_read_driver_state(pdev->xdev->nodename) != state)
+ goto out;
+
+ err = xenbus_scanf(XBT_NIL, pdev->xdev->nodename, "num_devs", "%d",
+@@ -500,6 +499,10 @@ static int xen_pcibk_reconfigure(struct
+ }
+ }
+
++ if (state != XenbusStateReconfiguring)
++ /* Make sure we only reconfigure once. */
++ goto out;
++
+ err = xenbus_switch_state(pdev->xdev, XenbusStateReconfigured);
+ if (err) {
+ xenbus_dev_fatal(pdev->xdev, err,
+@@ -525,7 +528,7 @@ static void xen_pcibk_frontend_changed(s
+ break;
+
+ case XenbusStateReconfiguring:
+- xen_pcibk_reconfigure(pdev);
++ xen_pcibk_reconfigure(pdev, XenbusStateReconfiguring);
+ break;
+
+ case XenbusStateConnected:
+@@ -664,6 +667,15 @@ static void xen_pcibk_be_watch(struct xe
+ xen_pcibk_setup_backend(pdev);
+ break;
+
++ case XenbusStateInitialised:
++ /*
++ * We typically move to Initialised when the first device was
++ * added. Hence subsequent devices getting added may need
++ * reconfiguring.
++ */
++ xen_pcibk_reconfigure(pdev, XenbusStateInitialised);
++ break;
++
+ default:
+ break;
+ }
--- /dev/null
+From 4ba50e7c423c29639878c00573288869aa627068 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <jbeulich@suse.com>
+Date: Tue, 18 May 2021 18:13:42 +0200
+Subject: xen-pciback: redo VF placement in the virtual topology
+
+From: Jan Beulich <jbeulich@suse.com>
+
+commit 4ba50e7c423c29639878c00573288869aa627068 upstream.
+
+The commit referenced below was incomplete: It merely affected what
+would get written to the vdev-<N> xenstore node. The guest would still
+find the function at the original function number as long as
+__xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt
+__xen_pcibk_get_pcifront_dev().
+
+Undo overriding the function to zero and instead make sure that VFs at
+function zero remain alone in their slot. This has the added benefit of
+improving overall capacity, considering that there's only a total of 32
+slots available right now (PCI segment and bus can both only ever be
+zero at present).
+
+Fixes: 8a5248fe10b1 ("xen PV passthru: assign SR-IOV virtual functions to separate virtual slots")
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Link: https://lore.kernel.org/r/8def783b-404c-3452-196d-3f3fd4d72c9e@suse.com
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/xen/xen-pciback/vpci.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/drivers/xen/xen-pciback/vpci.c
++++ b/drivers/xen/xen-pciback/vpci.c
+@@ -70,7 +70,7 @@ static int __xen_pcibk_add_pci_dev(struc
+ struct pci_dev *dev, int devid,
+ publish_pci_dev_cb publish_cb)
+ {
+- int err = 0, slot, func = -1;
++ int err = 0, slot, func = PCI_FUNC(dev->devfn);
+ struct pci_dev_entry *t, *dev_entry;
+ struct vpci_dev_data *vpci_dev = pdev->pci_dev_data;
+
+@@ -95,22 +95,25 @@ static int __xen_pcibk_add_pci_dev(struc
+
+ /*
+ * Keep multi-function devices together on the virtual PCI bus, except
+- * virtual functions.
++ * that we want to keep virtual functions at func 0 on their own. They
++ * aren't multi-function devices and hence their presence at func 0
++ * may cause guests to not scan the other functions.
+ */
+- if (!dev->is_virtfn) {
++ if (!dev->is_virtfn || func) {
+ for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
+ if (list_empty(&vpci_dev->dev_list[slot]))
+ continue;
+
+ t = list_entry(list_first(&vpci_dev->dev_list[slot]),
+ struct pci_dev_entry, list);
++ if (t->dev->is_virtfn && !PCI_FUNC(t->dev->devfn))
++ continue;
+
+ if (match_slot(dev, t->dev)) {
+ dev_info(&dev->dev, "vpci: assign to virtual slot %d func %d\n",
+- slot, PCI_FUNC(dev->devfn));
++ slot, func);
+ list_add_tail(&dev_entry->list,
+ &vpci_dev->dev_list[slot]);
+- func = PCI_FUNC(dev->devfn);
+ goto unlock;
+ }
+ }
+@@ -123,7 +126,6 @@ static int __xen_pcibk_add_pci_dev(struc
+ slot);
+ list_add_tail(&dev_entry->list,
+ &vpci_dev->dev_list[slot]);
+- func = dev->is_virtfn ? 0 : PCI_FUNC(dev->devfn);
+ goto unlock;
+ }
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
