--- /dev/null
+From 3b389cac2cd95bec95b235a674bec56faedb6974 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Sep 2020 19:16:11 +0100
+Subject: arm64: Allow CPUs unffected by ARM erratum 1418040 to come in late
+
+From: Marc Zyngier <maz@kernel.org>
+
+[ Upstream commit ed888cb0d1ebce69f12794e89fbd5e2c86d40b8d ]
+
+Now that we allow CPUs affected by erratum 1418040 to come in late,
+this prevents their unaffected sibblings from coming in late (or
+coming back after a suspend or hotplug-off, which amounts to the
+same thing).
+
+To allow this, we need to add ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
+which amounts to set .type to ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE.
+
+Fixes: bf87bb0881d0 ("arm64: Allow booting of late CPUs affected by erratum 1418040")
+Reported-by: Matthias Kaehlcke <mka@chromium.org>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
+Tested-by: Matthias Kaehlcke <mka@chromium.org>
+Acked-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20200911181611.2073183-1-maz@kernel.org
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/cpu_errata.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
+index 51462c59ab5da..d2e738c455566 100644
+--- a/arch/arm64/kernel/cpu_errata.c
++++ b/arch/arm64/kernel/cpu_errata.c
+@@ -917,8 +917,12 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
+ .desc = "ARM erratum 1418040",
+ .capability = ARM64_WORKAROUND_1418040,
+ ERRATA_MIDR_RANGE_LIST(erratum_1418040_list),
+- .type = (ARM64_CPUCAP_SCOPE_LOCAL_CPU |
+- ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU),
++ /*
++ * We need to allow affected CPUs to come in late, but
++ * also need the non-affected CPUs to be able to come
++ * in at any point in time. Wonderful.
++ */
++ .type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
+ },
+ #endif
+ #ifdef CONFIG_ARM64_ERRATUM_1165522
+--
+2.25.1
+
--- /dev/null
+From f3526be0369142fa4e3393ee52cd0497dda664e1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Sep 2020 11:49:25 +0300
+Subject: arm64: bpf: Fix branch offset in JIT
+
+From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
+
+[ Upstream commit 32f6865c7aa3c422f710903baa6eb81abc6f559b ]
+
+Running the eBPF test_verifier leads to random errors looking like this:
+
+[ 6525.735488] Unexpected kernel BRK exception at EL1
+[ 6525.735502] Internal error: ptrace BRK handler: f2000100 [#1] SMP
+[ 6525.741609] Modules linked in: nls_utf8 cifs libdes libarc4 dns_resolver fscache binfmt_misc nls_ascii nls_cp437 vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul efi_pstore sha2_ce sha256_arm64 sha1_ce evdev efivars efivarfs ip_tables x_tables autofs4 btrfs blake2b_generic xor xor_neon zstd_compress raid6_pq libcrc32c crc32c_generic ahci xhci_pci libahci xhci_hcd igb libata i2c_algo_bit nvme realtek usbcore nvme_core scsi_mod t10_pi netsec mdio_devres of_mdio gpio_keys fixed_phy libphy gpio_mb86s7x
+[ 6525.787760] CPU: 3 PID: 7881 Comm: test_verifier Tainted: G W 5.9.0-rc1+ #47
+[ 6525.796111] Hardware name: Socionext SynQuacer E-series DeveloperBox, BIOS build #1 Jun 6 2020
+[ 6525.804812] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--)
+[ 6525.810390] pc : bpf_prog_c3d01833289b6311_F+0xc8/0x9f4
+[ 6525.815613] lr : bpf_prog_d53bb52e3f4483f9_F+0x38/0xc8c
+[ 6525.820832] sp : ffff8000130cbb80
+[ 6525.824141] x29: ffff8000130cbbb0 x28: 0000000000000000
+[ 6525.829451] x27: 000005ef6fcbf39b x26: 0000000000000000
+[ 6525.834759] x25: ffff8000130cbb80 x24: ffff800011dc7038
+[ 6525.840067] x23: ffff8000130cbd00 x22: ffff0008f624d080
+[ 6525.845375] x21: 0000000000000001 x20: ffff800011dc7000
+[ 6525.850682] x19: 0000000000000000 x18: 0000000000000000
+[ 6525.855990] x17: 0000000000000000 x16: 0000000000000000
+[ 6525.861298] x15: 0000000000000000 x14: 0000000000000000
+[ 6525.866606] x13: 0000000000000000 x12: 0000000000000000
+[ 6525.871913] x11: 0000000000000001 x10: ffff8000000a660c
+[ 6525.877220] x9 : ffff800010951810 x8 : ffff8000130cbc38
+[ 6525.882528] x7 : 0000000000000000 x6 : 0000009864cfa881
+[ 6525.887836] x5 : 00ffffffffffffff x4 : 002880ba1a0b3e9f
+[ 6525.893144] x3 : 0000000000000018 x2 : ffff8000000a4374
+[ 6525.898452] x1 : 000000000000000a x0 : 0000000000000009
+[ 6525.903760] Call trace:
+[ 6525.906202] bpf_prog_c3d01833289b6311_F+0xc8/0x9f4
+[ 6525.911076] bpf_prog_d53bb52e3f4483f9_F+0x38/0xc8c
+[ 6525.915957] bpf_dispatcher_xdp_func+0x14/0x20
+[ 6525.920398] bpf_test_run+0x70/0x1b0
+[ 6525.923969] bpf_prog_test_run_xdp+0xec/0x190
+[ 6525.928326] __do_sys_bpf+0xc88/0x1b28
+[ 6525.932072] __arm64_sys_bpf+0x24/0x30
+[ 6525.935820] el0_svc_common.constprop.0+0x70/0x168
+[ 6525.940607] do_el0_svc+0x28/0x88
+[ 6525.943920] el0_sync_handler+0x88/0x190
+[ 6525.947838] el0_sync+0x140/0x180
+[ 6525.951154] Code: d4202000 d4202000 d4202000 d4202000 (d4202000)
+[ 6525.957249] ---[ end trace cecc3f93b14927e2 ]---
+
+The reason is the offset[] creation and later usage, while building
+the eBPF body. The code currently omits the first instruction, since
+build_insn() will increase our ctx->idx before saving it.
+That was fine up until bounded eBPF loops were introduced. After that
+introduction, offset[0] must be the offset of the end of prologue which
+is the start of the 1st insn while, offset[n] holds the
+offset of the end of n-th insn.
+
+When "taken loop with back jump to 1st insn" test runs, it will
+eventually call bpf2a64_offset(-1, 2, ctx). Since negative indexing is
+permitted, the current outcome depends on the value stored in
+ctx->offset[-1], which has nothing to do with our array.
+If the value happens to be 0 the tests will work. If not this error
+triggers.
+
+commit 7c2e988f400e ("bpf: fix x64 JIT code generation for jmp to 1st insn")
+fixed an indentical bug on x86 when eBPF bounded loops were introduced.
+
+So let's fix it by creating the ctx->offset[] differently. Track the
+beginning of instruction and account for the extra instruction while
+calculating the arm instruction offsets.
+
+Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
+Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
+Reported-by: Jiri Olsa <jolsa@kernel.org>
+Co-developed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
+Co-developed-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
+Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
+Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
+Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
+Acked-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20200917084925.177348-1-ilias.apalodimas@linaro.org
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/net/bpf_jit_comp.c | 43 +++++++++++++++++++++++++----------
+ 1 file changed, 31 insertions(+), 12 deletions(-)
+
+diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
+index cdc79de0c794a..945e5f690edec 100644
+--- a/arch/arm64/net/bpf_jit_comp.c
++++ b/arch/arm64/net/bpf_jit_comp.c
+@@ -141,14 +141,17 @@ static inline void emit_addr_mov_i64(const int reg, const u64 val,
+ }
+ }
+
+-static inline int bpf2a64_offset(int bpf_to, int bpf_from,
++static inline int bpf2a64_offset(int bpf_insn, int off,
+ const struct jit_ctx *ctx)
+ {
+- int to = ctx->offset[bpf_to];
+- /* -1 to account for the Branch instruction */
+- int from = ctx->offset[bpf_from] - 1;
+-
+- return to - from;
++ /* BPF JMP offset is relative to the next instruction */
++ bpf_insn++;
++ /*
++ * Whereas arm64 branch instructions encode the offset
++ * from the branch itself, so we must subtract 1 from the
++ * instruction offset.
++ */
++ return ctx->offset[bpf_insn + off] - (ctx->offset[bpf_insn] - 1);
+ }
+
+ static void jit_fill_hole(void *area, unsigned int size)
+@@ -532,7 +535,7 @@ emit_bswap_uxt:
+
+ /* JUMP off */
+ case BPF_JMP | BPF_JA:
+- jmp_offset = bpf2a64_offset(i + off, i, ctx);
++ jmp_offset = bpf2a64_offset(i, off, ctx);
+ check_imm26(jmp_offset);
+ emit(A64_B(jmp_offset), ctx);
+ break;
+@@ -559,7 +562,7 @@ emit_bswap_uxt:
+ case BPF_JMP32 | BPF_JSLE | BPF_X:
+ emit(A64_CMP(is64, dst, src), ctx);
+ emit_cond_jmp:
+- jmp_offset = bpf2a64_offset(i + off, i, ctx);
++ jmp_offset = bpf2a64_offset(i, off, ctx);
+ check_imm19(jmp_offset);
+ switch (BPF_OP(code)) {
+ case BPF_JEQ:
+@@ -780,10 +783,21 @@ static int build_body(struct jit_ctx *ctx, bool extra_pass)
+ const struct bpf_prog *prog = ctx->prog;
+ int i;
+
++ /*
++ * - offset[0] offset of the end of prologue,
++ * start of the 1st instruction.
++ * - offset[1] - offset of the end of 1st instruction,
++ * start of the 2nd instruction
++ * [....]
++ * - offset[3] - offset of the end of 3rd instruction,
++ * start of 4th instruction
++ */
+ for (i = 0; i < prog->len; i++) {
+ const struct bpf_insn *insn = &prog->insnsi[i];
+ int ret;
+
++ if (ctx->image == NULL)
++ ctx->offset[i] = ctx->idx;
+ ret = build_insn(insn, ctx, extra_pass);
+ if (ret > 0) {
+ i++;
+@@ -791,11 +805,16 @@ static int build_body(struct jit_ctx *ctx, bool extra_pass)
+ ctx->offset[i] = ctx->idx;
+ continue;
+ }
+- if (ctx->image == NULL)
+- ctx->offset[i] = ctx->idx;
+ if (ret)
+ return ret;
+ }
++ /*
++ * offset is allocated with prog->len + 1 so fill in
++ * the last element with the offset after the last
++ * instruction (end of program)
++ */
++ if (ctx->image == NULL)
++ ctx->offset[i] = ctx->idx;
+
+ return 0;
+ }
+@@ -871,7 +890,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
+ memset(&ctx, 0, sizeof(ctx));
+ ctx.prog = prog;
+
+- ctx.offset = kcalloc(prog->len, sizeof(int), GFP_KERNEL);
++ ctx.offset = kcalloc(prog->len + 1, sizeof(int), GFP_KERNEL);
+ if (ctx.offset == NULL) {
+ prog = orig_prog;
+ goto out_off;
+@@ -951,7 +970,7 @@ skip_init_ctx:
+ prog->jited_len = image_size;
+
+ if (!prog->is_func || extra_pass) {
+- bpf_prog_fill_jited_linfo(prog, ctx.offset);
++ bpf_prog_fill_jited_linfo(prog, ctx.offset + 1);
+ out_off:
+ kfree(ctx.offset);
+ kfree(jit_data);
+--
+2.25.1
+
--- /dev/null
+From 900a6941e663b6ecca55f0704828ccdec004c15e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Aug 2020 17:14:38 +0200
+Subject: ASoC: meson: axg-toddr: fix channel order on g12 platforms
+
+From: Jerome Brunet <jbrunet@baylibre.com>
+
+[ Upstream commit 9c4b205a20f483d8a5d1208cfec33e339347d4bd ]
+
+On g12 and following platforms, The first channel of record with more than
+2 channels ends being placed randomly on an even channel of the output.
+
+On these SoCs, a bit was added to force the first channel to be placed at
+the beginning of the output. Apparently the behavior if the bit is not set
+is not easily predictable. According to the documentation, this bit is not
+present on the axg series.
+
+Set the bit on g12 and fix the problem.
+
+Fixes: a3c23a8ad4dc ("ASoC: meson: axg-toddr: add g12a support")
+Reported-by: Nicolas Belin <nbelin@baylibre.com>
+Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
+Link: https://lore.kernel.org/r/20200828151438.350974-1-jbrunet@baylibre.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/meson/axg-toddr.c | 24 +++++++++++++++++++++++-
+ 1 file changed, 23 insertions(+), 1 deletion(-)
+
+diff --git a/sound/soc/meson/axg-toddr.c b/sound/soc/meson/axg-toddr.c
+index ecf41c7549a65..32b9fd59353a4 100644
+--- a/sound/soc/meson/axg-toddr.c
++++ b/sound/soc/meson/axg-toddr.c
+@@ -18,6 +18,7 @@
+ #define CTRL0_TODDR_SEL_RESAMPLE BIT(30)
+ #define CTRL0_TODDR_EXT_SIGNED BIT(29)
+ #define CTRL0_TODDR_PP_MODE BIT(28)
++#define CTRL0_TODDR_SYNC_CH BIT(27)
+ #define CTRL0_TODDR_TYPE_MASK GENMASK(15, 13)
+ #define CTRL0_TODDR_TYPE(x) ((x) << 13)
+ #define CTRL0_TODDR_MSB_POS_MASK GENMASK(12, 8)
+@@ -184,10 +185,31 @@ static const struct axg_fifo_match_data axg_toddr_match_data = {
+ .dai_drv = &axg_toddr_dai_drv
+ };
+
++static int g12a_toddr_dai_startup(struct snd_pcm_substream *substream,
++ struct snd_soc_dai *dai)
++{
++ struct axg_fifo *fifo = snd_soc_dai_get_drvdata(dai);
++ int ret;
++
++ ret = axg_toddr_dai_startup(substream, dai);
++ if (ret)
++ return ret;
++
++ /*
++ * Make sure the first channel ends up in the at beginning of the output
++ * As weird as it looks, without this the first channel may be misplaced
++ * in memory, with a random shift of 2 channels.
++ */
++ regmap_update_bits(fifo->map, FIFO_CTRL0, CTRL0_TODDR_SYNC_CH,
++ CTRL0_TODDR_SYNC_CH);
++
++ return 0;
++}
++
+ static const struct snd_soc_dai_ops g12a_toddr_ops = {
+ .prepare = g12a_toddr_dai_prepare,
+ .hw_params = axg_toddr_dai_hw_params,
+- .startup = axg_toddr_dai_startup,
++ .startup = g12a_toddr_dai_startup,
+ .shutdown = axg_toddr_dai_shutdown,
+ };
+
+--
+2.25.1
+
--- /dev/null
+From 40a26bb792d0008d9e115667fd8f99eaf6acbd6c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Aug 2020 12:28:27 +0800
+Subject: ASoC: qcom: common: Fix refcount imbalance on error
+
+From: Dinghao Liu <dinghao.liu@zju.edu.cn>
+
+[ Upstream commit c1e6414cdc371f9ed82cefebba7538499a3059f9 ]
+
+for_each_child_of_node returns a node pointer np with
+refcount incremented. So when devm_kzalloc fails, a
+pairing refcount decrement is needed to keep np's
+refcount balanced.
+
+Fixes: 16395ceee11f8 ("ASoC: qcom: common: Fix NULL pointer in of parser")
+Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
+Link: https://lore.kernel.org/r/20200820042828.10308-1-dinghao.liu@zju.edu.cn
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/qcom/common.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/sound/soc/qcom/common.c b/sound/soc/qcom/common.c
+index 8ada4ecba8472..10322690c0eaa 100644
+--- a/sound/soc/qcom/common.c
++++ b/sound/soc/qcom/common.c
+@@ -45,8 +45,10 @@ int qcom_snd_parse_of(struct snd_soc_card *card)
+
+ for_each_child_of_node(dev->of_node, np) {
+ dlc = devm_kzalloc(dev, 2 * sizeof(*dlc), GFP_KERNEL);
+- if (!dlc)
+- return -ENOMEM;
++ if (!dlc) {
++ ret = -ENOMEM;
++ goto err;
++ }
+
+ link->cpus = &dlc[0];
+ link->platforms = &dlc[1];
+--
+2.25.1
+
--- /dev/null
+From ad87e357126f782fae15ad501112f4b7b5091c92 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Aug 2020 17:45:11 +0200
+Subject: ASoC: qcom: Set card->owner to avoid warnings
+
+From: Stephan Gerhold <stephan@gerhold.net>
+
+[ Upstream commit 3c27ea23ffb43262da6c64964163895951aaed4e ]
+
+On Linux 5.9-rc1 I get the following warning with apq8016-sbc:
+
+WARNING: CPU: 2 PID: 69 at sound/core/init.c:207 snd_card_new+0x36c/0x3b0 [snd]
+CPU: 2 PID: 69 Comm: kworker/2:1 Not tainted 5.9.0-rc1 #1
+Workqueue: events deferred_probe_work_func
+pc : snd_card_new+0x36c/0x3b0 [snd]
+lr : snd_card_new+0xf4/0x3b0 [snd]
+Call trace:
+ snd_card_new+0x36c/0x3b0 [snd]
+ snd_soc_bind_card+0x340/0x9a0 [snd_soc_core]
+ snd_soc_register_card+0xf4/0x110 [snd_soc_core]
+ devm_snd_soc_register_card+0x44/0xa0 [snd_soc_core]
+ apq8016_sbc_platform_probe+0x11c/0x140 [snd_soc_apq8016_sbc]
+
+This warning was introduced in
+commit 81033c6b584b ("ALSA: core: Warn on empty module").
+It looks like we are supposed to set card->owner to THIS_MODULE.
+
+Fix this for all the qcom ASoC drivers.
+
+Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+Fixes: 79119c798649 ("ASoC: qcom: Add Storm machine driver")
+Fixes: bdb052e81f62 ("ASoC: qcom: add apq8016 sound card support")
+Fixes: a6f933f63f2f ("ASoC: qcom: apq8096: Add db820c machine driver")
+Fixes: 6b1687bf76ef ("ASoC: qcom: add sdm845 sound card support")
+Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
+Link: https://lore.kernel.org/r/20200820154511.203072-1-stephan@gerhold.net
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/qcom/apq8016_sbc.c | 1 +
+ sound/soc/qcom/apq8096.c | 1 +
+ sound/soc/qcom/sdm845.c | 1 +
+ sound/soc/qcom/storm.c | 1 +
+ 4 files changed, 4 insertions(+)
+
+diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c
+index ac75838bbfabe..15a88020dfab2 100644
+--- a/sound/soc/qcom/apq8016_sbc.c
++++ b/sound/soc/qcom/apq8016_sbc.c
+@@ -235,6 +235,7 @@ static int apq8016_sbc_platform_probe(struct platform_device *pdev)
+ return -ENOMEM;
+
+ card->dev = dev;
++ card->owner = THIS_MODULE;
+ card->dapm_widgets = apq8016_sbc_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(apq8016_sbc_dapm_widgets);
+ data = apq8016_sbc_parse_of(card);
+diff --git a/sound/soc/qcom/apq8096.c b/sound/soc/qcom/apq8096.c
+index 94363fd6846ab..c10c5f2ec29b7 100644
+--- a/sound/soc/qcom/apq8096.c
++++ b/sound/soc/qcom/apq8096.c
+@@ -114,6 +114,7 @@ static int apq8096_platform_probe(struct platform_device *pdev)
+ return -ENOMEM;
+
+ card->dev = dev;
++ card->owner = THIS_MODULE;
+ dev_set_drvdata(dev, card);
+ ret = qcom_snd_parse_of(card);
+ if (ret) {
+diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
+index 28f3cef696e61..7e6c41e63d8e1 100644
+--- a/sound/soc/qcom/sdm845.c
++++ b/sound/soc/qcom/sdm845.c
+@@ -410,6 +410,7 @@ static int sdm845_snd_platform_probe(struct platform_device *pdev)
+ card->dapm_widgets = sdm845_snd_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sdm845_snd_widgets);
+ card->dev = dev;
++ card->owner = THIS_MODULE;
+ dev_set_drvdata(dev, card);
+ ret = qcom_snd_parse_of(card);
+ if (ret) {
+diff --git a/sound/soc/qcom/storm.c b/sound/soc/qcom/storm.c
+index e6666e597265a..236759179100a 100644
+--- a/sound/soc/qcom/storm.c
++++ b/sound/soc/qcom/storm.c
+@@ -96,6 +96,7 @@ static int storm_platform_probe(struct platform_device *pdev)
+ return -ENOMEM;
+
+ card->dev = &pdev->dev;
++ card->owner = THIS_MODULE;
+
+ ret = snd_soc_of_parse_card_name(card, "qcom,model");
+ if (ret) {
+--
+2.25.1
+
--- /dev/null
+From 842cb5d2b47c08b2097a09930d413e70751fc05f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Sep 2020 13:46:37 -0700
+Subject: block: only call sched requeue_request() for scheduled requests
+
+From: Omar Sandoval <osandov@fb.com>
+
+[ Upstream commit e8a8a185051a460e3eb0617dca33f996f4e31516 ]
+
+Yang Yang reported the following crash caused by requeueing a flush
+request in Kyber:
+
+ [ 2.517297] Unable to handle kernel paging request at virtual address ffffffd8071c0b00
+ ...
+ [ 2.517468] pc : clear_bit+0x18/0x2c
+ [ 2.517502] lr : sbitmap_queue_clear+0x40/0x228
+ [ 2.517503] sp : ffffff800832bc60 pstate : 00c00145
+ ...
+ [ 2.517599] Process ksoftirqd/5 (pid: 51, stack limit = 0xffffff8008328000)
+ [ 2.517602] Call trace:
+ [ 2.517606] clear_bit+0x18/0x2c
+ [ 2.517619] kyber_finish_request+0x74/0x80
+ [ 2.517627] blk_mq_requeue_request+0x3c/0xc0
+ [ 2.517637] __scsi_queue_insert+0x11c/0x148
+ [ 2.517640] scsi_softirq_done+0x114/0x130
+ [ 2.517643] blk_done_softirq+0x7c/0xb0
+ [ 2.517651] __do_softirq+0x208/0x3bc
+ [ 2.517657] run_ksoftirqd+0x34/0x60
+ [ 2.517663] smpboot_thread_fn+0x1c4/0x2c0
+ [ 2.517667] kthread+0x110/0x120
+ [ 2.517669] ret_from_fork+0x10/0x18
+
+This happens because Kyber doesn't track flush requests, so
+kyber_finish_request() reads a garbage domain token. Only call the
+scheduler's requeue_request() hook if RQF_ELVPRIV is set (like we do for
+the finish_request() hook in blk_mq_free_request()). Now that we're
+handling it in blk-mq, also remove the check from BFQ.
+
+Reported-by: Yang Yang <yang.yang@vivo.com>
+Signed-off-by: Omar Sandoval <osandov@fb.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/bfq-iosched.c | 12 ------------
+ block/blk-mq-sched.h | 2 +-
+ 2 files changed, 1 insertion(+), 13 deletions(-)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index 88497bff1135f..ba32adaeefdd0 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -5890,18 +5890,6 @@ static void bfq_finish_requeue_request(struct request *rq)
+ struct bfq_queue *bfqq = RQ_BFQQ(rq);
+ struct bfq_data *bfqd;
+
+- /*
+- * Requeue and finish hooks are invoked in blk-mq without
+- * checking whether the involved request is actually still
+- * referenced in the scheduler. To handle this fact, the
+- * following two checks make this function exit in case of
+- * spurious invocations, for which there is nothing to do.
+- *
+- * First, check whether rq has nothing to do with an elevator.
+- */
+- if (unlikely(!(rq->rq_flags & RQF_ELVPRIV)))
+- return;
+-
+ /*
+ * rq either is not associated with any icq, or is an already
+ * requeued request that has not (yet) been re-inserted into
+diff --git a/block/blk-mq-sched.h b/block/blk-mq-sched.h
+index 126021fc3a11f..e81ca1bf6e10b 100644
+--- a/block/blk-mq-sched.h
++++ b/block/blk-mq-sched.h
+@@ -66,7 +66,7 @@ static inline void blk_mq_sched_requeue_request(struct request *rq)
+ struct request_queue *q = rq->q;
+ struct elevator_queue *e = q->elevator;
+
+- if (e && e->type->ops.requeue_request)
++ if ((rq->rq_flags & RQF_ELVPRIV) && e && e->type->ops.requeue_request)
+ e->type->ops.requeue_request(rq);
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 56289f313e4fff2b7a130763dd7faac749e635e6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Sep 2020 10:02:39 +1000
+Subject: cifs: fix DFS mount with cifsacl/modefromsid
+
+From: Ronnie Sahlberg <lsahlber@redhat.com>
+
+[ Upstream commit 01ec372cef1e5afa4ab843bbaf88a6fcb64dc14c ]
+
+RHBZ: 1871246
+
+If during cifs_lookup()/get_inode_info() we encounter a DFS link
+and we use the cifsacl or modefromsid mount options we must suppress
+any -EREMOTE errors that triggers or else we will not be able to follow
+the DFS link and automount the target.
+
+This fixes an issue with modefromsid/cifsacl where these mountoptions
+would break DFS and we would no longer be able to access the share.
+
+Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/cifs/inode.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
+index eb2e3db3916f0..17df90b5f57a2 100644
+--- a/fs/cifs/inode.c
++++ b/fs/cifs/inode.c
+@@ -898,6 +898,8 @@ cifs_get_inode_info(struct inode **inode, const char *full_path,
+ if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MODE_FROM_SID) {
+ rc = cifs_acl_to_fattr(cifs_sb, &fattr, *inode, true,
+ full_path, fid);
++ if (rc == -EREMOTE)
++ rc = 0;
+ if (rc) {
+ cifs_dbg(FYI, "%s: Get mode from SID failed. rc=%d\n",
+ __func__, rc);
+@@ -906,6 +908,8 @@ cifs_get_inode_info(struct inode **inode, const char *full_path,
+ } else if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_CIFS_ACL) {
+ rc = cifs_acl_to_fattr(cifs_sb, &fattr, *inode, false,
+ full_path, fid);
++ if (rc == -EREMOTE)
++ rc = 0;
+ if (rc) {
+ cifs_dbg(FYI, "%s: Getting ACL failed with error: %d\n",
+ __func__, rc);
+--
+2.25.1
+
--- /dev/null
+From 4921fa5a30d4cc9efc9dd7e87baac378c08a0063 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 9 Aug 2020 16:49:59 +0200
+Subject: clk: davinci: Use the correct size when allocating memory
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit 3dabfa2bda48dab717986609762ce2a49335eb99 ]
+
+'sizeof(*pllen)' should be used in place of 'sizeof(*pllout)' to avoid a
+small over-allocation.
+
+Fixes: 2d1726915159 ("clk: davinci: New driver for davinci PLL clocks")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Link: https://lore.kernel.org/r/20200809144959.747986-1-christophe.jaillet@wanadoo.fr
+Reviewed-by: David Lechner <david@lechnology.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clk/davinci/pll.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/clk/davinci/pll.c b/drivers/clk/davinci/pll.c
+index 1ac11b6a47a37..2ec48d030fda7 100644
+--- a/drivers/clk/davinci/pll.c
++++ b/drivers/clk/davinci/pll.c
+@@ -491,7 +491,7 @@ struct clk *davinci_pll_clk_register(struct device *dev,
+ parent_name = postdiv_name;
+ }
+
+- pllen = kzalloc(sizeof(*pllout), GFP_KERNEL);
++ pllen = kzalloc(sizeof(*pllen), GFP_KERNEL);
+ if (!pllen) {
+ ret = -ENOMEM;
+ goto err_unregister_postdiv;
+--
+2.25.1
+
--- /dev/null
+From 59be8392987f21efa10520392a9f62abfc9f55d5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 9 Aug 2020 21:40:20 -0700
+Subject: clk: rockchip: Fix initialization of mux_pll_src_4plls_p
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+[ Upstream commit e9c006bc782c488f485ffe50de20b44e1e3daa18 ]
+
+A new warning in Clang points out that the initialization of
+mux_pll_src_4plls_p appears incorrect:
+
+../drivers/clk/rockchip/clk-rk3228.c:140:58: warning: suspicious
+concatenation of string literals in an array initialization; did you
+mean to separate the elements with a comma? [-Wstring-concatenation]
+PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy" "usb480m" };
+ ^
+ ,
+../drivers/clk/rockchip/clk-rk3228.c:140:48: note: place parentheses
+around the string literal to silence warning
+PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy" "usb480m" };
+ ^
+1 warning generated.
+
+Given the name of the variable and the same variable name in rv1108, it
+seems that this should have been four distinct elements. Fix it up by
+adding the comma as suggested.
+
+Fixes: 307a2e9ac524 ("clk: rockchip: add clock controller for rk3228")
+Link: https://github.com/ClangBuiltLinux/linux/issues/1123
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Link: https://lore.kernel.org/r/20200810044020.2063350-1-natechancellor@gmail.com
+Reviewed-by: Heiko Stübner <heiko@sntech.de>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clk/rockchip/clk-rk3228.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/clk/rockchip/clk-rk3228.c b/drivers/clk/rockchip/clk-rk3228.c
+index d7243c09cc843..47d6482dda9df 100644
+--- a/drivers/clk/rockchip/clk-rk3228.c
++++ b/drivers/clk/rockchip/clk-rk3228.c
+@@ -137,7 +137,7 @@ PNAME(mux_usb480m_p) = { "usb480m_phy", "xin24m" };
+ PNAME(mux_hdmiphy_p) = { "hdmiphy_phy", "xin24m" };
+ PNAME(mux_aclk_cpu_src_p) = { "cpll_aclk_cpu", "gpll_aclk_cpu", "hdmiphy_aclk_cpu" };
+
+-PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy" "usb480m" };
++PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy", "usb480m" };
+ PNAME(mux_pll_src_3plls_p) = { "cpll", "gpll", "hdmiphy" };
+ PNAME(mux_pll_src_2plls_p) = { "cpll", "gpll" };
+ PNAME(mux_sclk_hdmi_cec_p) = { "cpll", "gpll", "xin24m" };
+--
+2.25.1
+
--- /dev/null
+From a1cc173d52bdc1894caa0270be8bf3baf99aeb39 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 13 Sep 2020 12:47:29 -0700
+Subject: Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload
+
+From: Michael Kelley <mikelley@microsoft.com>
+
+[ Upstream commit 911e1987efc8f3e6445955fbae7f54b428b92bd3 ]
+
+vmbus_wait_for_unload() looks for a CHANNELMSG_UNLOAD_RESPONSE message
+coming from Hyper-V. But if the message isn't found for some reason,
+the panic path gets hung forever. Add a timeout of 10 seconds to prevent
+this.
+
+Fixes: 415719160de3 ("Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()")
+Signed-off-by: Michael Kelley <mikelley@microsoft.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Link: https://lore.kernel.org/r/1600026449-23651-1-git-send-email-mikelley@microsoft.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hv/channel_mgmt.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
+index 501c43c5851dc..452307c79e4b9 100644
+--- a/drivers/hv/channel_mgmt.c
++++ b/drivers/hv/channel_mgmt.c
+@@ -769,7 +769,7 @@ static void vmbus_wait_for_unload(void)
+ void *page_addr;
+ struct hv_message *msg;
+ struct vmbus_channel_message_header *hdr;
+- u32 message_type;
++ u32 message_type, i;
+
+ /*
+ * CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was
+@@ -779,8 +779,11 @@ static void vmbus_wait_for_unload(void)
+ * functional and vmbus_unload_response() will complete
+ * vmbus_connection.unload_event. If not, the last thing we can do is
+ * read message pages for all CPUs directly.
++ *
++ * Wait no more than 10 seconds so that the panic path can't get
++ * hung forever in case the response message isn't seen.
+ */
+- while (1) {
++ for (i = 0; i < 1000; i++) {
+ if (completion_done(&vmbus_connection.unload_event))
+ break;
+
+--
+2.25.1
+
--- /dev/null
+From a89e4d83ac334edbf2d6eb338cbd5b0266f7698e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Sep 2020 19:55:55 -0700
+Subject: Drivers: hv: vmbus: hibernation: do not hang forever in
+ vmbus_bus_resume()
+
+From: Dexuan Cui <decui@microsoft.com>
+
+[ Upstream commit 19873eec7e13fda140a0ebc75d6664e57c00bfb1 ]
+
+After we Stop and later Start a VM that uses Accelerated Networking (NIC
+SR-IOV), currently the VF vmbus device's Instance GUID can change, so after
+vmbus_bus_resume() -> vmbus_request_offers(), vmbus_onoffer() can not find
+the original vmbus channel of the VF, and hence we can't complete()
+vmbus_connection.ready_for_resume_event in check_ready_for_resume_event(),
+and the VM hangs in vmbus_bus_resume() forever.
+
+Fix the issue by adding a timeout, so the resuming can still succeed, and
+the saved state is not lost, and according to my test, the user can disable
+Accelerated Networking and then will be able to SSH into the VM for
+further recovery. Also prevent the VM in question from suspending again.
+
+The host will be fixed so in future the Instance GUID will stay the same
+across hibernation.
+
+Fixes: d8bd2d442bb2 ("Drivers: hv: vmbus: Resume after fixing up old primary channels")
+Signed-off-by: Dexuan Cui <decui@microsoft.com>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/20200905025555.45614-1-decui@microsoft.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hv/vmbus_drv.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
+index 24c38e44ed3bc..2d2568dac2a66 100644
+--- a/drivers/hv/vmbus_drv.c
++++ b/drivers/hv/vmbus_drv.c
+@@ -2231,7 +2231,10 @@ static int vmbus_bus_suspend(struct device *dev)
+ if (atomic_read(&vmbus_connection.nr_chan_close_on_suspend) > 0)
+ wait_for_completion(&vmbus_connection.ready_for_suspend_event);
+
+- WARN_ON(atomic_read(&vmbus_connection.nr_chan_fixup_on_resume) != 0);
++ if (atomic_read(&vmbus_connection.nr_chan_fixup_on_resume) != 0) {
++ pr_err("Can not suspend due to a previous failed resuming\n");
++ return -EBUSY;
++ }
+
+ mutex_lock(&vmbus_connection.channel_mutex);
+
+@@ -2305,7 +2308,9 @@ static int vmbus_bus_resume(struct device *dev)
+
+ vmbus_request_offers();
+
+- wait_for_completion(&vmbus_connection.ready_for_resume_event);
++ if (wait_for_completion_timeout(
++ &vmbus_connection.ready_for_resume_event, 10 * HZ) == 0)
++ pr_err("Some vmbus device is missing after suspending?\n");
+
+ /* Reset the event for the next suspend. */
+ reinit_completion(&vmbus_connection.ready_for_suspend_event);
+--
+2.25.1
+
--- /dev/null
+From 1eeb2d5c0ebeaeebafe09ad132f32726cb6f1472 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Sep 2020 16:49:42 +0800
+Subject: drm/mediatek: Add exception handing in mtk_drm_probe() if component
+ init fail
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+[ Upstream commit 64c194c00789889b0f9454f583712f079ba414ee ]
+
+mtk_ddp_comp_init() is called in a loop in mtk_drm_probe(), if it
+fail, previous successive init component is not proccessed.
+
+Thus uninitialize valid component and put their device if component
+init failed.
+
+Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+index 352b81a7a6702..f98bb2e263723 100644
+--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
++++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+@@ -594,8 +594,13 @@ err_pm:
+ pm_runtime_disable(dev);
+ err_node:
+ of_node_put(private->mutex_node);
+- for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
++ for (i = 0; i < DDP_COMPONENT_ID_MAX; i++) {
+ of_node_put(private->comp_node[i]);
++ if (private->ddp_comp[i]) {
++ put_device(private->ddp_comp[i]->larb_dev);
++ private->ddp_comp[i] = NULL;
++ }
++ }
+ return ret;
+ }
+
+--
+2.25.1
+
--- /dev/null
+From e3300876540998884e5758efe1fd4782ae653864 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Sep 2020 19:21:51 +0800
+Subject: drm/mediatek: Add missing put_device() call in
+ mtk_hdmi_dt_parse_pdata()
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+[ Upstream commit 0680a622318b8d657323b94082f4b9a44038dfee ]
+
+if of_find_device_by_node() succeed, mtk_drm_kms_init() doesn't have
+a corresponding put_device(). Thus add jump target to fix the exception
+handling for this function implementation.
+
+Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++++++++++++++++++--------
+ 1 file changed, 18 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
+index ce91b61364eb6..6b22fd63c3f55 100644
+--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
++++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
+@@ -1482,25 +1482,30 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
+ dev_err(dev,
+ "Failed to get system configuration registers: %d\n",
+ ret);
+- return ret;
++ goto put_device;
+ }
+ hdmi->sys_regmap = regmap;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ hdmi->regs = devm_ioremap_resource(dev, mem);
+- if (IS_ERR(hdmi->regs))
+- return PTR_ERR(hdmi->regs);
++ if (IS_ERR(hdmi->regs)) {
++ ret = PTR_ERR(hdmi->regs);
++ goto put_device;
++ }
+
+ remote = of_graph_get_remote_node(np, 1, 0);
+- if (!remote)
+- return -EINVAL;
++ if (!remote) {
++ ret = -EINVAL;
++ goto put_device;
++ }
+
+ if (!of_device_is_compatible(remote, "hdmi-connector")) {
+ hdmi->next_bridge = of_drm_find_bridge(remote);
+ if (!hdmi->next_bridge) {
+ dev_err(dev, "Waiting for external bridge\n");
+ of_node_put(remote);
+- return -EPROBE_DEFER;
++ ret = -EPROBE_DEFER;
++ goto put_device;
+ }
+ }
+
+@@ -1509,7 +1514,8 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
+ dev_err(dev, "Failed to find ddc-i2c-bus node in %pOF\n",
+ remote);
+ of_node_put(remote);
+- return -EINVAL;
++ ret = -EINVAL;
++ goto put_device;
+ }
+ of_node_put(remote);
+
+@@ -1517,10 +1523,14 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
+ of_node_put(i2c_np);
+ if (!hdmi->ddc_adpt) {
+ dev_err(dev, "Failed to get ddc i2c adapter by node\n");
+- return -EINVAL;
++ ret = -EINVAL;
++ goto put_device;
+ }
+
+ return 0;
++put_device:
++ put_device(hdmi->cec_dev);
++ return ret;
+ }
+
+ /*
+--
+2.25.1
+
--- /dev/null
+From 2c219da2e7bc982196688a79d3068c8921cbeca7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Aug 2020 15:40:14 +0530
+Subject: f2fs: fix indefinite loop scanning for free nid
+
+From: Sahitya Tummala <stummala@codeaurora.org>
+
+[ Upstream commit e2cab031ba7b5003cd12185b3ef38f1a75e3dae8 ]
+
+If the sbi->ckpt->next_free_nid is not NAT block aligned and if there
+are free nids in that NAT block between the start of the block and
+next_free_nid, then those free nids will not be scanned in scan_nat_page().
+This results into mismatch between nm_i->available_nids and the sum of
+nm_i->free_nid_count of all NAT blocks scanned. And nm_i->available_nids
+will always be greater than the sum of free nids in all the blocks.
+Under this condition, if we use all the currently scanned free nids,
+then it will loop forever in f2fs_alloc_nid() as nm_i->available_nids
+is still not zero but nm_i->free_nid_count of that partially scanned
+NAT block is zero.
+
+Fix this to align the nm_i->next_scan_nid to the first nid of the
+corresponding NAT block.
+
+Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/node.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
+index daeac4268c1ab..8a67b933ccd42 100644
+--- a/fs/f2fs/node.c
++++ b/fs/f2fs/node.c
+@@ -2315,6 +2315,9 @@ static int __f2fs_build_free_nids(struct f2fs_sb_info *sbi,
+ if (unlikely(nid >= nm_i->max_nid))
+ nid = 0;
+
++ if (unlikely(nid % NAT_ENTRY_PER_BLOCK))
++ nid = NAT_BLOCK_OFFSET(nid) * NAT_ENTRY_PER_BLOCK;
++
+ /* Enough entries */
+ if (nm_i->nid_cnt[FREE_NID] >= NAT_ENTRY_PER_BLOCK)
+ return 0;
+--
+2.25.1
+
--- /dev/null
+From 87783c5fc73f48a14502d3160936267db2da6094 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 19 Aug 2020 16:07:31 -0400
+Subject: f2fs: Return EOF on unaligned end of file DIO read
+
+From: Gabriel Krisman Bertazi <krisman@collabora.com>
+
+[ Upstream commit 20d0a107fb35f37578b919f62bd474d6d358d579 ]
+
+Reading past end of file returns EOF for aligned reads but -EINVAL for
+unaligned reads on f2fs. While documentation is not strict about this
+corner case, most filesystem returns EOF on this case, like iomap
+filesystems. This patch consolidates the behavior for f2fs, by making
+it return EOF(0).
+
+it can be verified by a read loop on a file that does a partial read
+before EOF (A file that doesn't end at an aligned address). The
+following code fails on an unaligned file on f2fs, but not on
+btrfs, ext4, and xfs.
+
+ while (done < total) {
+ ssize_t delta = pread(fd, buf + done, total - done, off + done);
+ if (!delta)
+ break;
+ ...
+ }
+
+It is arguable whether filesystems should actually return EOF or
+-EINVAL, but since iomap filesystems support it, and so does the
+original DIO code, it seems reasonable to consolidate on that.
+
+Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/data.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
+index ec9a1f9ce2dd6..68be334afc286 100644
+--- a/fs/f2fs/data.c
++++ b/fs/f2fs/data.c
+@@ -2753,6 +2753,9 @@ static int check_direct_IO(struct inode *inode, struct iov_iter *iter,
+ unsigned long align = offset | iov_iter_alignment(iter);
+ struct block_device *bdev = inode->i_sb->s_bdev;
+
++ if (iov_iter_rw(iter) == READ && offset >= i_size_read(inode))
++ return 1;
++
+ if (align & blocksize_mask) {
+ if (bdev)
+ blkbits = blksize_bits(bdev_logical_block_size(bdev));
+--
+2.25.1
+
--- /dev/null
+From 0007240d631e9fa9408c7588c13951e1a5f0c15a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Sep 2020 07:57:06 +0900
+Subject: fbcon: Fix user font detection test at fbcon_resize().
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+[ Upstream commit ec0972adecb391a8d8650832263a4790f3bfb4df ]
+
+syzbot is reporting OOB read at fbcon_resize() [1], for
+commit 39b3cffb8cf31117 ("fbcon: prevent user font height or width change
+ from causing potential out-of-bounds access") is by error using
+registered_fb[con2fb_map[vc->vc_num]]->fbcon_par->p->userfont (which was
+set to non-zero) instead of fb_display[vc->vc_num].userfont (which remains
+zero for that display).
+
+We could remove tricky userfont flag [2], for we can determine it by
+comparing address of the font data and addresses of built-in font data.
+But since that commit is failing to fix the original OOB read [3], this
+patch keeps the change minimal in case we decide to revert altogether.
+
+[1] https://syzkaller.appspot.com/bug?id=ebcbbb6576958a496500fee9cf7aa83ea00b5920
+[2] https://syzkaller.appspot.com/text?tag=Patch&x=14030853900000
+[3] https://syzkaller.appspot.com/bug?id=6fba8c186d97cf1011ab17660e633b1cc4e080c9
+
+Reported-by: syzbot <syzbot+b38b1ef6edf0c74a8d97@syzkaller.appspotmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Fixes: 39b3cffb8cf31117 ("fbcon: prevent user font height or width change from causing potential out-of-bounds access")
+Cc: George Kennedy <george.kennedy@oracle.com>
+Link: https://lore.kernel.org/r/f6e3e611-8704-1263-d163-f52c906a4f06@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/core/fbcon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
+index 8685d28dfdaaf..dc7f5c4f0607e 100644
+--- a/drivers/video/fbdev/core/fbcon.c
++++ b/drivers/video/fbdev/core/fbcon.c
+@@ -2012,7 +2012,7 @@ static int fbcon_resize(struct vc_data *vc, unsigned int width,
+ struct fb_var_screeninfo var = info->var;
+ int x_diff, y_diff, virt_w, virt_h, virt_fw, virt_fh;
+
+- if (ops->p && ops->p->userfont && FNTSIZE(vc->vc_font.data)) {
++ if (p->userfont && FNTSIZE(vc->vc_font.data)) {
+ int size;
+ int pitch = PITCH(vc->vc_font.width);
+
+--
+2.25.1
+
--- /dev/null
+From 35acd7b1912663399aca2964fd2f723ef9efa850 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Sep 2020 08:32:47 +1200
+Subject: i2c: algo: pca: Reapply i2c bus settings after reset
+
+From: Evan Nimmo <evan.nimmo@alliedtelesis.co.nz>
+
+[ Upstream commit 0a355aeb24081e4538d4d424cd189f16c0bbd983 ]
+
+If something goes wrong (such as the SCL being stuck low) then we need
+to reset the PCA chip. The issue with this is that on reset we lose all
+config settings and the chip ends up in a disabled state which results
+in a lock up/high CPU usage. We need to re-apply any configuration that
+had previously been set and re-enable the chip.
+
+Signed-off-by: Evan Nimmo <evan.nimmo@alliedtelesis.co.nz>
+Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/algos/i2c-algo-pca.c | 35 +++++++++++++++++++++-----------
+ include/linux/i2c-algo-pca.h | 15 ++++++++++++++
+ 2 files changed, 38 insertions(+), 12 deletions(-)
+
+diff --git a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c
+index 8ea850eed18f7..1d3691a049b16 100644
+--- a/drivers/i2c/algos/i2c-algo-pca.c
++++ b/drivers/i2c/algos/i2c-algo-pca.c
+@@ -41,8 +41,22 @@ static void pca_reset(struct i2c_algo_pca_data *adap)
+ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_IPRESET);
+ pca_outw(adap, I2C_PCA_IND, 0xA5);
+ pca_outw(adap, I2C_PCA_IND, 0x5A);
++
++ /*
++ * After a reset we need to re-apply any configuration
++ * (calculated in pca_init) to get the bus in a working state.
++ */
++ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_IMODE);
++ pca_outw(adap, I2C_PCA_IND, adap->bus_settings.mode);
++ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_ISCLL);
++ pca_outw(adap, I2C_PCA_IND, adap->bus_settings.tlow);
++ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_ISCLH);
++ pca_outw(adap, I2C_PCA_IND, adap->bus_settings.thi);
++
++ pca_set_con(adap, I2C_PCA_CON_ENSIO);
+ } else {
+ adap->reset_chip(adap->data);
++ pca_set_con(adap, I2C_PCA_CON_ENSIO | adap->bus_settings.clock_freq);
+ }
+ }
+
+@@ -423,13 +437,14 @@ static int pca_init(struct i2c_adapter *adap)
+ " Use the nominal frequency.\n", adap->name);
+ }
+
+- pca_reset(pca_data);
+-
+ clock = pca_clock(pca_data);
+ printk(KERN_INFO "%s: Clock frequency is %dkHz\n",
+ adap->name, freqs[clock]);
+
+- pca_set_con(pca_data, I2C_PCA_CON_ENSIO | clock);
++ /* Store settings as these will be needed when the PCA chip is reset */
++ pca_data->bus_settings.clock_freq = clock;
++
++ pca_reset(pca_data);
+ } else {
+ int clock;
+ int mode;
+@@ -496,19 +511,15 @@ static int pca_init(struct i2c_adapter *adap)
+ thi = tlow * min_thi / min_tlow;
+ }
+
++ /* Store settings as these will be needed when the PCA chip is reset */
++ pca_data->bus_settings.mode = mode;
++ pca_data->bus_settings.tlow = tlow;
++ pca_data->bus_settings.thi = thi;
++
+ pca_reset(pca_data);
+
+ printk(KERN_INFO
+ "%s: Clock frequency is %dHz\n", adap->name, clock * 100);
+-
+- pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_IMODE);
+- pca_outw(pca_data, I2C_PCA_IND, mode);
+- pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_ISCLL);
+- pca_outw(pca_data, I2C_PCA_IND, tlow);
+- pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_ISCLH);
+- pca_outw(pca_data, I2C_PCA_IND, thi);
+-
+- pca_set_con(pca_data, I2C_PCA_CON_ENSIO);
+ }
+ udelay(500); /* 500 us for oscillator to stabilise */
+
+diff --git a/include/linux/i2c-algo-pca.h b/include/linux/i2c-algo-pca.h
+index d03071732db4a..7c522fdd9ea73 100644
+--- a/include/linux/i2c-algo-pca.h
++++ b/include/linux/i2c-algo-pca.h
+@@ -53,6 +53,20 @@
+ #define I2C_PCA_CON_SI 0x08 /* Serial Interrupt */
+ #define I2C_PCA_CON_CR 0x07 /* Clock Rate (MASK) */
+
++/**
++ * struct pca_i2c_bus_settings - The configured PCA i2c bus settings
++ * @mode: Configured i2c bus mode
++ * @tlow: Configured SCL LOW period
++ * @thi: Configured SCL HIGH period
++ * @clock_freq: The configured clock frequency
++ */
++struct pca_i2c_bus_settings {
++ int mode;
++ int tlow;
++ int thi;
++ int clock_freq;
++};
++
+ struct i2c_algo_pca_data {
+ void *data; /* private low level data */
+ void (*write_byte) (void *data, int reg, int val);
+@@ -64,6 +78,7 @@ struct i2c_algo_pca_data {
+ * For PCA9665, use the frequency you want here. */
+ unsigned int i2c_clock;
+ unsigned int chip;
++ struct pca_i2c_bus_settings bus_settings;
+ };
+
+ int i2c_pca_add_bus(struct i2c_adapter *);
+--
+2.25.1
+
--- /dev/null
+From 8cbcf812bbc6b04a9090519f89c4ee566297492e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Sep 2020 17:01:39 +0200
+Subject: i2c: mxs: use MXS_DMA_CTRL_WAIT4END instead of DMA_CTRL_ACK
+
+From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
+
+[ Upstream commit 6eb158ec0a45dbfd98bc6971c461b7d4d5bf61b3 ]
+
+The driver-specific usage of the DMA_CTRL_ACK flag was replaced with a
+custom flag in commit ceeeb99cd821 ("dmaengine: mxs: rename custom flag"),
+but i2c-mxs was not updated to use the new flag, completely breaking I2C
+transactions using DMA.
+
+Fixes: ceeeb99cd821 ("dmaengine: mxs: rename custom flag")
+Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-mxs.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
+index 89224913f578b..081a1169ecea3 100644
+--- a/drivers/i2c/busses/i2c-mxs.c
++++ b/drivers/i2c/busses/i2c-mxs.c
+@@ -25,6 +25,7 @@
+ #include <linux/of_device.h>
+ #include <linux/dma-mapping.h>
+ #include <linux/dmaengine.h>
++#include <linux/dma/mxs-dma.h>
+
+ #define DRIVER_NAME "mxs-i2c"
+
+@@ -200,7 +201,8 @@ static int mxs_i2c_dma_setup_xfer(struct i2c_adapter *adap,
+ dma_map_sg(i2c->dev, &i2c->sg_io[0], 1, DMA_TO_DEVICE);
+ desc = dmaengine_prep_slave_sg(i2c->dmach, &i2c->sg_io[0], 1,
+ DMA_MEM_TO_DEV,
+- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
++ DMA_PREP_INTERRUPT |
++ MXS_DMA_CTRL_WAIT4END);
+ if (!desc) {
+ dev_err(i2c->dev,
+ "Failed to get DMA data write descriptor.\n");
+@@ -228,7 +230,8 @@ static int mxs_i2c_dma_setup_xfer(struct i2c_adapter *adap,
+ dma_map_sg(i2c->dev, &i2c->sg_io[1], 1, DMA_FROM_DEVICE);
+ desc = dmaengine_prep_slave_sg(i2c->dmach, &i2c->sg_io[1], 1,
+ DMA_DEV_TO_MEM,
+- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
++ DMA_PREP_INTERRUPT |
++ MXS_DMA_CTRL_WAIT4END);
+ if (!desc) {
+ dev_err(i2c->dev,
+ "Failed to get DMA data write descriptor.\n");
+@@ -260,7 +263,8 @@ static int mxs_i2c_dma_setup_xfer(struct i2c_adapter *adap,
+ dma_map_sg(i2c->dev, i2c->sg_io, 2, DMA_TO_DEVICE);
+ desc = dmaengine_prep_slave_sg(i2c->dmach, i2c->sg_io, 2,
+ DMA_MEM_TO_DEV,
+- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
++ DMA_PREP_INTERRUPT |
++ MXS_DMA_CTRL_WAIT4END);
+ if (!desc) {
+ dev_err(i2c->dev,
+ "Failed to get DMA data write descriptor.\n");
+--
+2.25.1
+
--- /dev/null
+From 34dd382355cdf7699c30cb12b53113669537b412 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Sep 2020 18:16:21 +0100
+Subject: iommu/amd: Fix potential @entry null deref
+
+From: Joao Martins <joao.m.martins@oracle.com>
+
+[ Upstream commit 14c4acc5ed22c21f9821103be7c48efdf9763584 ]
+
+After commit 26e495f34107 ("iommu/amd: Restore IRTE.RemapEn bit after
+programming IRTE"), smatch warns:
+
+ drivers/iommu/amd/iommu.c:3870 amd_iommu_deactivate_guest_mode()
+ warn: variable dereferenced before check 'entry' (see line 3867)
+
+Fix this by moving the @valid assignment to after @entry has been checked
+for NULL.
+
+Fixes: 26e495f34107 ("iommu/amd: Restore IRTE.RemapEn bit after programming IRTE")
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
+Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Link: https://lore.kernel.org/r/20200910171621.12879-1-joao.m.martins@oracle.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/amd_iommu.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
+index cdafc652d9d1a..fa91d856a43ee 100644
+--- a/drivers/iommu/amd_iommu.c
++++ b/drivers/iommu/amd_iommu.c
+@@ -4431,12 +4431,14 @@ int amd_iommu_deactivate_guest_mode(void *data)
+ struct amd_ir_data *ir_data = (struct amd_ir_data *)data;
+ struct irte_ga *entry = (struct irte_ga *) ir_data->entry;
+ struct irq_cfg *cfg = ir_data->cfg;
+- u64 valid = entry->lo.fields_remap.valid;
++ u64 valid;
+
+ if (!AMD_IOMMU_GUEST_IR_VAPIC(amd_iommu_guest_ir) ||
+ !entry || !entry->lo.fields_vapic.guest_mode)
+ return 0;
+
++ valid = entry->lo.fields_remap.valid;
++
+ entry->lo.val = 0;
+ entry->hi.val = 0;
+
+--
+2.25.1
+
--- /dev/null
+From dbda54d3cd891d53338a85c15b0de37652434257 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Sep 2020 18:33:51 +0800
+Subject: KVM: MIPS: Change the definition of kvm type
+
+From: Huacai Chen <chenhc@lemote.com>
+
+[ Upstream commit 15e9e35cd1dec2bc138464de6bf8ef828df19235 ]
+
+MIPS defines two kvm types:
+
+ #define KVM_VM_MIPS_TE 0
+ #define KVM_VM_MIPS_VZ 1
+
+In Documentation/virt/kvm/api.rst it is said that "You probably want to
+use 0 as machine type", which implies that type 0 be the "automatic" or
+"default" type. And, in user-space libvirt use the null-machine (with
+type 0) to detect the kvm capability, which returns "KVM not supported"
+on a VZ platform.
+
+I try to fix it in QEMU but it is ugly:
+https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg05629.html
+
+And Thomas Huth suggests me to change the definition of kvm type:
+https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03281.html
+
+So I define like this:
+
+ #define KVM_VM_MIPS_AUTO 0
+ #define KVM_VM_MIPS_VZ 1
+ #define KVM_VM_MIPS_TE 2
+
+Since VZ and TE cannot co-exists, using type 0 on a TE platform will
+still return success (so old user-space tools have no problems on new
+kernels); the advantage is that using type 0 on a VZ platform will not
+return failure. So, the only problem is "new user-space tools use type
+2 on old kernels", but if we treat this as a kernel bug, we can backport
+this patch to old stable kernels.
+
+Signed-off-by: Huacai Chen <chenhc@lemote.com>
+Message-Id: <1599734031-28746-1-git-send-email-chenhc@lemote.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kvm/mips.c | 2 ++
+ include/uapi/linux/kvm.h | 5 +++--
+ 2 files changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
+index 1109924560d8c..b22a3565e1330 100644
+--- a/arch/mips/kvm/mips.c
++++ b/arch/mips/kvm/mips.c
+@@ -131,6 +131,8 @@ int kvm_arch_check_processor_compat(void)
+ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
+ {
+ switch (type) {
++ case KVM_VM_MIPS_AUTO:
++ break;
+ #ifdef CONFIG_KVM_MIPS_VZ
+ case KVM_VM_MIPS_VZ:
+ #else
+diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
+index e735bc4075dc7..1b6b8e05868dd 100644
+--- a/include/uapi/linux/kvm.h
++++ b/include/uapi/linux/kvm.h
+@@ -768,9 +768,10 @@ struct kvm_ppc_resize_hpt {
+ #define KVM_VM_PPC_HV 1
+ #define KVM_VM_PPC_PR 2
+
+-/* on MIPS, 0 forces trap & emulate, 1 forces VZ ASE */
+-#define KVM_VM_MIPS_TE 0
++/* on MIPS, 0 indicates auto, 1 forces VZ ASE, 2 forces trap & emulate */
++#define KVM_VM_MIPS_AUTO 0
+ #define KVM_VM_MIPS_VZ 1
++#define KVM_VM_MIPS_TE 2
+
+ #define KVM_S390_SIE_PAGE_OFFSET 1
+
+--
+2.25.1
+
--- /dev/null
+From a029506ec14d3a4fffedf3683dc2724d23c00066 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Sep 2020 18:05:00 +0200
+Subject: MIPS: SNI: Fix MIPS_L1_CACHE_SHIFT
+
+From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+[ Upstream commit 564c836fd945a94b5dd46597d6b7adb464092650 ]
+
+Commit 930beb5ac09a ("MIPS: introduce MIPS_L1_CACHE_SHIFT_<N>") forgot
+to select the correct MIPS_L1_CACHE_SHIFT for SNI RM. This breaks non
+coherent DMA because of a wrong allocation alignment.
+
+Fixes: 930beb5ac09a ("MIPS: introduce MIPS_L1_CACHE_SHIFT_<N>")
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
+index e5c2d47608feb..6ecdc690f7336 100644
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -862,6 +862,7 @@ config SNI_RM
+ select I8253
+ select I8259
+ select ISA
++ select MIPS_L1_CACHE_SHIFT_6
+ select SWAP_IO_SPACE if CPU_BIG_ENDIAN
+ select SYS_HAS_CPU_R4X00
+ select SYS_HAS_CPU_R5000
+--
+2.25.1
+
--- /dev/null
+From 67aa6669822a182b5fc5fccc8705aeac45f772d1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Sep 2020 15:54:37 +0200
+Subject: MIPS: SNI: Fix spurious interrupts
+
+From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]
+
+On A20R machines the interrupt pending bits in cause register need to be
+updated by requesting the chipset to do it. This needs to be done to
+find the interrupt cause and after interrupt service. In
+commit 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
+function to do after service update got lost, which caused spurious
+interrupts.
+
+Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/sni/a20r.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
+index f9407e1704762..c6af7047eb0d2 100644
+--- a/arch/mips/sni/a20r.c
++++ b/arch/mips/sni/a20r.c
+@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
+ },
+ };
+
+-static u32 a20r_ack_hwint(void)
++/*
++ * Trigger chipset to update CPU's CAUSE IP field
++ */
++static u32 a20r_update_cause_ip(void)
+ {
+ u32 status = read_c0_status();
+
+@@ -205,12 +208,14 @@ static void a20r_hwint(void)
+ int irq;
+
+ clear_c0_status(IE_IRQ0);
+- status = a20r_ack_hwint();
++ status = a20r_update_cause_ip();
+ cause = read_c0_cause();
+
+ irq = ffs(((cause & status) >> 8) & 0xf8);
+ if (likely(irq > 0))
+ do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
++
++ a20r_update_cause_ip();
+ set_c0_status(IE_IRQ0);
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 49fe8020552b5eaec4d0f6738c7723248dd290df Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Sep 2020 17:39:12 -0400
+Subject: NFS: Zero-stateid SETATTR should first return delegation
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+[ Upstream commit 644c9f40cf71969f29add32f32349e71d4995c0b ]
+
+If a write delegation isn't available, the Linux NFS client uses
+a zero-stateid when performing a SETATTR.
+
+NFSv4.0 provides no mechanism for an NFS server to match such a
+request to a particular client. It recalls all delegations for that
+file, even delegations held by the client issuing the request. If
+that client happens to hold a read delegation, the server will
+recall it immediately, resulting in an NFS4ERR_DELAY/CB_RECALL/
+DELEGRETURN sequence.
+
+Optimize out this pipeline bubble by having the client return any
+delegations it may hold on a file before it issues a
+SETATTR(zero-stateid) on that file.
+
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4proc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
+index 16414ae02c089..00435556db0ce 100644
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -3257,8 +3257,10 @@ static int _nfs4_do_setattr(struct inode *inode,
+
+ /* Servers should only apply open mode checks for file size changes */
+ truncate = (arg->iap->ia_valid & ATTR_SIZE) ? true : false;
+- if (!truncate)
++ if (!truncate) {
++ nfs4_inode_make_writeable(inode);
+ goto zero_stateid;
++ }
+
+ if (nfs4_copy_delegation_stateid(inode, FMODE_WRITE, &arg->stateid, &delegation_cred)) {
+ /* Use that stateid */
+--
+2.25.1
+
--- /dev/null
+From 046ce82dcebcd87c29e234b23774aededb5c08ef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Aug 2020 18:52:43 -0400
+Subject: NFSv4.1 handle ERR_DELAY error reclaiming locking state on delegation
+ recall
+
+From: Olga Kornievskaia <kolga@netapp.com>
+
+[ Upstream commit 3d7a9520f0c3e6a68b6de8c5812fc8b6d7a52626 ]
+
+A client should be able to handle getting an ERR_DELAY error
+while doing a LOCK call to reclaim state due to delegation being
+recalled. This is a transient error that can happen due to server
+moving its volumes and invalidating its file location cache and
+upon reference to it during the LOCK call needing to do an
+expensive lookup (leading to an ERR_DELAY error on a PUTFH).
+
+Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4proc.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
+index d0cb827b72cfa..16414ae02c089 100644
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -7232,7 +7232,12 @@ int nfs4_lock_delegation_recall(struct file_lock *fl, struct nfs4_state *state,
+ err = nfs4_set_lock_state(state, fl);
+ if (err != 0)
+ return err;
+- err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
++ do {
++ err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
++ if (err != -NFS4ERR_DELAY)
++ break;
++ ssleep(1);
++ } while (err == -NFS4ERR_DELAY);
+ return nfs4_handle_delegation_recall_error(server, state, stateid, fl, err);
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 0d076b74b49b5f1d55e7cd3b9b99035b19807800 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Sep 2020 17:42:54 -0500
+Subject: nvme-fc: cancel async events before freeing event struct
+
+From: David Milburn <dmilburn@redhat.com>
+
+[ Upstream commit e126e8210e950bb83414c4f57b3120ddb8450742 ]
+
+Cancel async event work in case async event has been queued up, and
+nvme_fc_submit_async_event() runs after event has been freed.
+
+Signed-off-by: David Milburn <dmilburn@redhat.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/fc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
+index dce4d6782ceb1..dae050d1f814d 100644
+--- a/drivers/nvme/host/fc.c
++++ b/drivers/nvme/host/fc.c
+@@ -1820,6 +1820,7 @@ nvme_fc_term_aen_ops(struct nvme_fc_ctrl *ctrl)
+ struct nvme_fc_fcp_op *aen_op;
+ int i;
+
++ cancel_work_sync(&ctrl->ctrl.async_event_work);
+ aen_op = ctrl->aen_ops;
+ for (i = 0; i < NVME_NR_AEN_COMMANDS; i++, aen_op++) {
+ if (!aen_op->fcp_req.private)
+--
+2.25.1
+
--- /dev/null
+From 176b1784728bcd8439e524b80e7a6e0ede6c7b2e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Sep 2020 17:42:52 -0500
+Subject: nvme-rdma: cancel async events before freeing event struct
+
+From: David Milburn <dmilburn@redhat.com>
+
+[ Upstream commit 925dd04c1f9825194b9e444c12478084813b2b5d ]
+
+Cancel async event work in case async event has been queued up, and
+nvme_rdma_submit_async_event() runs after event has been freed.
+
+Signed-off-by: David Milburn <dmilburn@redhat.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/rdma.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
+index f0847f2bb117b..f9444272f861e 100644
+--- a/drivers/nvme/host/rdma.c
++++ b/drivers/nvme/host/rdma.c
+@@ -769,6 +769,7 @@ static void nvme_rdma_destroy_admin_queue(struct nvme_rdma_ctrl *ctrl,
+ blk_mq_free_tag_set(ctrl->ctrl.admin_tagset);
+ }
+ if (ctrl->async_event_sqe.data) {
++ cancel_work_sync(&ctrl->ctrl.async_event_work);
+ nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe,
+ sizeof(struct nvme_command), DMA_TO_DEVICE);
+ ctrl->async_event_sqe.data = NULL;
+--
+2.25.1
+
--- /dev/null
+From e501fe2bdc1c56e277e9d202f6ab0d90ac84c9bb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Sep 2020 17:42:53 -0500
+Subject: nvme-tcp: cancel async events before freeing event struct
+
+From: David Milburn <dmilburn@redhat.com>
+
+[ Upstream commit ceb1e0874dba5cbfc4e0b4145796a4bfb3716e6a ]
+
+Cancel async event work in case async event has been queued up, and
+nvme_tcp_submit_async_event() runs after event has been freed.
+
+Signed-off-by: David Milburn <dmilburn@redhat.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/tcp.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
+index 9b81763b44d99..c782005ee99f9 100644
+--- a/drivers/nvme/host/tcp.c
++++ b/drivers/nvme/host/tcp.c
+@@ -1507,6 +1507,7 @@ static struct blk_mq_tag_set *nvme_tcp_alloc_tagset(struct nvme_ctrl *nctrl,
+ static void nvme_tcp_free_admin_queue(struct nvme_ctrl *ctrl)
+ {
+ if (to_tcp_ctrl(ctrl)->async_req.pdu) {
++ cancel_work_sync(&ctrl->async_event_work);
+ nvme_tcp_free_async_req(to_tcp_ctrl(ctrl));
+ to_tcp_ctrl(ctrl)->async_req.pdu = NULL;
+ }
+--
+2.25.1
+
--- /dev/null
+From c80f2165917c8293c9207fa661fc14d193d742fc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Sep 2020 05:48:58 +0900
+Subject: openrisc: Fix cache API compile issue when not inlining
+
+From: Stafford Horne <shorne@gmail.com>
+
+[ Upstream commit 3ae90d764093dfcd6ab8ab6875377302892c87d4 ]
+
+I found this when compiling a kbuild random config with GCC 11. The
+config enables CONFIG_DEBUG_SECTION_MISMATCH, which sets CFLAGS
+-fno-inline-functions-called-once. This causes the call to cache_loop in
+cache.c to not be inlined causing the below compile error.
+
+ In file included from arch/openrisc/mm/cache.c:13:
+ arch/openrisc/mm/cache.c: In function 'cache_loop':
+ ./arch/openrisc/include/asm/spr.h:16:27: warning: 'asm' operand 0 probably does not match constraints
+ 16 | #define mtspr(_spr, _val) __asm__ __volatile__ ( \
+ | ^~~~~~~
+ arch/openrisc/mm/cache.c:25:3: note: in expansion of macro 'mtspr'
+ 25 | mtspr(reg, line);
+ | ^~~~~
+ ./arch/openrisc/include/asm/spr.h:16:27: error: impossible constraint in 'asm'
+ 16 | #define mtspr(_spr, _val) __asm__ __volatile__ ( \
+ | ^~~~~~~
+ arch/openrisc/mm/cache.c:25:3: note: in expansion of macro 'mtspr'
+ 25 | mtspr(reg, line);
+ | ^~~~~
+ make[1]: *** [scripts/Makefile.build:283: arch/openrisc/mm/cache.o] Error 1
+
+The asm constraint "K" requires a immediate constant argument to mtspr,
+however because of no inlining a register argument is passed causing a
+failure. Fix this by using __always_inline.
+
+Link: https://lore.kernel.org/lkml/202008200453.ohnhqkjQ%25lkp@intel.com/
+Signed-off-by: Stafford Horne <shorne@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/openrisc/mm/cache.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/openrisc/mm/cache.c b/arch/openrisc/mm/cache.c
+index 08f56af387ac4..534a52ec5e667 100644
+--- a/arch/openrisc/mm/cache.c
++++ b/arch/openrisc/mm/cache.c
+@@ -16,7 +16,7 @@
+ #include <asm/cacheflush.h>
+ #include <asm/tlbflush.h>
+
+-static void cache_loop(struct page *page, const unsigned int reg)
++static __always_inline void cache_loop(struct page *page, const unsigned int reg)
+ {
+ unsigned long paddr = page_to_pfn(page) << PAGE_SHIFT;
+ unsigned long line = paddr & ~(L1_CACHE_BYTES - 1);
+--
+2.25.1
+
--- /dev/null
+From 17a1f2e4beec3707e9b3688bf5f32e0e2abf2c18 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Sep 2020 12:18:11 +0900
+Subject: perf evlist: Fix cpu/thread map leak
+
+From: Namhyung Kim <namhyung@kernel.org>
+
+[ Upstream commit bfd1b83d75e44a9f65de30accb3dd3b5940bd3ac ]
+
+Asan reported leak of cpu and thread maps as they have one more refcount
+than released. I found that after setting evlist maps it should release
+it's refcount.
+
+It seems to be broken from the beginning so I chose the original commit
+as the culprit. But not sure how it's applied to stable trees since
+there are many changes in the code after that.
+
+Fixes: 7e2ed097538c5 ("perf evlist: Store pointer to the cpu and thread maps")
+Fixes: 4112eb1899c0e ("perf evlist: Default to syswide target when no thread/cpu maps set")
+Signed-off-by: Namhyung Kim <namhyung@kernel.org>
+Acked-by: Jiri Olsa <jolsa@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Andi Kleen <ak@linux.intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Link: http://lore.kernel.org/lkml/20200915031819.386559-4-namhyung@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/evlist.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
+index de79c735e4411..505b890ac85cc 100644
+--- a/tools/perf/util/evlist.c
++++ b/tools/perf/util/evlist.c
+@@ -976,6 +976,10 @@ int perf_evlist__create_maps(struct evlist *evlist, struct target *target)
+
+ perf_evlist__set_maps(&evlist->core, cpus, threads);
+
++ /* as evlist now has references, put count here */
++ perf_cpu_map__put(cpus);
++ perf_thread_map__put(threads);
++
+ return 0;
+
+ out_delete_threads:
+@@ -1230,11 +1234,12 @@ static int perf_evlist__create_syswide_maps(struct evlist *evlist)
+ goto out_put;
+
+ perf_evlist__set_maps(&evlist->core, cpus, threads);
+-out:
+- return err;
++
++ perf_thread_map__put(threads);
+ out_put:
+ perf_cpu_map__put(cpus);
+- goto out;
++out:
++ return err;
+ }
+
+ int evlist__open(struct evlist *evlist)
+--
+2.25.1
+
--- /dev/null
+From 7b0a8ebaa83aa212dd7c56e44e31336efefafb30 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Sep 2020 12:18:13 +0900
+Subject: perf parse-event: Fix memory leak in evsel->unit
+
+From: Namhyung Kim <namhyung@kernel.org>
+
+[ Upstream commit b12eea5ad8e77f8a380a141e3db67c07432dde16 ]
+
+The evsel->unit borrows a pointer of pmu event or alias instead of
+owns a string. But tool event (duration_time) passes a result of
+strdup() caused a leak.
+
+It was found by ASAN during metric test:
+
+ Direct leak of 210 byte(s) in 70 object(s) allocated from:
+ #0 0x7fe366fca0b5 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x920b5)
+ #1 0x559fbbcc6ea3 in add_event_tool util/parse-events.c:414
+ #2 0x559fbbcc6ea3 in parse_events_add_tool util/parse-events.c:1414
+ #3 0x559fbbd8474d in parse_events_parse util/parse-events.y:439
+ #4 0x559fbbcc95da in parse_events__scanner util/parse-events.c:2096
+ #5 0x559fbbcc95da in __parse_events util/parse-events.c:2141
+ #6 0x559fbbc28555 in check_parse_id tests/pmu-events.c:406
+ #7 0x559fbbc28555 in check_parse_id tests/pmu-events.c:393
+ #8 0x559fbbc28555 in check_parse_cpu tests/pmu-events.c:415
+ #9 0x559fbbc28555 in test_parsing tests/pmu-events.c:498
+ #10 0x559fbbc0109b in run_test tests/builtin-test.c:410
+ #11 0x559fbbc0109b in test_and_print tests/builtin-test.c:440
+ #12 0x559fbbc03e69 in __cmd_test tests/builtin-test.c:695
+ #13 0x559fbbc03e69 in cmd_test tests/builtin-test.c:807
+ #14 0x559fbbc691f4 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:312
+ #15 0x559fbbb071a8 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:364
+ #16 0x559fbbb071a8 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:408
+ #17 0x559fbbb071a8 in main /home/namhyung/project/linux/tools/perf/perf.c:538
+ #18 0x7fe366b68cc9 in __libc_start_main ../csu/libc-start.c:308
+
+Fixes: f0fbb114e3025 ("perf stat: Implement duration_time as a proper event")
+Signed-off-by: Namhyung Kim <namhyung@kernel.org>
+Acked-by: Jiri Olsa <jolsa@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Andi Kleen <ak@linux.intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Link: http://lore.kernel.org/lkml/20200915031819.386559-6-namhyung@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/parse-events.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
+index 422ad1888e74f..759a99f723fc3 100644
+--- a/tools/perf/util/parse-events.c
++++ b/tools/perf/util/parse-events.c
+@@ -370,7 +370,7 @@ static int add_event_tool(struct list_head *list, int *idx,
+ return -ENOMEM;
+ evsel->tool_event = tool_event;
+ if (tool_event == PERF_TOOL_DURATION_TIME)
+- evsel->unit = strdup("ns");
++ evsel->unit = "ns";
+ return 0;
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 7135f79a20b6d39ac83519fdb6ce6277a8529732 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Sep 2020 15:00:05 +0200
+Subject: perf test: Fix the "signal" test inline assembly
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+[ Upstream commit 8a39e8c4d9baf65d88f66d49ac684df381e30055 ]
+
+When compiling with DEBUG=1 on Fedora 32 I'm getting crash for 'perf
+test signal':
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0000000000c68548 in __test_function ()
+ (gdb) bt
+ #0 0x0000000000c68548 in __test_function ()
+ #1 0x00000000004d62e9 in test_function () at tests/bp_signal.c:61
+ #2 0x00000000004d689a in test__bp_signal (test=0xa8e280 <generic_ ...
+ #3 0x00000000004b7d49 in run_test (test=0xa8e280 <generic_tests+1 ...
+ #4 0x00000000004b7e7f in test_and_print (t=0xa8e280 <generic_test ...
+ #5 0x00000000004b8927 in __cmd_test (argc=1, argv=0x7fffffffdce0, ...
+ ...
+
+It's caused by the symbol __test_function being in the ".bss" section:
+
+ $ readelf -a ./perf | less
+ [Nr] Name Type Address Offset
+ Size EntSize Flags Link Info Align
+ ...
+ [28] .bss NOBITS 0000000000c356a0 008346a0
+ 00000000000511f8 0000000000000000 WA 0 0 32
+
+ $ nm perf | grep __test_function
+ 0000000000c68548 B __test_function
+
+I guess most of the time we're just lucky the inline asm ended up in the
+".text" section, so making it specific explicit with push and pop
+section clauses.
+
+ $ readelf -a ./perf | less
+ [Nr] Name Type Address Offset
+ Size EntSize Flags Link Info Align
+ ...
+ [13] .text PROGBITS 0000000000431240 00031240
+ 0000000000306faa 0000000000000000 AX 0 0 16
+
+ $ nm perf | grep __test_function
+ 00000000004d62c8 T __test_function
+
+Committer testing:
+
+ $ readelf -wi ~/bin/perf | grep producer -m1
+ <c> DW_AT_producer : (indirect string, offset: 0x254a): GNU C99 10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -ggdb3 -std=gnu99 -fno-omit-frame-pointer -funwind-tables -fstack-protector-all
+ ^^^^^
+ ^^^^^
+ ^^^^^
+ $
+
+Before:
+
+ $ perf test signal
+ 20: Breakpoint overflow signal handler : FAILED!
+ $
+
+After:
+
+ $ perf test signal
+ 20: Breakpoint overflow signal handler : Ok
+ $
+
+Fixes: 8fd34e1cce18 ("perf test: Improve bp_signal")
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+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: Wang Nan <wangnan0@huawei.com>
+Link: http://lore.kernel.org/lkml/20200911130005.1842138-1-jolsa@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/tests/bp_signal.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c
+index 166f411568a50..b5cdedd13cbc7 100644
+--- a/tools/perf/tests/bp_signal.c
++++ b/tools/perf/tests/bp_signal.c
+@@ -45,10 +45,13 @@ volatile long the_var;
+ #if defined (__x86_64__)
+ extern void __test_function(volatile long *ptr);
+ asm (
++ ".pushsection .text;"
+ ".globl __test_function\n"
++ ".type __test_function, @function;"
+ "__test_function:\n"
+ "incq (%rdi)\n"
+- "ret\n");
++ "ret\n"
++ ".popsection\n");
+ #else
+ static void __test_function(volatile long *ptr)
+ {
+--
+2.25.1
+
--- /dev/null
+From 787e930708d209b8cf7d1fea1249fe994a37c62f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Sep 2020 12:18:19 +0900
+Subject: perf test: Free formats for perf pmu parse test
+
+From: Namhyung Kim <namhyung@kernel.org>
+
+[ Upstream commit d26383dcb2b4b8629fde05270b4e3633be9e3d4b ]
+
+The following leaks were detected by ASAN:
+
+ Indirect leak of 360 byte(s) in 9 object(s) allocated from:
+ #0 0x7fecc305180e in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10780e)
+ #1 0x560578f6dce5 in perf_pmu__new_format util/pmu.c:1333
+ #2 0x560578f752fc in perf_pmu_parse util/pmu.y:59
+ #3 0x560578f6a8b7 in perf_pmu__format_parse util/pmu.c:73
+ #4 0x560578e07045 in test__pmu tests/pmu.c:155
+ #5 0x560578de109b in run_test tests/builtin-test.c:410
+ #6 0x560578de109b in test_and_print tests/builtin-test.c:440
+ #7 0x560578de401a in __cmd_test tests/builtin-test.c:661
+ #8 0x560578de401a in cmd_test tests/builtin-test.c:807
+ #9 0x560578e49354 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:312
+ #10 0x560578ce71a8 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:364
+ #11 0x560578ce71a8 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:408
+ #12 0x560578ce71a8 in main /home/namhyung/project/linux/tools/perf/perf.c:538
+ #13 0x7fecc2b7acc9 in __libc_start_main ../csu/libc-start.c:308
+
+Fixes: cff7f956ec4a1 ("perf tests: Move pmu tests into separate object")
+Signed-off-by: Namhyung Kim <namhyung@kernel.org>
+Acked-by: Jiri Olsa <jolsa@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Andi Kleen <ak@linux.intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Link: http://lore.kernel.org/lkml/20200915031819.386559-12-namhyung@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/tests/pmu.c | 1 +
+ tools/perf/util/pmu.c | 11 +++++++++++
+ tools/perf/util/pmu.h | 1 +
+ 3 files changed, 13 insertions(+)
+
+diff --git a/tools/perf/tests/pmu.c b/tools/perf/tests/pmu.c
+index 74379ff1f7fa0..46cd1db85bd06 100644
+--- a/tools/perf/tests/pmu.c
++++ b/tools/perf/tests/pmu.c
+@@ -173,6 +173,7 @@ int test__pmu(struct test *test __maybe_unused, int subtest __maybe_unused)
+ ret = 0;
+ } while (0);
+
++ perf_pmu__del_formats(&formats);
+ test_format_dir_put(format);
+ return ret;
+ }
+diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
+index 5608da82ad239..628a6d5a5b384 100644
+--- a/tools/perf/util/pmu.c
++++ b/tools/perf/util/pmu.c
+@@ -1294,6 +1294,17 @@ void perf_pmu__set_format(unsigned long *bits, long from, long to)
+ set_bit(b, bits);
+ }
+
++void perf_pmu__del_formats(struct list_head *formats)
++{
++ struct perf_pmu_format *fmt, *tmp;
++
++ list_for_each_entry_safe(fmt, tmp, formats, list) {
++ list_del(&fmt->list);
++ free(fmt->name);
++ free(fmt);
++ }
++}
++
+ static int sub_non_neg(int a, int b)
+ {
+ if (b > a)
+diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
+index f36ade6df76d1..9570d9b26250f 100644
+--- a/tools/perf/util/pmu.h
++++ b/tools/perf/util/pmu.h
+@@ -81,6 +81,7 @@ int perf_pmu__new_format(struct list_head *list, char *name,
+ int config, unsigned long *bits);
+ void perf_pmu__set_format(unsigned long *bits, long from, long to);
+ int perf_pmu__format_parse(char *dir, struct list_head *head);
++void perf_pmu__del_formats(struct list_head *formats);
+
+ struct perf_pmu *perf_pmu__scan(struct perf_pmu *pmu);
+
+--
+2.25.1
+
--- /dev/null
+From d64726399f73a88adaa7dafed2241b7ad4d643ab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Aug 2020 15:38:52 +0530
+Subject: powerpc/book3s64/radix: Fix boot failure with large amount of guest
+ memory
+
+From: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+
+[ Upstream commit 103a8542cb35b5130f732d00b0419a594ba1b517 ]
+
+If the hypervisor doesn't support hugepages, the kernel ends up allocating a large
+number of page table pages. The early page table allocation was wrongly
+setting the max memblock limit to ppc64_rma_size with radix translation
+which resulted in boot failure as shown below.
+
+Kernel panic - not syncing:
+early_alloc_pgtable: Failed to allocate 16777216 bytes align=0x1000000 nid=-1 from=0x0000000000000000 max_addr=0xffffffffffffffff
+ CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-24.9-default+ #2
+ Call Trace:
+ [c0000000016f3d00] [c0000000007c6470] dump_stack+0xc4/0x114 (unreliable)
+ [c0000000016f3d40] [c00000000014c78c] panic+0x164/0x418
+ [c0000000016f3dd0] [c000000000098890] early_alloc_pgtable+0xe0/0xec
+ [c0000000016f3e60] [c0000000010a5440] radix__early_init_mmu+0x360/0x4b4
+ [c0000000016f3ef0] [c000000001099bac] early_init_mmu+0x1c/0x3c
+ [c0000000016f3f10] [c00000000109a320] early_setup+0x134/0x170
+
+This was because the kernel was checking for the radix feature before we enable the
+feature via mmu_features. This resulted in the kernel using hash restrictions on
+radix.
+
+Rework the early init code such that the kernel boot with memblock restrictions
+as imposed by hash. At that point, the kernel still hasn't finalized the
+translation the kernel will end up using.
+
+We have three different ways of detecting radix.
+
+1. dt_cpu_ftrs_scan -> used only in case of PowerNV
+2. ibm,pa-features -> Used when we don't use cpu_dt_ftr_scan
+3. CAS -> Where we negotiate with hypervisor about the supported translation.
+
+We look at 1 or 2 early in the boot and after that, we look at the CAS vector to
+finalize the translation the kernel will use. We also support a kernel command
+line option (disable_radix) to switch to hash.
+
+Update the memblock limit after mmu_early_init_devtree() if the kernel is going
+to use radix translation. This forces some of the memblock allocations we do before
+mmu_early_init_devtree() to be within the RMA limit.
+
+Fixes: 2bfd65e45e87 ("powerpc/mm/radix: Add radix callbacks for early init routines")
+Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
+Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200828100852.426575-1-aneesh.kumar@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/include/asm/book3s/64/mmu.h | 10 +++++-----
+ arch/powerpc/mm/book3s64/radix_pgtable.c | 15 ---------------
+ arch/powerpc/mm/init_64.c | 11 +++++++++--
+ 3 files changed, 14 insertions(+), 22 deletions(-)
+
+diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
+index bb3deb76c951b..2f4ddc802fe9d 100644
+--- a/arch/powerpc/include/asm/book3s/64/mmu.h
++++ b/arch/powerpc/include/asm/book3s/64/mmu.h
+@@ -225,14 +225,14 @@ static inline void early_init_mmu_secondary(void)
+
+ extern void hash__setup_initial_memory_limit(phys_addr_t first_memblock_base,
+ phys_addr_t first_memblock_size);
+-extern void radix__setup_initial_memory_limit(phys_addr_t first_memblock_base,
+- phys_addr_t first_memblock_size);
+ static inline void setup_initial_memory_limit(phys_addr_t first_memblock_base,
+ phys_addr_t first_memblock_size)
+ {
+- if (early_radix_enabled())
+- return radix__setup_initial_memory_limit(first_memblock_base,
+- first_memblock_size);
++ /*
++ * Hash has more strict restrictions. At this point we don't
++ * know which translations we will pick. Hence go with hash
++ * restrictions.
++ */
+ return hash__setup_initial_memory_limit(first_memblock_base,
+ first_memblock_size);
+ }
+diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
+index 6ee17d09649c3..770542ccdb468 100644
+--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
++++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
+@@ -643,21 +643,6 @@ void radix__mmu_cleanup_all(void)
+ }
+ }
+
+-void radix__setup_initial_memory_limit(phys_addr_t first_memblock_base,
+- phys_addr_t first_memblock_size)
+-{
+- /*
+- * We don't currently support the first MEMBLOCK not mapping 0
+- * physical on those processors
+- */
+- BUG_ON(first_memblock_base != 0);
+-
+- /*
+- * Radix mode is not limited by RMA / VRMA addressing.
+- */
+- ppc64_rma_size = ULONG_MAX;
+-}
+-
+ #ifdef CONFIG_MEMORY_HOTPLUG
+ static void free_pte_table(pte_t *pte_start, pmd_t *pmd)
+ {
+diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
+index 4e08246acd79a..210f1c28b8e41 100644
+--- a/arch/powerpc/mm/init_64.c
++++ b/arch/powerpc/mm/init_64.c
+@@ -415,9 +415,16 @@ void __init mmu_early_init_devtree(void)
+ if (!(mfmsr() & MSR_HV))
+ early_check_vec5();
+
+- if (early_radix_enabled())
++ if (early_radix_enabled()) {
+ radix__early_init_devtree();
+- else
++ /*
++ * We have finalized the translation we are going to use by now.
++ * Radix mode is not limited by RMA / VRMA addressing.
++ * Hence don't limit memblock allocations.
++ */
++ ppc64_rma_size = ULONG_MAX;
++ memblock_set_current_limit(MEMBLOCK_ALLOC_ANYWHERE);
++ } else
+ hash__early_init_devtree();
+ }
+ #endif /* CONFIG_PPC_BOOK3S_64 */
+--
+2.25.1
+
--- /dev/null
+From acd81dc1d45e473090d754a2979b840d30c148e6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 29 Jul 2020 01:19:40 +0300
+Subject: rapidio: Replace 'select' DMAENGINES 'with depends on'
+
+From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+[ Upstream commit d2b86100245080cfdf1e95e9e07477474c1be2bd ]
+
+Enabling a whole subsystem from a single driver 'select' is frowned
+upon and won't be accepted in new drivers, that need to use 'depends on'
+instead. Existing selection of DMAENGINES will then cause circular
+dependencies. Replace them with a dependency.
+
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Acked-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/rapidio/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/rapidio/Kconfig b/drivers/rapidio/Kconfig
+index 677d1aff61b7f..788e7830771be 100644
+--- a/drivers/rapidio/Kconfig
++++ b/drivers/rapidio/Kconfig
+@@ -37,7 +37,7 @@ config RAPIDIO_ENABLE_RX_TX_PORTS
+ config RAPIDIO_DMA_ENGINE
+ bool "DMA Engine support for RapidIO"
+ depends on RAPIDIO
+- select DMADEVICES
++ depends on DMADEVICES
+ select DMA_ENGINE
+ help
+ Say Y here if you want to use DMA Engine frameork for RapidIO data
+--
+2.25.1
+
--- /dev/null
+From 5354746b02834587282e52181d8b36e9f58b18c5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Sep 2020 15:09:52 +0200
+Subject: regulator: pwm: Fix machine constraints application
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ Upstream commit 59ae97a7a9e1499c2070e29841d1c4be4ae2994a ]
+
+If the zero duty cycle doesn't correspond to any voltage in the voltage
+table, the PWM regulator returns an -EINVAL from get_voltage_sel() which
+results in the core erroring out with a "failed to get the current
+voltage" and ending up not applying the machine constraints.
+
+Instead, return -ENOTRECOVERABLE which makes the core set the voltage
+since it's at an unknown value.
+
+For example, with this device tree:
+
+ fooregulator {
+ compatible = "pwm-regulator";
+ pwms = <&foopwm 0 100000>;
+ regulator-min-microvolt = <2250000>;
+ regulator-max-microvolt = <2250000>;
+ regulator-name = "fooregulator";
+ regulator-always-on;
+ regulator-boot-on;
+ voltage-table = <2250000 30>;
+ };
+
+Before this patch:
+
+ fooregulator: failed to get the current voltage(-22)
+
+After this patch:
+
+ fooregulator: Setting 2250000-2250000uV
+ fooregulator: 2250 mV
+
+Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Link: https://lore.kernel.org/r/20200902130952.24880-1-vincent.whitchurch@axis.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/regulator/pwm-regulator.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
+index e74e11101fc15..0a9d61a91f436 100644
+--- a/drivers/regulator/pwm-regulator.c
++++ b/drivers/regulator/pwm-regulator.c
+@@ -279,7 +279,7 @@ static int pwm_regulator_init_table(struct platform_device *pdev,
+ return ret;
+ }
+
+- drvdata->state = -EINVAL;
++ drvdata->state = -ENOTRECOVERABLE;
+ drvdata->duty_cycle_table = duty_cycle_table;
+ drvdata->desc.ops = &pwm_regulator_voltage_table_ops;
+ drvdata->desc.n_voltages = length / sizeof(*duty_cycle_table);
+--
+2.25.1
+
--- /dev/null
+From 885422c3b83926fcd4481ed60552dbc52f1ac63c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 4 Aug 2020 11:02:05 +0800
+Subject: riscv: Add sfence.vma after early page table changes
+
+From: Greentime Hu <greentime.hu@sifive.com>
+
+[ Upstream commit 21190b74bcf3a36ebab9a715088c29f59877e1f3 ]
+
+This invalidates local TLB after modifying the page tables during early init as
+it's too early to handle suprious faults as we otherwise do.
+
+Fixes: f2c17aabc917 ("RISC-V: Implement compile-time fixed mappings")
+Reported-by: Syven Wang <syven.wang@sifive.com>
+Signed-off-by: Syven Wang <syven.wang@sifive.com>
+Signed-off-by: Greentime Hu <greentime.hu@sifive.com>
+Reviewed-by: Anup Patel <anup@brainfault.org>
+[Palmer: Cleaned up the commit text]
+Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/mm/init.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
+index b1eb6a0411183..d49e334071d45 100644
+--- a/arch/riscv/mm/init.c
++++ b/arch/riscv/mm/init.c
+@@ -167,12 +167,11 @@ void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot)
+
+ ptep = &fixmap_pte[pte_index(addr)];
+
+- if (pgprot_val(prot)) {
++ if (pgprot_val(prot))
+ set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, prot));
+- } else {
++ else
+ pte_clear(&init_mm, addr, ptep);
+- local_flush_tlb_page(addr);
+- }
++ local_flush_tlb_page(addr);
+ }
+
+ static pte_t *__init get_pte_virt(phys_addr_t pa)
+--
+2.25.1
+
--- /dev/null
+From 6689cdda46ac8275dcece888417bbd8ba54b5d67 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 Aug 2020 02:39:40 -0700
+Subject: scsi: libfc: Fix for double free()
+
+From: Javed Hasan <jhasan@marvell.com>
+
+[ Upstream commit 5a5b80f98534416b3b253859897e2ba1dc241e70 ]
+
+Fix for '&fp->skb' double free.
+
+Link:
+https://lore.kernel.org/r/20200825093940.19612-1-jhasan@marvell.com
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Javed Hasan <jhasan@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/libfc/fc_disc.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/drivers/scsi/libfc/fc_disc.c b/drivers/scsi/libfc/fc_disc.c
+index e00dc4693fcbd..589ddf003886e 100644
+--- a/drivers/scsi/libfc/fc_disc.c
++++ b/drivers/scsi/libfc/fc_disc.c
+@@ -634,8 +634,6 @@ free_fp:
+ fc_frame_free(fp);
+ out:
+ kref_put(&rdata->kref, fc_rport_destroy);
+- if (!IS_ERR(fp))
+- fc_frame_free(fp);
+ }
+
+ /**
+--
+2.25.1
+
--- /dev/null
+From 692db106e210ed2944b34190c0f41b0a969a68f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 5 Sep 2020 15:58:36 +0300
+Subject: scsi: libsas: Fix error path in sas_notify_lldd_dev_found()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 244359c99fd90f1c61c3944f93250f8219435c75 ]
+
+In sas_notify_lldd_dev_found(), if we can't allocate the necessary
+resources, then it seems like the wrong thing to mark the device as found
+and to increment the reference count. None of the callers ever drop the
+reference in that situation.
+
+[mkp: tweaked commit desc based on feedback from John]
+
+Link: https://lore.kernel.org/r/20200905125836.GF183976@mwanda
+Fixes: 735f7d2fedf5 ("[SCSI] libsas: fix domain_device leak")
+Reviewed-by: Jason Yan <yanaijie@huawei.com>
+Acked-by: John Garry <john.garry@huawei.com>
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/libsas/sas_discover.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c
+index d7302c2052f91..10975f3f7ff65 100644
+--- a/drivers/scsi/libsas/sas_discover.c
++++ b/drivers/scsi/libsas/sas_discover.c
+@@ -182,10 +182,11 @@ int sas_notify_lldd_dev_found(struct domain_device *dev)
+ pr_warn("driver on host %s cannot handle device %llx, error:%d\n",
+ dev_name(sas_ha->dev),
+ SAS_ADDR(dev->sas_addr), res);
++ return res;
+ }
+ set_bit(SAS_DEV_FOUND, &dev->state);
+ kref_get(&dev->kref);
+- return res;
++ return 0;
+ }
+
+
+--
+2.25.1
+
--- /dev/null
+From 5a03a448850f3ca77c1bc2573a90f5ffe1da2321 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Aug 2020 10:53:30 -0700
+Subject: scsi: lpfc: Fix FLOGI/PLOGI receive race condition in pt2pt discovery
+
+From: James Smart <james.smart@broadcom.com>
+
+[ Upstream commit 7b08e89f98cee9907895fabb64cf437bc505ce9a ]
+
+The driver is unable to successfully login with remote device. During pt2pt
+login, the driver completes its FLOGI request with the remote device having
+WWN precedence. The remote device issues its own (delayed) FLOGI after
+accepting the driver's and, upon transmitting the FLOGI, immediately
+recognizes it has already processed the driver's FLOGI thus it transitions
+to sending a PLOGI before waiting for an ACC to its FLOGI.
+
+In the driver, the FLOGI is received and an ACC sent, followed by the PLOGI
+being received and an ACC sent. The issue is that the PLOGI reception
+occurs before the response from the adapter from the FLOGI ACC is
+received. Processing of the PLOGI sets state flags to perform the REG_RPI
+mailbox command and proceed with the rest of discovery on the port. The
+same completion routine used by both FLOGI and PLOGI is generic in
+nature. One of the things it does is clear flags, and those flags happen to
+drive the rest of discovery. So what happened was the PLOGI processing set
+the flags, the FLOGI ACC completion cleared them, thus when the PLOGI ACC
+completes it doesn't see the flags and stops.
+
+Fix by modifying the generic completion routine to not clear the rest of
+discovery flag (NLP_ACC_REGLOGIN) unless the completion is also associated
+with performing a mailbox command as part of its handling. For things such
+as FLOGI ACC, there isn't a subsequent action to perform with the adapter,
+thus there is no mailbox cmd ptr. PLOGI ACC though will perform REG_RPI
+upon completion, thus there is a mailbox cmd ptr.
+
+Link: https://lore.kernel.org/r/20200828175332.130300-3-james.smart@broadcom.com
+Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
+Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
+Signed-off-by: James Smart <james.smart@broadcom.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/lpfc/lpfc_els.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
+index 94d8f28341009..4e994a693e3f5 100644
+--- a/drivers/scsi/lpfc/lpfc_els.c
++++ b/drivers/scsi/lpfc/lpfc_els.c
+@@ -4442,7 +4442,9 @@ lpfc_cmpl_els_rsp(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb,
+ out:
+ if (ndlp && NLP_CHK_NODE_ACT(ndlp) && shost) {
+ spin_lock_irq(shost->host_lock);
+- ndlp->nlp_flag &= ~(NLP_ACC_REGLOGIN | NLP_RM_DFLT_RPI);
++ if (mbox)
++ ndlp->nlp_flag &= ~NLP_ACC_REGLOGIN;
++ ndlp->nlp_flag &= ~NLP_RM_DFLT_RPI;
+ spin_unlock_irq(shost->host_lock);
+
+ /* If the node is not being used by another discovery thread,
+--
+2.25.1
+
--- /dev/null
+From 41d2dfe787d391d9ea8ab4e2cbe201d812686483 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 23 Aug 2020 17:14:53 +0800
+Subject: scsi: pm8001: Fix memleak in pm8001_exec_internal_task_abort
+
+From: Dinghao Liu <dinghao.liu@zju.edu.cn>
+
+[ Upstream commit ea403fde7552bd61bad6ea45e3feb99db77cb31e ]
+
+When pm8001_tag_alloc() fails, task should be freed just like it is done in
+the subsequent error paths.
+
+Link: https://lore.kernel.org/r/20200823091453.4782-1-dinghao.liu@zju.edu.cn
+Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
+Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/pm8001/pm8001_sas.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c
+index 7e48154e11c36..027bf5b2981b9 100644
+--- a/drivers/scsi/pm8001/pm8001_sas.c
++++ b/drivers/scsi/pm8001/pm8001_sas.c
+@@ -816,7 +816,7 @@ pm8001_exec_internal_task_abort(struct pm8001_hba_info *pm8001_ha,
+
+ res = pm8001_tag_alloc(pm8001_ha, &ccb_tag);
+ if (res)
+- return res;
++ goto ex_err;
+ ccb = &pm8001_ha->ccb_info[ccb_tag];
+ ccb->device = pm8001_dev;
+ ccb->ccb_tag = ccb_tag;
+--
+2.25.1
+
net-handle-the-return-value-of-pskb_carve_frag_list-correctly.patch
hv_netvsc-remove-unlikely-from-netvsc_select_queue.patch
firmware_loader-fix-memory-leak-for-paged-buffer.patch
+nfsv4.1-handle-err_delay-error-reclaiming-locking-st.patch
+scsi-pm8001-fix-memleak-in-pm8001_exec_internal_task.patch
+scsi-libfc-fix-for-double-free.patch
+scsi-lpfc-fix-flogi-plogi-receive-race-condition-in-.patch
+regulator-pwm-fix-machine-constraints-application.patch
+spi-spi-loopback-test-fix-out-of-bounds-read.patch
+nfs-zero-stateid-setattr-should-first-return-delegat.patch
+sunrpc-stop-printk-reading-past-end-of-string.patch
+rapidio-replace-select-dmaengines-with-depends-on.patch
+cifs-fix-dfs-mount-with-cifsacl-modefromsid.patch
+openrisc-fix-cache-api-compile-issue-when-not-inlini.patch
+nvme-fc-cancel-async-events-before-freeing-event-str.patch
+nvme-rdma-cancel-async-events-before-freeing-event-s.patch
+nvme-tcp-cancel-async-events-before-freeing-event-st.patch
+block-only-call-sched-requeue_request-for-scheduled-.patch
+f2fs-fix-indefinite-loop-scanning-for-free-nid.patch
+f2fs-return-eof-on-unaligned-end-of-file-dio-read.patch
+i2c-algo-pca-reapply-i2c-bus-settings-after-reset.patch
+spi-fix-memory-leak-on-splited-transfers.patch
+kvm-mips-change-the-definition-of-kvm-type.patch
+clk-davinci-use-the-correct-size-when-allocating-mem.patch
+clk-rockchip-fix-initialization-of-mux_pll_src_4plls.patch
+asoc-qcom-set-card-owner-to-avoid-warnings.patch
+asoc-qcom-common-fix-refcount-imbalance-on-error.patch
+powerpc-book3s64-radix-fix-boot-failure-with-large-a.patch
+asoc-meson-axg-toddr-fix-channel-order-on-g12-platfo.patch
+drivers-hv-vmbus-hibernation-do-not-hang-forever-in-.patch
+scsi-libsas-fix-error-path-in-sas_notify_lldd_dev_fo.patch
+arm64-allow-cpus-unffected-by-arm-erratum-1418040-to.patch
+drivers-hv-vmbus-add-timeout-to-vmbus_wait_for_unloa.patch
+perf-test-fix-the-signal-test-inline-assembly.patch
+mips-sni-fix-mips_l1_cache_shift.patch
+perf-evlist-fix-cpu-thread-map-leak.patch
+perf-parse-event-fix-memory-leak-in-evsel-unit.patch
+perf-test-free-formats-for-perf-pmu-parse-test.patch
+fbcon-fix-user-font-detection-test-at-fbcon_resize.patch
+mips-sni-fix-spurious-interrupts.patch
+drm-mediatek-add-exception-handing-in-mtk_drm_probe-.patch
+drm-mediatek-add-missing-put_device-call-in-mtk_hdmi.patch
+arm64-bpf-fix-branch-offset-in-jit.patch
+iommu-amd-fix-potential-entry-null-deref.patch
+i2c-mxs-use-mxs_dma_ctrl_wait4end-instead-of-dma_ctr.patch
+riscv-add-sfence.vma-after-early-page-table-changes.patch
--- /dev/null
+From ee050de9deb685b08a2f7ed28d9941f0e9e49987 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Sep 2020 17:11:29 +0200
+Subject: spi: Fix memory leak on splited transfers
+
+From: Gustav Wiklander <gustavwi@axis.com>
+
+[ Upstream commit b59a7ca15464c78ea1ba3b280cfc5ac5ece11ade ]
+
+In the prepare_message callback the bus driver has the
+opportunity to split a transfer into smaller chunks.
+spi_map_msg is done after prepare_message.
+
+Function spi_res_release releases the splited transfers
+in the message. Therefore spi_res_release should be called
+after spi_map_msg.
+
+The previous try at this was commit c9ba7a16d0f1
+which released the splited transfers after
+spi_finalize_current_message had been called.
+This introduced a race since the message struct could be
+out of scope because the spi_sync call got completed.
+
+Fixes this leak on spi bus driver spi-bcm2835.c when transfer
+size is greater than 65532:
+
+Kmemleak:
+sg_alloc_table+0x28/0xc8
+spi_map_buf+0xa4/0x300
+__spi_pump_messages+0x370/0x748
+__spi_sync+0x1d4/0x270
+spi_sync+0x34/0x58
+spi_test_execute_msg+0x60/0x340 [spi_loopback_test]
+spi_test_run_iter+0x548/0x578 [spi_loopback_test]
+spi_test_run_test+0x94/0x140 [spi_loopback_test]
+spi_test_run_tests+0x150/0x180 [spi_loopback_test]
+spi_loopback_test_probe+0x50/0xd0 [spi_loopback_test]
+spi_drv_probe+0x84/0xe0
+
+Signed-off-by: Gustav Wiklander <gustavwi@axis.com>
+Link: https://lore.kernel.org/r/20200908151129.15915-1-gustav.wiklander@axis.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
+index 6a81b2a33cb4b..982753ac1bf6c 100644
+--- a/drivers/spi/spi.c
++++ b/drivers/spi/spi.c
+@@ -1241,8 +1241,6 @@ out:
+ if (msg->status && ctlr->handle_err)
+ ctlr->handle_err(ctlr, msg);
+
+- spi_res_release(ctlr, msg);
+-
+ spi_finalize_current_message(ctlr);
+
+ return ret;
+@@ -1525,6 +1523,13 @@ void spi_finalize_current_message(struct spi_controller *ctlr)
+
+ spi_unmap_msg(ctlr, mesg);
+
++ /* In the prepare_messages callback the spi bus has the opportunity to
++ * split a transfer to smaller chunks.
++ * Release splited transfers here since spi_map_msg is done on the
++ * splited transfers.
++ */
++ spi_res_release(ctlr, mesg);
++
+ if (ctlr->cur_msg_prepared && ctlr->unprepare_message) {
+ ret = ctlr->unprepare_message(ctlr, mesg);
+ if (ret) {
+--
+2.25.1
+
--- /dev/null
+From 7218a23abe713719a62a84857fb9084366a72043 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Sep 2020 15:23:41 +0200
+Subject: spi: spi-loopback-test: Fix out-of-bounds read
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ Upstream commit 837ba18dfcd4db21ad58107c65bfe89753aa56d7 ]
+
+The "tx/rx-transfer - crossing PAGE_SIZE" test always fails when
+len=131071 and rx_offset >= 5:
+
+ spi-loopback-test spi0.0: Running test tx/rx-transfer - crossing PAGE_SIZE
+ ...
+ with iteration values: len = 131071, tx_off = 0, rx_off = 3
+ with iteration values: len = 131071, tx_off = 0, rx_off = 4
+ with iteration values: len = 131071, tx_off = 0, rx_off = 5
+ loopback strangeness - rx changed outside of allowed range at: ...a4321000
+ spi_msg@ffffffd5a4157690
+ frame_length: 131071
+ actual_length: 131071
+ spi_transfer@ffffffd5a41576f8
+ len: 131071
+ tx_buf: ffffffd5a4340ffc
+
+Note that rx_offset > 3 can only occur if the SPI controller driver sets
+->dma_alignment to a higher value than 4, so most SPI controller drivers
+are not affect.
+
+The allocated Rx buffer is of size SPI_TEST_MAX_SIZE_PLUS, which is 132
+KiB (assuming 4 KiB pages). This test uses an initial offset into the
+rx_buf of PAGE_SIZE - 4, and a len of 131071, so the range expected to
+be written in this transfer ends at (4096 - 4) + 5 + 131071 == 132 KiB,
+which is also the end of the allocated buffer. But the code which
+verifies the content of the buffer reads a byte beyond the allocated
+buffer and spuriously fails because this out-of-bounds read doesn't
+return the expected value.
+
+Fix this by using ITERATE_LEN instead of ITERATE_MAX_LEN to avoid
+testing sizes which cause out-of-bounds reads.
+
+Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Link: https://lore.kernel.org/r/20200902132341.7079-1-vincent.whitchurch@axis.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-loopback-test.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
+index 6f18d49527673..51633b2b64371 100644
+--- a/drivers/spi/spi-loopback-test.c
++++ b/drivers/spi/spi-loopback-test.c
+@@ -90,7 +90,7 @@ static struct spi_test spi_tests[] = {
+ {
+ .description = "tx/rx-transfer - crossing PAGE_SIZE",
+ .fill_option = FILL_COUNT_8,
+- .iterate_len = { ITERATE_MAX_LEN },
++ .iterate_len = { ITERATE_LEN },
+ .iterate_tx_align = ITERATE_ALIGN,
+ .iterate_rx_align = ITERATE_ALIGN,
+ .transfer_count = 1,
+--
+2.25.1
+
--- /dev/null
+From 9a932b687d48745294814adbd3d24365ddcba370 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 5 Sep 2020 10:03:26 -0400
+Subject: SUNRPC: stop printk reading past end of string
+
+From: J. Bruce Fields <bfields@redhat.com>
+
+[ Upstream commit 8c6b6c793ed32b8f9770ebcdf1ba99af423c303b ]
+
+Since p points at raw xdr data, there's no guarantee that it's NULL
+terminated, so we should give a length. And probably escape any special
+characters too.
+
+Reported-by: Zhi Li <yieli@redhat.com>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sunrpc/rpcb_clnt.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
+index 4a020b6888608..1db9f62e466d9 100644
+--- a/net/sunrpc/rpcb_clnt.c
++++ b/net/sunrpc/rpcb_clnt.c
+@@ -988,8 +988,8 @@ static int rpcb_dec_getaddr(struct rpc_rqst *req, struct xdr_stream *xdr,
+ p = xdr_inline_decode(xdr, len);
+ if (unlikely(p == NULL))
+ goto out_fail;
+- dprintk("RPC: %5u RPCB_%s reply: %s\n", req->rq_task->tk_pid,
+- req->rq_task->tk_msg.rpc_proc->p_name, (char *)p);
++ dprintk("RPC: %5u RPCB_%s reply: %*pE\n", req->rq_task->tk_pid,
++ req->rq_task->tk_msg.rpc_proc->p_name, len, (char *)p);
+
+ if (rpc_uaddr2sockaddr(req->rq_xprt->xprt_net, (char *)p, len,
+ sap, sizeof(address)) == 0)
+--
+2.25.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
