--- /dev/null
+From b96156bc7d5bddd7831bc3ce763df20abc3070b3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Nov 2020 17:10:28 +0000
+Subject: block: don't ignore REQ_NOWAIT for direct IO
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+[ Upstream commit f8b78caf21d5bc3fcfc40c18898f9d52ed1451a5 ]
+
+If IOCB_NOWAIT is set on submission, then that needs to get propagated to
+REQ_NOWAIT on the block side. Otherwise we completely lose this
+information, and any issuer of IOCB_NOWAIT IO will potentially end up
+blocking on eg request allocation on the storage side.
+
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/block_dev.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/fs/block_dev.c b/fs/block_dev.c
+index 79272cdbe827..bd93563477a4 100644
+--- a/fs/block_dev.c
++++ b/fs/block_dev.c
+@@ -246,6 +246,8 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
+ bio.bi_opf = dio_bio_write_op(iocb);
+ task_io_account_write(ret);
+ }
++ if (iocb->ki_flags & IOCB_NOWAIT)
++ bio.bi_opf |= REQ_NOWAIT;
+ if (iocb->ki_flags & IOCB_HIPRI)
+ bio_set_polled(&bio, iocb);
+
+@@ -399,6 +401,8 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, int nr_pages)
+ bio->bi_opf = dio_bio_write_op(iocb);
+ task_io_account_write(bio->bi_iter.bi_size);
+ }
++ if (iocb->ki_flags & IOCB_NOWAIT)
++ bio->bi_opf |= REQ_NOWAIT;
+
+ dio->size += bio->bi_iter.bi_size;
+ pos += bio->bi_iter.bi_size;
+--
+2.30.2
+
--- /dev/null
+From c7e7524b4024d2a74619e61c9c12b284c7c996a2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 31 Mar 2021 07:53:59 -0400
+Subject: block: only update parent bi_status when bio fail
+
+From: Yufen Yu <yuyufen@huawei.com>
+
+[ Upstream commit 3edf5346e4f2ce2fa0c94651a90a8dda169565ee ]
+
+For multiple split bios, if one of the bio is fail, the whole
+should return error to application. But we found there is a race
+between bio_integrity_verify_fn and bio complete, which return
+io success to application after one of the bio fail. The race as
+following:
+
+split bio(READ) kworker
+
+nvme_complete_rq
+blk_update_request //split error=0
+ bio_endio
+ bio_integrity_endio
+ queue_work(kintegrityd_wq, &bip->bip_work);
+
+ bio_integrity_verify_fn
+ bio_endio //split bio
+ __bio_chain_endio
+ if (!parent->bi_status)
+
+ <interrupt entry>
+ nvme_irq
+ blk_update_request //parent error=7
+ req_bio_endio
+ bio->bi_status = 7 //parent bio
+ <interrupt exit>
+
+ parent->bi_status = 0
+ parent->bi_end_io() // return bi_status=0
+
+The bio has been split as two: split and parent. When split
+bio completed, it depends on kworker to do endio, while
+bio_integrity_verify_fn have been interrupted by parent bio
+complete irq handler. Then, parent bio->bi_status which have
+been set in irq handler will overwrite by kworker.
+
+In fact, even without the above race, we also need to conside
+the concurrency beteen mulitple split bio complete and update
+the same parent bi_status. Normally, multiple split bios will
+be issued to the same hctx and complete from the same irq
+vector. But if we have updated queue map between multiple split
+bios, these bios may complete on different hw queue and different
+irq vector. Then the concurrency update parent bi_status may
+cause the final status error.
+
+Suggested-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Yufen Yu <yuyufen@huawei.com>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Link: https://lore.kernel.org/r/20210331115359.1125679-1-yuyufen@huawei.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/bio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/block/bio.c b/block/bio.c
+index 24704bc2ad6f..cb38d6f3acce 100644
+--- a/block/bio.c
++++ b/block/bio.c
+@@ -305,7 +305,7 @@ static struct bio *__bio_chain_endio(struct bio *bio)
+ {
+ struct bio *parent = bio->bi_private;
+
+- if (!parent->bi_status)
++ if (bio->bi_status && !parent->bi_status)
+ parent->bi_status = bio->bi_status;
+ bio_put(bio);
+ return parent;
+--
+2.30.2
+
--- /dev/null
+From 2d6952b185118d09a8bcc316c635446ec613d4d1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 24 Mar 2021 17:47:41 +0100
+Subject: drm/imx: imx-ldb: fix out of bounds array access warning
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]
+
+When CONFIG_OF is disabled, building with 'make W=1' produces warnings
+about out of bounds array access:
+
+drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
+drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]
+
+Add an error check before the index is used, which helps with the
+warning, as well as any possible other error condition that may be
+triggered at runtime.
+
+The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
+but Liu Ying points out that the driver may hit the out-of-bounds
+problem at runtime anyway.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: Liu Ying <victor.liu@nxp.com>
+Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
+index d6629fc869f3..116473c2360a 100644
+--- a/drivers/gpu/drm/imx/imx-ldb.c
++++ b/drivers/gpu/drm/imx/imx-ldb.c
+@@ -197,6 +197,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
+ int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
+ int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
+
++ if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
++ dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
++ return;
++ }
++
+ drm_panel_prepare(imx_ldb_ch->panel);
+
+ if (dual) {
+@@ -255,6 +260,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
+ int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
+ u32 bus_format = imx_ldb_ch->bus_format;
+
++ if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
++ dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
++ return;
++ }
++
+ if (mode->clock > 170000) {
+ dev_warn(ldb->dev,
+ "%s: mode exceeds 170 MHz pixel clock\n", __func__);
+--
+2.30.2
+
--- /dev/null
+From 3266b0837e234cdb9799a84f5d093cbe9978550f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Mar 2021 16:15:06 +0300
+Subject: drm/tegra: dc: Don't set PLL clock to 0Hz
+
+From: Dmitry Osipenko <digetx@gmail.com>
+
+[ Upstream commit f8fb97c915954fc6de6513cdf277103b5c6df7b3 ]
+
+RGB output doesn't allow to change parent clock rate of the display and
+PCLK rate is set to 0Hz in this case. The tegra_dc_commit_state() shall
+not set the display clock to 0Hz since this change propagates to the
+parent clock. The DISP clock is defined as a NODIV clock by the tegra-clk
+driver and all NODIV clocks use the CLK_SET_RATE_PARENT flag.
+
+This bug stayed unnoticed because by default PLLP is used as the parent
+clock for the display controller and PLLP silently skips the erroneous 0Hz
+rate changes because it always has active child clocks that don't permit
+rate changes. The PLLP isn't acceptable for some devices that we want to
+upstream (like Samsung Galaxy Tab and ASUS TF700T) due to a display panel
+clock rate requirements that can't be fulfilled by using PLLP and then the
+bug pops up in this case since parent clock is set to 0Hz, killing the
+display output.
+
+Don't touch DC clock if pclk=0 in order to fix the problem.
+
+Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/tegra/dc.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
+index fbf57bc3cdab..617cbe468aec 100644
+--- a/drivers/gpu/drm/tegra/dc.c
++++ b/drivers/gpu/drm/tegra/dc.c
+@@ -1667,6 +1667,11 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
+ dev_err(dc->dev,
+ "failed to set clock rate to %lu Hz\n",
+ state->pclk);
++
++ err = clk_set_rate(dc->clk, state->pclk);
++ if (err < 0)
++ dev_err(dc->dev, "failed to set clock %pC to %lu Hz: %d\n",
++ dc->clk, state->pclk, err);
+ }
+
+ DRM_DEBUG_KMS("rate: %lu, div: %u\n", clk_get_rate(dc->clk),
+@@ -1677,11 +1682,6 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
+ value = SHIFT_CLK_DIVIDER(state->div) | PIXEL_CLK_DIVIDER_PCD1;
+ tegra_dc_writel(dc, value, DC_DISP_DISP_CLOCK_CONTROL);
+ }
+-
+- err = clk_set_rate(dc->clk, state->pclk);
+- if (err < 0)
+- dev_err(dc->dev, "failed to set clock %pC to %lu Hz: %d\n",
+- dc->clk, state->pclk, err);
+ }
+
+ static void tegra_dc_stop(struct tegra_dc *dc)
+--
+2.30.2
+
--- /dev/null
+From b037aeb2689ab40c5b592ca4990859af216448b7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 25 Mar 2021 08:51:13 -0400
+Subject: gfs2: report "already frozen/thawed" errors
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+[ Upstream commit ff132c5f93c06bd4432bbab5c369e468653bdec4 ]
+
+Before this patch, gfs2's freeze function failed to report an error
+when the target file system was already frozen as it should (and as
+generic vfs function freeze_super does. Similarly, gfs2's thaw function
+failed to report an error when trying to thaw a file system that is not
+frozen, as vfs function thaw_super does. The errors were checked, but
+it always returned a 0 return code.
+
+This patch adds the missing error return codes to gfs2 freeze and thaw.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/super.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
+index 50c925d9c610..9c593fd50c6a 100644
+--- a/fs/gfs2/super.c
++++ b/fs/gfs2/super.c
+@@ -757,11 +757,13 @@ void gfs2_freeze_func(struct work_struct *work)
+ static int gfs2_freeze(struct super_block *sb)
+ {
+ struct gfs2_sbd *sdp = sb->s_fs_info;
+- int error = 0;
++ int error;
+
+ mutex_lock(&sdp->sd_freeze_mutex);
+- if (atomic_read(&sdp->sd_freeze_state) != SFS_UNFROZEN)
++ if (atomic_read(&sdp->sd_freeze_state) != SFS_UNFROZEN) {
++ error = -EBUSY;
+ goto out;
++ }
+
+ if (test_bit(SDF_WITHDRAWN, &sdp->sd_flags)) {
+ error = -EINVAL;
+@@ -798,10 +800,10 @@ static int gfs2_unfreeze(struct super_block *sb)
+ struct gfs2_sbd *sdp = sb->s_fs_info;
+
+ mutex_lock(&sdp->sd_freeze_mutex);
+- if (atomic_read(&sdp->sd_freeze_state) != SFS_FROZEN ||
++ if (atomic_read(&sdp->sd_freeze_state) != SFS_FROZEN ||
+ !gfs2_holder_initialized(&sdp->sd_freeze_gh)) {
+ mutex_unlock(&sdp->sd_freeze_mutex);
+- return 0;
++ return -EINVAL;
+ }
+
+ gfs2_glock_dq_uninit(&sdp->sd_freeze_gh);
+--
+2.30.2
+
--- /dev/null
+From 72d10f7e4bdb2286eb27a3674a6243e615f1240a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Apr 2021 07:46:49 -0400
+Subject: idr test suite: Create anchor before launching throbber
+
+From: Matthew Wilcox (Oracle) <willy@infradead.org>
+
+[ Upstream commit 094ffbd1d8eaa27ed426feb8530cb1456348b018 ]
+
+The throbber could race with creation of the anchor entry and cause the
+IDR to have zero entries in it, which would cause the test to fail.
+
+Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/radix-tree/idr-test.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tools/testing/radix-tree/idr-test.c b/tools/testing/radix-tree/idr-test.c
+index 4a9b451b7ba0..6ce7460f3c7a 100644
+--- a/tools/testing/radix-tree/idr-test.c
++++ b/tools/testing/radix-tree/idr-test.c
+@@ -301,11 +301,11 @@ void idr_find_test_1(int anchor_id, int throbber_id)
+ pthread_t throbber;
+ time_t start = time(NULL);
+
+- pthread_create(&throbber, NULL, idr_throbber, &throbber_id);
+-
+ BUG_ON(idr_alloc(&find_idr, xa_mk_value(anchor_id), anchor_id,
+ anchor_id + 1, GFP_KERNEL) != anchor_id);
+
++ pthread_create(&throbber, NULL, idr_throbber, &throbber_id);
++
+ rcu_read_lock();
+ do {
+ int id = 0;
+--
+2.30.2
+
--- /dev/null
+From 61d32d8cab8dad6c3cda1cc225fb605e7706ae8a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Apr 2021 07:44:48 -0400
+Subject: idr test suite: Take RCU read lock in idr_find_test_1
+
+From: Matthew Wilcox (Oracle) <willy@infradead.org>
+
+[ Upstream commit 703586410da69eb40062e64d413ca33bd735917a ]
+
+When run on a single CPU, this test would frequently access already-freed
+memory. Due to timing, this bug never showed up on multi-CPU tests.
+
+Reported-by: Chris von Recklinghausen <crecklin@redhat.com>
+Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/radix-tree/idr-test.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tools/testing/radix-tree/idr-test.c b/tools/testing/radix-tree/idr-test.c
+index 44ceff95a9b3..4a9b451b7ba0 100644
+--- a/tools/testing/radix-tree/idr-test.c
++++ b/tools/testing/radix-tree/idr-test.c
+@@ -306,11 +306,15 @@ void idr_find_test_1(int anchor_id, int throbber_id)
+ BUG_ON(idr_alloc(&find_idr, xa_mk_value(anchor_id), anchor_id,
+ anchor_id + 1, GFP_KERNEL) != anchor_id);
+
++ rcu_read_lock();
+ do {
+ int id = 0;
+ void *entry = idr_get_next(&find_idr, &id);
++ rcu_read_unlock();
+ BUG_ON(entry != xa_mk_value(id));
++ rcu_read_lock();
+ } while (time(NULL) < start + 11);
++ rcu_read_unlock();
+
+ pthread_join(throbber, NULL);
+
+--
+2.30.2
+
--- /dev/null
+From 1df7622daf98b95a12db9a298f4ffbf562917de7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Mar 2021 15:09:15 +0200
+Subject: interconnect: core: fix error return code of icc_link_destroy()
+
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+
+[ Upstream commit 715ea61532e731c62392221238906704e63d75b6 ]
+
+When krealloc() fails and new is NULL, no error return code of
+icc_link_destroy() is assigned.
+To fix this bug, ret is assigned with -ENOMEM hen new is NULL.
+
+Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
+Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
+Link: https://lore.kernel.org/r/20210306132857.17020-1-baijiaju1990@gmail.com
+Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/interconnect/core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
+index c498796adc07..e579b3633a84 100644
+--- a/drivers/interconnect/core.c
++++ b/drivers/interconnect/core.c
+@@ -704,6 +704,8 @@ int icc_link_destroy(struct icc_node *src, struct icc_node *dst)
+ GFP_KERNEL);
+ if (new)
+ src->links = new;
++ else
++ ret = -ENOMEM;
+
+ out:
+ mutex_unlock(&icc_lock);
+--
+2.30.2
+
--- /dev/null
+From 3876f5388ed7a7518ad1e4be53dc7ba820cd6dc6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Mar 2021 12:06:30 +0000
+Subject: KVM: arm64: Disable guest access to trace filter controls
+
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+[ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ]
+
+Disable guest access to the Trace Filter control registers.
+We do not advertise the Trace filter feature to the guest
+(ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest
+can still access the TRFCR_EL1 unless we trap it.
+
+This will also make sure that the guest cannot fiddle with
+the filtering controls set by a nvhe host.
+
+Cc: Marc Zyngier <maz@kernel.org>
+Cc: Will Deacon <will@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20210323120647.454211-3-suzuki.poulose@arm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/include/asm/kvm_arm.h | 1 +
+ arch/arm64/kvm/debug.c | 2 ++
+ 2 files changed, 3 insertions(+)
+
+diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
+index a4ffd9b55e72..9be64c0ad31f 100644
+--- a/arch/arm64/include/asm/kvm_arm.h
++++ b/arch/arm64/include/asm/kvm_arm.h
+@@ -276,6 +276,7 @@
+ #define CPTR_EL2_DEFAULT CPTR_EL2_RES1
+
+ /* Hyp Debug Configuration Register bits */
++#define MDCR_EL2_TTRF (1 << 19)
+ #define MDCR_EL2_TPMS (1 << 14)
+ #define MDCR_EL2_E2PB_MASK (UL(0x3))
+ #define MDCR_EL2_E2PB_SHIFT (UL(12))
+diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
+index 7a7e425616b5..dbc890511631 100644
+--- a/arch/arm64/kvm/debug.c
++++ b/arch/arm64/kvm/debug.c
+@@ -89,6 +89,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
+ * - Debug ROM Address (MDCR_EL2_TDRA)
+ * - OS related registers (MDCR_EL2_TDOSA)
+ * - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
++ * - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
+ *
+ * Additionally, KVM only traps guest accesses to the debug registers if
+ * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
+@@ -112,6 +113,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
+ vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
+ vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
+ MDCR_EL2_TPMS |
++ MDCR_EL2_TTRF |
+ MDCR_EL2_TPMCR |
+ MDCR_EL2_TDRA |
+ MDCR_EL2_TDOSA);
+--
+2.30.2
+
--- /dev/null
+From 9a26e57226fe7e5d0365f38a03d713e8ef0d9a4b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Mar 2021 12:06:29 +0000
+Subject: KVM: arm64: Hide system instruction access to Trace registers
+
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]
+
+Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
+when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
+So, the guest will get an undefined instruction, if trusts the
+ID registers and access one of the trace registers.
+Lets be nice to the guest and hide the feature to avoid
+unexpected behavior.
+
+Even though this can be done at KVM sysreg emulation layer,
+we do this by removing the TRACEVER from the sanitised feature
+register field. This is fine as long as the ETM drivers
+can handle the individual trace units separately, even
+when there are differences among the CPUs.
+
+Cc: Will Deacon <will@kernel.org>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20210323120647.454211-2-suzuki.poulose@arm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/cpufeature.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
+index 79caab15ccbf..acdef8d76c64 100644
+--- a/arch/arm64/kernel/cpufeature.c
++++ b/arch/arm64/kernel/cpufeature.c
+@@ -277,7 +277,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
+ * of support.
+ */
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
+- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
+ ARM64_FTR_END,
+ };
+--
+2.30.2
+
--- /dev/null
+From cc9eddd8b7dfc2733c8e22d6748e2cdbe2c08831 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 31 Mar 2021 14:59:19 -0400
+Subject: radix tree test suite: Register the main thread with the RCU library
+
+From: Matthew Wilcox (Oracle) <willy@infradead.org>
+
+[ Upstream commit 1bb4bd266cf39fd2fa711f2d265c558b92df1119 ]
+
+Several test runners register individual worker threads with the
+RCU library, but neglect to register the main thread, which can lead
+to objects being freed while the main thread is in what appears to be
+an RCU critical section.
+
+Reported-by: Chris von Recklinghausen <crecklin@redhat.com>
+Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/radix-tree/idr-test.c | 2 ++
+ tools/testing/radix-tree/multiorder.c | 2 ++
+ tools/testing/radix-tree/xarray.c | 2 ++
+ 3 files changed, 6 insertions(+)
+
+diff --git a/tools/testing/radix-tree/idr-test.c b/tools/testing/radix-tree/idr-test.c
+index 3b796dd5e577..44ceff95a9b3 100644
+--- a/tools/testing/radix-tree/idr-test.c
++++ b/tools/testing/radix-tree/idr-test.c
+@@ -577,6 +577,7 @@ void ida_tests(void)
+
+ int __weak main(void)
+ {
++ rcu_register_thread();
+ radix_tree_init();
+ idr_checks();
+ ida_tests();
+@@ -584,5 +585,6 @@ int __weak main(void)
+ rcu_barrier();
+ if (nr_allocated)
+ printf("nr_allocated = %d\n", nr_allocated);
++ rcu_unregister_thread();
+ return 0;
+ }
+diff --git a/tools/testing/radix-tree/multiorder.c b/tools/testing/radix-tree/multiorder.c
+index 9eae0fb5a67d..e00520cc6349 100644
+--- a/tools/testing/radix-tree/multiorder.c
++++ b/tools/testing/radix-tree/multiorder.c
+@@ -224,7 +224,9 @@ void multiorder_checks(void)
+
+ int __weak main(void)
+ {
++ rcu_register_thread();
+ radix_tree_init();
+ multiorder_checks();
++ rcu_unregister_thread();
+ return 0;
+ }
+diff --git a/tools/testing/radix-tree/xarray.c b/tools/testing/radix-tree/xarray.c
+index e61e43efe463..f20e12cbbfd4 100644
+--- a/tools/testing/radix-tree/xarray.c
++++ b/tools/testing/radix-tree/xarray.c
+@@ -25,11 +25,13 @@ void xarray_tests(void)
+
+ int __weak main(void)
+ {
++ rcu_register_thread();
+ radix_tree_init();
+ xarray_tests();
+ radix_tree_cpu_dead(1);
+ rcu_barrier();
+ if (nr_allocated)
+ printf("nr_allocated = %d\n", nr_allocated);
++ rcu_unregister_thread();
+ return 0;
+ }
+--
+2.30.2
+
--- /dev/null
+From 6b9f054943945b550381a4bf7eebbb807ef19c0a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Mar 2021 16:17:25 +0800
+Subject: riscv,entry: fix misaligned base for excp_vect_table
+
+From: Zihao Yu <yuzihao@ict.ac.cn>
+
+[ Upstream commit ac8d0b901f0033b783156ab2dc1a0e73ec42409b ]
+
+In RV64, the size of each entry in excp_vect_table is 8 bytes. If the
+base of the table is not 8-byte aligned, loading an entry in the table
+will raise a misaligned exception. Although such exception will be
+handled by opensbi/bbl, this still causes performance degradation.
+
+Signed-off-by: Zihao Yu <yuzihao@ict.ac.cn>
+Reviewed-by: Anup Patel <anup@brainfault.org>
+Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/kernel/entry.S | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
+index 8ca479831142..9c87ae77ad5d 100644
+--- a/arch/riscv/kernel/entry.S
++++ b/arch/riscv/kernel/entry.S
+@@ -387,6 +387,7 @@ ENTRY(__switch_to)
+ ENDPROC(__switch_to)
+
+ .section ".rodata"
++ .align LGREG
+ /* Exception vector table */
+ ENTRY(excp_vect_table)
+ RISCV_PTR do_trap_insn_misaligned
+--
+2.30.2
+
--- /dev/null
+interconnect-core-fix-error-return-code-of-icc_link_.patch
+kvm-arm64-hide-system-instruction-access-to-trace-re.patch
+kvm-arm64-disable-guest-access-to-trace-filter-contr.patch
+drm-imx-imx-ldb-fix-out-of-bounds-array-access-warni.patch
+gfs2-report-already-frozen-thawed-errors.patch
+drm-tegra-dc-don-t-set-pll-clock-to-0hz.patch
+block-only-update-parent-bi_status-when-bio-fail.patch
+radix-tree-test-suite-register-the-main-thread-with-.patch
+idr-test-suite-take-rcu-read-lock-in-idr_find_test_1.patch
+idr-test-suite-create-anchor-before-launching-throbb.patch
+riscv-entry-fix-misaligned-base-for-excp_vect_table.patch
+block-don-t-ignore-req_nowait-for-direct-io.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
