--- /dev/null
+From e5bcaaa0b887dcb6cb9d253bbb57584d1cbc42b5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Jun 2022 09:09:43 +0100
+Subject: arm64: ftrace: consistently handle PLTs.
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+[ Upstream commit a6253579977e4c6f7818eeb05bf2bc65678a7187 ]
+
+Sometimes it is necessary to use a PLT entry to call an ftrace
+trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(),
+with each having *almost* identical logic, but this is not handled by
+ftrace_modify_call() since its introduction in commit:
+
+ 3b23e4991fb66f6d ("arm64: implement ftrace with regs")
+
+Due to this, if we ever were to call ftrace_modify_call() for a callsite
+which requires a PLT entry for a trampoline, then either:
+
+a) If the old addr requires a trampoline, ftrace_modify_call() will use
+ an out-of-range address to generate the 'old' branch instruction.
+ This will result in warnings from aarch64_insn_gen_branch_imm() and
+ ftrace_modify_code(), and no instructions will be modified. As
+ ftrace_modify_call() will return an error, this will result in
+ subsequent internal ftrace errors.
+
+b) If the old addr does not require a trampoline, but the new addr does,
+ ftrace_modify_call() will use an out-of-range address to generate the
+ 'new' branch instruction. This will result in warnings from
+ aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace
+ the 'old' branch with a BRK. This will result in a kernel panic when
+ this BRK is later executed.
+
+Practically speaking, case (a) is vastly more likely than case (b), and
+typically this will result in internal ftrace errors that don't
+necessarily affect the rest of the system. This can be demonstrated with
+an out-of-tree test module which triggers ftrace_modify_call(), e.g.
+
+| # insmod test_ftrace.ko
+| test_ftrace: Function test_function raw=0xffffb3749399201c, callsite=0xffffb37493992024
+| branch_imm_common: offset out of range
+| branch_imm_common: offset out of range
+| ------------[ ftrace bug ]------------
+| ftrace failed to modify
+| [<ffffb37493992024>] test_function+0x8/0x38 [test_ftrace]
+| actual: 1d:00:00:94
+| Updating ftrace call site to call a different ftrace function
+| ftrace record flags: e0000002
+| (2) R
+| expected tramp: ffffb374ae42ed54
+| ------------[ cut here ]------------
+| WARNING: CPU: 0 PID: 165 at kernel/trace/ftrace.c:2085 ftrace_bug+0x280/0x2b0
+| Modules linked in: test_ftrace(+)
+| CPU: 0 PID: 165 Comm: insmod Not tainted 5.19.0-rc2-00002-g4d9ead8b45ce #13
+| Hardware name: linux,dummy-virt (DT)
+| pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+| pc : ftrace_bug+0x280/0x2b0
+| lr : ftrace_bug+0x280/0x2b0
+| sp : ffff80000839ba00
+| x29: ffff80000839ba00 x28: 0000000000000000 x27: ffff80000839bcf0
+| x26: ffffb37493994180 x25: ffffb374b0991c28 x24: ffffb374b0d70000
+| x23: 00000000ffffffea x22: ffffb374afcc33b0 x21: ffffb374b08f9cc8
+| x20: ffff572b8462c000 x19: ffffb374b08f9000 x18: ffffffffffffffff
+| x17: 6c6c6163202c6331 x16: ffffb374ae5ad110 x15: ffffb374b0d51ee4
+| x14: 0000000000000000 x13: 3435646532346561 x12: 3437336266666666
+| x11: 203a706d61727420 x10: 6465746365707865 x9 : ffffb374ae5149e8
+| x8 : 336266666666203a x7 : 706d617274206465 x6 : 00000000fffff167
+| x5 : ffff572bffbc4a08 x4 : 00000000fffff167 x3 : 0000000000000000
+| x2 : 0000000000000000 x1 : ffff572b84461e00 x0 : 0000000000000022
+| Call trace:
+| ftrace_bug+0x280/0x2b0
+| ftrace_replace_code+0x98/0xa0
+| ftrace_modify_all_code+0xe0/0x144
+| arch_ftrace_update_code+0x14/0x20
+| ftrace_startup+0xf8/0x1b0
+| register_ftrace_function+0x38/0x90
+| test_ftrace_init+0xd0/0x1000 [test_ftrace]
+| do_one_initcall+0x50/0x2b0
+| do_init_module+0x50/0x1f0
+| load_module+0x17c8/0x1d64
+| __do_sys_finit_module+0xa8/0x100
+| __arm64_sys_finit_module+0x2c/0x3c
+| invoke_syscall+0x50/0x120
+| el0_svc_common.constprop.0+0xdc/0x100
+| do_el0_svc+0x3c/0xd0
+| el0_svc+0x34/0xb0
+| el0t_64_sync_handler+0xbc/0x140
+| el0t_64_sync+0x18c/0x190
+| ---[ end trace 0000000000000000 ]---
+
+We can solve this by consistently determining whether to use a PLT entry
+for an address.
+
+Note that since (the earlier) commit:
+
+ f1a54ae9af0da4d7 ("arm64: module/ftrace: intialize PLT at load time")
+
+... we can consistently determine the PLT address that a given callsite
+will use, and therefore ftrace_make_nop() does not need to skip
+validation when a PLT is in use.
+
+This patch factors the existing logic out of ftrace_make_call() and
+ftrace_make_nop() into a common ftrace_find_callable_addr() helper
+function, which is used by ftrace_make_call(), ftrace_make_nop(), and
+ftrace_modify_call(). In ftrace_make_nop() the patching is consistently
+validated by ftrace_modify_code() as we can always determine what the
+old instruction should have been.
+
+Fixes: 3b23e4991fb6 ("arm64: implement ftrace with regs")
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Cc: Ard Biesheuvel <ardb@kernel.org>
+Cc: Will Deacon <will@kernel.org>
+Tested-by: "Ivan T. Ivanov" <iivanov@suse.de>
+Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20220614080944.1349146-3-mark.rutland@arm.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/ftrace.c | 137 ++++++++++++++++++-------------------
+ 1 file changed, 66 insertions(+), 71 deletions(-)
+
+diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
+index d9e3eda419ec..f3184cd81b19 100644
+--- a/arch/arm64/kernel/ftrace.c
++++ b/arch/arm64/kernel/ftrace.c
+@@ -78,47 +78,76 @@ static struct plt_entry *get_ftrace_plt(struct module *mod, unsigned long addr)
+ }
+
+ /*
+- * Turn on the call to ftrace_caller() in instrumented function
++ * Find the address the callsite must branch to in order to reach '*addr'.
++ *
++ * Due to the limited range of 'BL' instructions, modules may be placed too far
++ * away to branch directly and must use a PLT.
++ *
++ * Returns true when '*addr' contains a reachable target address, or has been
++ * modified to contain a PLT address. Returns false otherwise.
+ */
+-int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
++static bool ftrace_find_callable_addr(struct dyn_ftrace *rec,
++ struct module *mod,
++ unsigned long *addr)
+ {
+ unsigned long pc = rec->ip;
+- u32 old, new;
+- long offset = (long)addr - (long)pc;
++ long offset = (long)*addr - (long)pc;
++ struct plt_entry *plt;
+
+- if (offset < -SZ_128M || offset >= SZ_128M) {
+- struct module *mod;
+- struct plt_entry *plt;
++ /*
++ * When the target is within range of the 'BL' instruction, use 'addr'
++ * as-is and branch to that directly.
++ */
++ if (offset >= -SZ_128M && offset < SZ_128M)
++ return true;
+
+- if (!IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
+- return -EINVAL;
++ /*
++ * When the target is outside of the range of a 'BL' instruction, we
++ * must use a PLT to reach it. We can only place PLTs for modules, and
++ * only when module PLT support is built-in.
++ */
++ if (!IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
++ return false;
+
+- /*
+- * On kernels that support module PLTs, the offset between the
+- * branch instruction and its target may legally exceed the
+- * range of an ordinary relative 'bl' opcode. In this case, we
+- * need to branch via a trampoline in the module.
+- *
+- * NOTE: __module_text_address() must be called with preemption
+- * disabled, but we can rely on ftrace_lock to ensure that 'mod'
+- * retains its validity throughout the remainder of this code.
+- */
++ /*
++ * 'mod' is only set at module load time, but if we end up
++ * dealing with an out-of-range condition, we can assume it
++ * is due to a module being loaded far away from the kernel.
++ *
++ * NOTE: __module_text_address() must be called with preemption
++ * disabled, but we can rely on ftrace_lock to ensure that 'mod'
++ * retains its validity throughout the remainder of this code.
++ */
++ if (!mod) {
+ preempt_disable();
+ mod = __module_text_address(pc);
+ preempt_enable();
++ }
+
+- if (WARN_ON(!mod))
+- return -EINVAL;
++ if (WARN_ON(!mod))
++ return false;
+
+- plt = get_ftrace_plt(mod, addr);
+- if (!plt) {
+- pr_err("ftrace: no module PLT for %ps\n", (void *)addr);
+- return -EINVAL;
+- }
+-
+- addr = (unsigned long)plt;
++ plt = get_ftrace_plt(mod, *addr);
++ if (!plt) {
++ pr_err("ftrace: no module PLT for %ps\n", (void *)*addr);
++ return false;
+ }
+
++ *addr = (unsigned long)plt;
++ return true;
++}
++
++/*
++ * Turn on the call to ftrace_caller() in instrumented function
++ */
++int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
++{
++ unsigned long pc = rec->ip;
++ u32 old, new;
++
++ if (!ftrace_find_callable_addr(rec, NULL, &addr))
++ return -EINVAL;
++
+ old = aarch64_insn_gen_nop();
+ new = aarch64_insn_gen_branch_imm(pc, addr, AARCH64_INSN_BRANCH_LINK);
+
+@@ -132,6 +161,11 @@ int ftrace_modify_call(struct dyn_ftrace *rec, unsigned long old_addr,
+ unsigned long pc = rec->ip;
+ u32 old, new;
+
++ if (!ftrace_find_callable_addr(rec, NULL, &old_addr))
++ return -EINVAL;
++ if (!ftrace_find_callable_addr(rec, NULL, &addr))
++ return -EINVAL;
++
+ old = aarch64_insn_gen_branch_imm(pc, old_addr,
+ AARCH64_INSN_BRANCH_LINK);
+ new = aarch64_insn_gen_branch_imm(pc, addr, AARCH64_INSN_BRANCH_LINK);
+@@ -181,54 +215,15 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
+ unsigned long addr)
+ {
+ unsigned long pc = rec->ip;
+- bool validate = true;
+ u32 old = 0, new;
+- long offset = (long)addr - (long)pc;
+
+- if (offset < -SZ_128M || offset >= SZ_128M) {
+- u32 replaced;
+-
+- if (!IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
+- return -EINVAL;
+-
+- /*
+- * 'mod' is only set at module load time, but if we end up
+- * dealing with an out-of-range condition, we can assume it
+- * is due to a module being loaded far away from the kernel.
+- */
+- if (!mod) {
+- preempt_disable();
+- mod = __module_text_address(pc);
+- preempt_enable();
+-
+- if (WARN_ON(!mod))
+- return -EINVAL;
+- }
+-
+- /*
+- * The instruction we are about to patch may be a branch and
+- * link instruction that was redirected via a PLT entry. In
+- * this case, the normal validation will fail, but we can at
+- * least check that we are dealing with a branch and link
+- * instruction that points into the right module.
+- */
+- if (aarch64_insn_read((void *)pc, &replaced))
+- return -EFAULT;
+-
+- if (!aarch64_insn_is_bl(replaced) ||
+- !within_module(pc + aarch64_get_branch_offset(replaced),
+- mod))
+- return -EINVAL;
+-
+- validate = false;
+- } else {
+- old = aarch64_insn_gen_branch_imm(pc, addr,
+- AARCH64_INSN_BRANCH_LINK);
+- }
++ if (!ftrace_find_callable_addr(rec, mod, &addr))
++ return -EINVAL;
+
++ old = aarch64_insn_gen_branch_imm(pc, addr, AARCH64_INSN_BRANCH_LINK);
+ new = aarch64_insn_gen_nop();
+
+- return ftrace_modify_code(pc, old, new, validate);
++ return ftrace_modify_code(pc, old, new, true);
+ }
+
+ void arch_ftrace_update_code(int command)
+--
+2.35.1
+
--- /dev/null
+From 69ca76f9d0ce71230973d4b2666aac77e3b77fa3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Jun 2022 09:09:42 +0100
+Subject: arm64: ftrace: fix branch range checks
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+[ Upstream commit 3eefdf9d1e406f3da47470b2854347009ffcb6fa ]
+
+The branch range checks in ftrace_make_call() and ftrace_make_nop() are
+incorrect, erroneously permitting a forwards branch of 128M and
+erroneously rejecting a backwards branch of 128M.
+
+This is because both functions calculate the offset backwards,
+calculating the offset *from* the target *to* the branch, rather than
+the other way around as the later comparisons expect.
+
+If an out-of-range branch were erroeously permitted, this would later be
+rejected by aarch64_insn_gen_branch_imm() as branch_imm_common() checks
+the bounds correctly, resulting in warnings and the placement of a BRK
+instruction. Note that this can only happen for a forwards branch of
+exactly 128M, and so the caller would need to be exactly 128M bytes
+below the relevant ftrace trampoline.
+
+If an in-range branch were erroeously rejected, then:
+
+* For modules when CONFIG_ARM64_MODULE_PLTS=y, this would result in the
+ use of a PLT entry, which is benign.
+
+ Note that this is the common case, as this is selected by
+ CONFIG_RANDOMIZE_BASE (and therefore RANDOMIZE_MODULE_REGION_FULL),
+ which distributions typically seelct. This is also selected by
+ CONFIG_ARM64_ERRATUM_843419.
+
+* For modules when CONFIG_ARM64_MODULE_PLTS=n, this would result in
+ internal ftrace failures.
+
+* For core kernel text, this would result in internal ftrace failues.
+
+ Note that for this to happen, the kernel text would need to be at
+ least 128M bytes in size, and typical configurations are smaller tha
+ this.
+
+Fix this by calculating the offset *from* the branch *to* the target in
+both functions.
+
+Fixes: f8af0b364e24 ("arm64: ftrace: don't validate branch via PLT in ftrace_make_nop()")
+Fixes: e71a4e1bebaf ("arm64: ftrace: add support for far branches to dynamic ftrace")
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Cc: Ard Biesheuvel <ardb@kernel.org>
+Cc: Will Deacon <will@kernel.org>
+Tested-by: "Ivan T. Ivanov" <iivanov@suse.de>
+Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20220614080944.1349146-2-mark.rutland@arm.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kernel/ftrace.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
+index 4506c4a90ac1..d9e3eda419ec 100644
+--- a/arch/arm64/kernel/ftrace.c
++++ b/arch/arm64/kernel/ftrace.c
+@@ -84,7 +84,7 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
+ {
+ unsigned long pc = rec->ip;
+ u32 old, new;
+- long offset = (long)pc - (long)addr;
++ long offset = (long)addr - (long)pc;
+
+ if (offset < -SZ_128M || offset >= SZ_128M) {
+ struct module *mod;
+@@ -183,7 +183,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
+ unsigned long pc = rec->ip;
+ bool validate = true;
+ u32 old = 0, new;
+- long offset = (long)pc - (long)addr;
++ long offset = (long)addr - (long)pc;
+
+ if (offset < -SZ_128M || offset >= SZ_128M) {
+ u32 replaced;
+--
+2.35.1
+
--- /dev/null
+From b2b600b112a7e7996b24c1afbde386a6e84d545e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Jun 2022 14:00:04 -0700
+Subject: block: Fix handling of offline queues in blk_mq_alloc_request_hctx()
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit 14dc7a18abbe4176f5626c13c333670da8e06aa1 ]
+
+This patch prevents that test nvme/004 triggers the following:
+
+UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9
+index 512 is out of range for type 'long unsigned int [512]'
+Call Trace:
+ show_stack+0x52/0x58
+ dump_stack_lvl+0x49/0x5e
+ dump_stack+0x10/0x12
+ ubsan_epilogue+0x9/0x3b
+ __ubsan_handle_out_of_bounds.cold+0x44/0x49
+ blk_mq_alloc_request_hctx+0x304/0x310
+ __nvme_submit_sync_cmd+0x70/0x200 [nvme_core]
+ nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics]
+ nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop]
+ nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop]
+ nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics]
+ nvmf_dev_write+0xae/0x111 [nvme_fabrics]
+ vfs_write+0x144/0x560
+ ksys_write+0xb7/0x140
+ __x64_sys_write+0x42/0x50
+ do_syscall_64+0x35/0x80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Ming Lei <ming.lei@redhat.com>
+Fixes: 20e4d8139319 ("blk-mq: simplify queue mapping & schedule with each possisble CPU")
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Link: https://lore.kernel.org/r/20220615210004.1031820-1-bvanassche@acm.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-mq.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/block/blk-mq.c b/block/blk-mq.c
+index f18e1c9c3f4a..bef60ba8ef6b 100644
+--- a/block/blk-mq.c
++++ b/block/blk-mq.c
+@@ -578,6 +578,8 @@ struct request *blk_mq_alloc_request_hctx(struct request_queue *q,
+ if (!blk_mq_hw_queue_mapped(data.hctx))
+ goto out_queue_exit;
+ cpu = cpumask_first_and(data.hctx->cpumask, cpu_online_mask);
++ if (cpu >= nr_cpu_ids)
++ goto out_queue_exit;
+ data.ctx = __blk_mq_get_ctx(q, cpu);
+
+ if (!q->elevator)
+--
+2.35.1
+
--- /dev/null
+From f38c71bffd545bf39d5d6eb4ff4a520080323bf0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 12 Jun 2022 02:22:30 +0900
+Subject: certs/blacklist_hashes.c: fix const confusion in certs blacklist
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Masahiro Yamada <masahiroy@kernel.org>
+
+[ Upstream commit 6a1c3767d82ed8233de1263aa7da81595e176087 ]
+
+This file fails to compile as follows:
+
+ CC certs/blacklist_hashes.o
+certs/blacklist_hashes.c:4:1: error: ignoring attribute ‘section (".init.data")’ because it conflicts with previous ‘section (".init.rodata")’ [-Werror=attributes]
+ 4 | const char __initdata *const blacklist_hashes[] = {
+ | ^~~~~
+In file included from certs/blacklist_hashes.c:2:
+certs/blacklist.h:5:38: note: previous declaration here
+ 5 | extern const char __initconst *const blacklist_hashes[];
+ | ^~~~~~~~~~~~~~~~
+
+Apply the same fix as commit 2be04df5668d ("certs/blacklist_nohashes.c:
+fix const confusion in certs blacklist").
+
+Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring")
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Reviewed-by: Mickaël Salaün <mic@linux.microsoft.com>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ certs/blacklist_hashes.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/certs/blacklist_hashes.c b/certs/blacklist_hashes.c
+index 344892337be0..d5961aa3d338 100644
+--- a/certs/blacklist_hashes.c
++++ b/certs/blacklist_hashes.c
+@@ -1,7 +1,7 @@
+ // SPDX-License-Identifier: GPL-2.0
+ #include "blacklist.h"
+
+-const char __initdata *const blacklist_hashes[] = {
++const char __initconst *const blacklist_hashes[] = {
+ #include CONFIG_SYSTEM_BLACKLIST_HASH_LIST
+ , NULL
+ };
+--
+2.35.1
+
--- /dev/null
+From 2a47390b6282e620e525c3faab09b866bb001bfc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 6 Jun 2022 14:02:38 +0900
+Subject: clocksource: hyper-v: unexport __init-annotated hv_init_clocksource()
+
+From: Masahiro Yamada <masahiroy@kernel.org>
+
+[ Upstream commit 245b993d8f6c4e25f19191edfbd8080b645e12b1 ]
+
+EXPORT_SYMBOL and __init is a bad combination because the .init.text
+section is freed up after the initialization. Hence, modules cannot
+use symbols annotated __init. The access to a freed symbol may end up
+with kernel panic.
+
+modpost used to detect it, but it has been broken for a decade.
+
+Recently, I fixed modpost so it started to warn it again, then this
+showed up in linux-next builds.
+
+There are two ways to fix it:
+
+ - Remove __init
+ - Remove EXPORT_SYMBOL
+
+I chose the latter for this case because the only in-tree call-site,
+arch/x86/kernel/cpu/mshyperv.c is never compiled as modular.
+(CONFIG_HYPERVISOR_GUEST is boolean)
+
+Fixes: dd2cb348613b ("clocksource/drivers: Continue making Hyper-V clocksource ISA agnostic")
+Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/20220606050238.4162200-1-masahiroy@kernel.org
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clocksource/hyperv_timer.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
+index ff188ab68496..bb47610bbd1c 100644
+--- a/drivers/clocksource/hyperv_timer.c
++++ b/drivers/clocksource/hyperv_timer.c
+@@ -565,4 +565,3 @@ void __init hv_init_clocksource(void)
+ hv_sched_clock_offset = hv_read_reference_counter();
+ hv_setup_sched_clock(read_hv_sched_clock_msr);
+ }
+-EXPORT_SYMBOL_GPL(hv_init_clocksource);
+--
+2.35.1
+
--- /dev/null
+From 7c4614522bd7bc4645e7d59957f5c443e2c4ad34 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 9 Jun 2022 10:16:36 -0700
+Subject: Drivers: hv: vmbus: Release cpu lock in error case
+
+From: Saurabh Sengar <ssengar@linux.microsoft.com>
+
+[ Upstream commit 656c5ba50b7172a0ea25dc1b37606bd51d01fe8d ]
+
+In case of invalid sub channel, release cpu lock before returning.
+
+Fixes: a949e86c0d780 ("Drivers: hv: vmbus: Resolve race between init_vp_index() and CPU hotplug")
+Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/1654794996-13244-1-git-send-email-ssengar@linux.microsoft.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hv/channel_mgmt.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
+index 67be81208a2d..3a4dae1f5e9c 100644
+--- a/drivers/hv/channel_mgmt.c
++++ b/drivers/hv/channel_mgmt.c
+@@ -637,6 +637,7 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
+ */
+ if (newchannel->offermsg.offer.sub_channel_index == 0) {
+ mutex_unlock(&vmbus_connection.channel_mutex);
++ cpus_read_unlock();
+ /*
+ * Don't call free_channel(), because newchannel->kobj
+ * is not initialized yet.
+--
+2.35.1
+
--- /dev/null
+From b133c2c2bb2bdf24cb83b798a228f42bb38339a0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Mar 2022 16:43:11 -0800
+Subject: drm/i915/reset: Fix error_state_read ptr + offset use
+
+From: Alan Previn <alan.previn.teres.alexis@intel.com>
+
+[ Upstream commit c9b576d0c7bf55aeae1a736da7974fa202c4394d ]
+
+Fix our pointer offset usage in error_state_read
+when there is no i915_gpu_coredump but buf offset
+is non-zero.
+
+This fixes a kernel page fault can happen when
+multiple tests are running concurrently in a loop
+and one is producing engine resets and consuming
+the i915 error_state dump while the other is
+forcing full GT resets. (takes a while to trigger).
+
+The dmesg call trace:
+
+[ 5590.803000] BUG: unable to handle page fault for address:
+ ffffffffa0b0e000
+[ 5590.803009] #PF: supervisor read access in kernel mode
+[ 5590.803013] #PF: error_code(0x0000) - not-present page
+[ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067
+ PTE 0
+[ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI
+[ 5590.803026] CPU: 5 PID: 13656 Comm: i915_hangman Tainted: G U
+ 5.17.0-rc5-ups69-guc-err-capt-rev6+ #136
+[ 5590.803033] Hardware name: Intel Corporation Alder Lake Client
+ Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00.
+ 3031.A02.2201171222 01/17/2022
+[ 5590.803039] RIP: 0010:memcpy_erms+0x6/0x10
+[ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1
+ 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3
+ 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4
+ c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20
+ 72 7e 40 38 fe
+[ 5590.803054] RSP: 0018:ffffc90003a8fdf0 EFLAGS: 00010282
+[ 5590.803057] RAX: ffff888107ee9000 RBX: ffff888108cb1a00
+ RCX: 0000000000000f8f
+[ 5590.803061] RDX: 0000000000001000 RSI: ffffffffa0b0e000
+ RDI: ffff888107ee9071
+[ 5590.803065] RBP: 0000000000000000 R08: 0000000000000001
+ R09: 0000000000000001
+[ 5590.803069] R10: 0000000000000001 R11: 0000000000000002
+ R12: 0000000000000019
+[ 5590.803073] R13: 0000000000174fff R14: 0000000000001000
+ R15: ffff888107ee9000
+[ 5590.803077] FS: 00007f62a99bee80(0000) GS:ffff88849f880000(0000)
+ knlGS:0000000000000000
+[ 5590.803082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 5590.803085] CR2: ffffffffa0b0e000 CR3: 000000010a1a8004
+ CR4: 0000000000770ee0
+[ 5590.803089] PKRU: 55555554
+[ 5590.803091] Call Trace:
+[ 5590.803093] <TASK>
+[ 5590.803096] error_state_read+0xa1/0xd0 [i915]
+[ 5590.803175] kernfs_fop_read_iter+0xb2/0x1b0
+[ 5590.803180] new_sync_read+0x116/0x1a0
+[ 5590.803185] vfs_read+0x114/0x1b0
+[ 5590.803189] ksys_read+0x63/0xe0
+[ 5590.803193] do_syscall_64+0x38/0xc0
+[ 5590.803197] entry_SYSCALL_64_after_hwframe+0x44/0xae
+[ 5590.803201] RIP: 0033:0x7f62aaea5912
+[ 5590.803204] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 5a b9 0c 00 e8 05
+ 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25
+ 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff
+ ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
+[ 5590.803213] RSP: 002b:00007fff5b659ae8 EFLAGS: 00000246
+ ORIG_RAX: 0000000000000000
+[ 5590.803218] RAX: ffffffffffffffda RBX: 0000000000100000
+ RCX: 00007f62aaea5912
+[ 5590.803221] RDX: 000000000008b000 RSI: 00007f62a8c4000f
+ RDI: 0000000000000006
+[ 5590.803225] RBP: 00007f62a8bcb00f R08: 0000000000200010
+ R09: 0000000000101000
+[ 5590.803229] R10: 0000000000000001 R11: 0000000000000246
+ R12: 0000000000000006
+[ 5590.803233] R13: 0000000000075000 R14: 00007f62a8acb010
+ R15: 0000000000200000
+[ 5590.803238] </TASK>
+[ 5590.803240] Modules linked in: i915 ttm drm_buddy drm_dp_helper
+ drm_kms_helper syscopyarea sysfillrect sysimgblt
+ fb_sys_fops prime_numbers nfnetlink br_netfilter
+ overlay mei_pxp mei_hdcp x86_pkg_temp_thermal
+ coretemp kvm_intel snd_hda_codec_hdmi snd_hda_intel
+ snd_intel_dspcfg snd_hda_codec snd_hwdep
+ snd_hda_core snd_pcm mei_me mei fuse ip_tables
+ x_tables crct10dif_pclmul e1000e crc32_pclmul ptp
+ i2c_i801 ghash_clmulni_intel i2c_smbus pps_core
+ [last unloa ded: ttm]
+[ 5590.803277] CR2: ffffffffa0b0e000
+[ 5590.803280] ---[ end trace 0000000000000000 ]---
+
+Fixes: 0e39037b3165 ("drm/i915: Cache the error string")
+Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
+Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
+Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220311004311.514198-2-alan.previn.teres.alexis@intel.com
+(cherry picked from commit 3304033a1e69cd81a2044b4422f0d7e593afb4e6)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/i915/i915_sysfs.c | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/i915_sysfs.c b/drivers/gpu/drm/i915/i915_sysfs.c
+index fae4d1f4f275..d34a70d0f56d 100644
+--- a/drivers/gpu/drm/i915/i915_sysfs.c
++++ b/drivers/gpu/drm/i915/i915_sysfs.c
+@@ -431,7 +431,14 @@ static ssize_t error_state_read(struct file *filp, struct kobject *kobj,
+ struct device *kdev = kobj_to_dev(kobj);
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+ struct i915_gpu_coredump *gpu;
+- ssize_t ret;
++ ssize_t ret = 0;
++
++ /*
++ * FIXME: Concurrent clients triggering resets and reading + clearing
++ * dumps can cause inconsistent sysfs reads when a user calls in with a
++ * non-zero offset to complete a prior partial read but the
++ * gpu_coredump has been cleared or replaced.
++ */
+
+ gpu = i915_first_error_state(i915);
+ if (IS_ERR(gpu)) {
+@@ -443,8 +450,10 @@ static ssize_t error_state_read(struct file *filp, struct kobject *kobj,
+ const char *str = "No error state collected\n";
+ size_t len = strlen(str);
+
+- ret = min_t(size_t, count, len - off);
+- memcpy(buf, str + off, ret);
++ if (off < len) {
++ ret = min_t(size_t, count, len - off);
++ memcpy(buf, str + off, ret);
++ }
+ }
+
+ return ret;
+--
+2.35.1
+
--- /dev/null
+From a414a19d52cb48bfb114e18956c313be850d252e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 Apr 2022 14:27:08 +0200
+Subject: i40e: Fix adding ADQ filter to TC0
+
+From: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
+
+[ Upstream commit c3238d36c3a2be0a29a9d848d6c51e1b14be6692 ]
+
+Procedure of configure tc flower filters erroneously allows to create
+filters on TC0 where unfiltered packets are also directed by default.
+Issue was caused by insufficient checks of hw_tc parameter specifying
+the hardware traffic class to pass matching packets to.
+
+Fix checking hw_tc parameter which blocks creation of filters on TC0.
+
+Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower")
+Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
+Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_main.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
+index 313a798fe3a9..cb8ab6a63d6d 100644
+--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
+@@ -8523,6 +8523,11 @@ static int i40e_configure_clsflower(struct i40e_vsi *vsi,
+ return -EOPNOTSUPP;
+ }
+
++ if (!tc) {
++ dev_err(&pf->pdev->dev, "Unable to add filter because of invalid destination");
++ return -EINVAL;
++ }
++
+ if (test_bit(__I40E_RESET_RECOVERY_PENDING, pf->state) ||
+ test_bit(__I40E_RESET_INTR_RECEIVED, pf->state))
+ return -EBUSY;
+--
+2.35.1
+
--- /dev/null
+From c7015fb8d12a0a2ab173c62f478ded55fea8c31b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 Apr 2022 14:40:23 +0200
+Subject: i40e: Fix calculating the number of queue pairs
+
+From: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
+
+[ Upstream commit 0bb050670ac90a167ecfa3f9590f92966c9a3677 ]
+
+If ADQ is enabled for a VF, then actual number of queue pair
+is a number of currently available traffic classes for this VF.
+
+Without this change the configuration of the Rx/Tx queues
+fails with error.
+
+Fixes: d29e0d233e0d ("i40e: missing input validation on VF message handling by the PF")
+Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
+Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+index 2606e8f0f19b..033ea71763e3 100644
+--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+@@ -2282,7 +2282,7 @@ static int i40e_vc_config_queues_msg(struct i40e_vf *vf, u8 *msg)
+ }
+
+ if (vf->adq_enabled) {
+- for (i = 0; i < I40E_MAX_VF_VSI; i++)
++ for (i = 0; i < vf->num_tc; i++)
+ num_qps_all += vf->ch[i].num_qps;
+ if (num_qps_all != qci->num_queue_pairs) {
+ aq_ret = I40E_ERR_PARAM;
+--
+2.35.1
+
--- /dev/null
+From 4fb3b8a256a525d61a5535f51fff3998a67f924c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 May 2022 16:01:45 +0200
+Subject: i40e: Fix call trace in setup_tx_descriptors
+
+From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+
+[ Upstream commit fd5855e6b1358e816710afee68a1d2bc685176ca ]
+
+After PF reset and ethtool -t there was call trace in dmesg
+sometimes leading to panic. When there was some time, around 5
+seconds, between reset and test there were no errors.
+
+Problem was that pf reset calls i40e_vsi_close in prep_for_reset
+and ethtool -t calls i40e_vsi_close in diag_test. If there was not
+enough time between those commands the second i40e_vsi_close starts
+before previous i40e_vsi_close was done which leads to crash.
+
+Add check to diag_test if pf is in reset and don't start offline
+tests if it is true.
+Add netif_info("testing failed") into unhappy path of i40e_diag_test()
+
+Fixes: e17bc411aea8 ("i40e: Disable offline diagnostics if VFs are enabled")
+Fixes: 510efb2682b3 ("i40e: Fix ethtool offline diagnostic with netqueues")
+Signed-off-by: Michal Jaron <michalx.jaron@intel.com>
+Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/intel/i40e/i40e_ethtool.c | 25 +++++++++++++------
+ 1 file changed, 17 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+index 091f36adbbe1..9f9b1817c479 100644
+--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+@@ -2580,15 +2580,16 @@ static void i40e_diag_test(struct net_device *netdev,
+
+ set_bit(__I40E_TESTING, pf->state);
+
++ if (test_bit(__I40E_RESET_RECOVERY_PENDING, pf->state) ||
++ test_bit(__I40E_RESET_INTR_RECEIVED, pf->state)) {
++ dev_warn(&pf->pdev->dev,
++ "Cannot start offline testing when PF is in reset state.\n");
++ goto skip_ol_tests;
++ }
++
+ if (i40e_active_vfs(pf) || i40e_active_vmdqs(pf)) {
+ dev_warn(&pf->pdev->dev,
+ "Please take active VFs and Netqueues offline and restart the adapter before running NIC diagnostics\n");
+- data[I40E_ETH_TEST_REG] = 1;
+- data[I40E_ETH_TEST_EEPROM] = 1;
+- data[I40E_ETH_TEST_INTR] = 1;
+- data[I40E_ETH_TEST_LINK] = 1;
+- eth_test->flags |= ETH_TEST_FL_FAILED;
+- clear_bit(__I40E_TESTING, pf->state);
+ goto skip_ol_tests;
+ }
+
+@@ -2635,9 +2636,17 @@ static void i40e_diag_test(struct net_device *netdev,
+ data[I40E_ETH_TEST_INTR] = 0;
+ }
+
+-skip_ol_tests:
+-
+ netif_info(pf, drv, netdev, "testing finished\n");
++ return;
++
++skip_ol_tests:
++ data[I40E_ETH_TEST_REG] = 1;
++ data[I40E_ETH_TEST_EEPROM] = 1;
++ data[I40E_ETH_TEST_INTR] = 1;
++ data[I40E_ETH_TEST_LINK] = 1;
++ eth_test->flags |= ETH_TEST_FL_FAILED;
++ clear_bit(__I40E_TESTING, pf->state);
++ netif_info(pf, drv, netdev, "testing failed\n");
+ }
+
+ static void i40e_get_wol(struct net_device *netdev,
+--
+2.35.1
+
--- /dev/null
+From 9df7dadd42aaa2eea30cfd1fe950a784ace3016e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 May 2022 13:03:43 +0200
+Subject: ice: Fix PTP TX timestamp offset calculation
+
+From: Michal Michalik <michal.michalik@intel.com>
+
+[ Upstream commit 71a579f0d3777a704355e6f1572dfba92a9b58b2 ]
+
+The offset was being incorrectly calculated for E822 - that led to
+collisions in choosing TX timestamp register location when more than
+one port was trying to use timestamping mechanism.
+
+In E822 one quad is being logically split between ports, so quad 0 is
+having trackers for ports 0-3, quad 1 ports 4-7 etc. Each port should
+have separate memory location for tracking timestamps. Due to error for
+example ports 1 and 2 had been assigned to quad 0 with same offset (0),
+while port 1 should have offset 0 and 1 offset 16.
+
+Fix it by correctly calculating quad offset.
+
+Fixes: 3a7496234d17 ("ice: implement basic E822 PTP support")
+Signed-off-by: Michal Michalik <michal.michalik@intel.com>
+Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ice/ice_ptp.c | 2 +-
+ drivers/net/ethernet/intel/ice/ice_ptp.h | 31 ++++++++++++++++++++++++
+ 2 files changed, 32 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
+index 836c67f1aa46..df7ce1f0213b 100644
+--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
++++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
+@@ -2263,7 +2263,7 @@ static int
+ ice_ptp_init_tx_e822(struct ice_pf *pf, struct ice_ptp_tx *tx, u8 port)
+ {
+ tx->quad = port / ICE_PORTS_PER_QUAD;
+- tx->quad_offset = tx->quad * INDEX_PER_PORT;
++ tx->quad_offset = (port % ICE_PORTS_PER_QUAD) * INDEX_PER_PORT;
+ tx->len = INDEX_PER_PORT;
+
+ return ice_ptp_alloc_tx_tracker(tx);
+diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.h b/drivers/net/ethernet/intel/ice/ice_ptp.h
+index afd048d69959..10e396abf130 100644
+--- a/drivers/net/ethernet/intel/ice/ice_ptp.h
++++ b/drivers/net/ethernet/intel/ice/ice_ptp.h
+@@ -49,6 +49,37 @@ struct ice_perout_channel {
+ * To allow multiple ports to access the shared register block independently,
+ * the blocks are split up so that indexes are assigned to each port based on
+ * hardware logical port number.
++ *
++ * The timestamp blocks are handled differently for E810- and E822-based
++ * devices. In E810 devices, each port has its own block of timestamps, while in
++ * E822 there is a need to logically break the block of registers into smaller
++ * chunks based on the port number to avoid collisions.
++ *
++ * Example for port 5 in E810:
++ * +--------+--------+--------+--------+--------+--------+--------+--------+
++ * |register|register|register|register|register|register|register|register|
++ * | block | block | block | block | block | block | block | block |
++ * | for | for | for | for | for | for | for | for |
++ * | port 0 | port 1 | port 2 | port 3 | port 4 | port 5 | port 6 | port 7 |
++ * +--------+--------+--------+--------+--------+--------+--------+--------+
++ * ^^
++ * ||
++ * |--- quad offset is always 0
++ * ---- quad number
++ *
++ * Example for port 5 in E822:
++ * +-----------------------------+-----------------------------+
++ * | register block for quad 0 | register block for quad 1 |
++ * |+------+------+------+------+|+------+------+------+------+|
++ * ||port 0|port 1|port 2|port 3|||port 0|port 1|port 2|port 3||
++ * |+------+------+------+------+|+------+------+------+------+|
++ * +-----------------------------+-------^---------------------+
++ * ^ |
++ * | --- quad offset*
++ * ---- quad number
++ *
++ * * PHY port 5 is port 1 in quad 1
++ *
+ */
+
+ /**
+--
+2.35.1
+
--- /dev/null
+From 0c00046fa2f46e8515ac306af28f9a6a3a0a4821 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 2 Jun 2022 12:09:04 +0200
+Subject: ice: Fix queue config fail handling
+
+From: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
+
+[ Upstream commit be2af71496a54a7195ac62caba6fab49cfe5006c ]
+
+Disable VF's RX/TX queues, when VIRTCHNL_OP_CONFIG_VSI_QUEUES fail.
+Not disabling them might lead to scenario, where PF driver leaves VF
+queues enabled, when VF's VSI failed queue config.
+In this scenario VF should not have RX/TX queues enabled. If PF failed
+to set up VF's queues, VF will reset due to TX timeouts in VF driver.
+Initialize iterator 'i' to -1, so if error happens prior to configuring
+queues then error path code will not disable queue 0. Loop that
+configures queues will is using same iterator, so error path code will
+only disable queues that were configured.
+
+Fixes: 77ca27c41705 ("ice: add support for virtchnl_queue_select.[tx|rx]_queues bitmap")
+Suggested-by: Slawomir Laba <slawomirx.laba@intel.com>
+Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
+Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
+Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/intel/ice/ice_virtchnl_pf.c | 53 +++++++++----------
+ 1 file changed, 26 insertions(+), 27 deletions(-)
+
+diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+index 0cc8b7e06b72..6ad5ff4c2ec0 100644
+--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
++++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+@@ -3580,35 +3580,27 @@ static int ice_vc_cfg_irq_map_msg(struct ice_vf *vf, u8 *msg)
+ */
+ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
+ {
+- enum virtchnl_status_code v_ret = VIRTCHNL_STATUS_SUCCESS;
+ struct virtchnl_vsi_queue_config_info *qci =
+ (struct virtchnl_vsi_queue_config_info *)msg;
+ struct virtchnl_queue_pair_info *qpi;
+ struct ice_pf *pf = vf->pf;
+ struct ice_vsi *vsi;
+- int i, q_idx;
++ int i = -1, q_idx;
+
+- if (!test_bit(ICE_VF_STATE_ACTIVE, vf->vf_states)) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ if (!test_bit(ICE_VF_STATE_ACTIVE, vf->vf_states))
+ goto error_param;
+- }
+
+- if (!ice_vc_isvalid_vsi_id(vf, qci->vsi_id)) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ if (!ice_vc_isvalid_vsi_id(vf, qci->vsi_id))
+ goto error_param;
+- }
+
+ vsi = ice_get_vf_vsi(vf);
+- if (!vsi) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ if (!vsi)
+ goto error_param;
+- }
+
+ if (qci->num_queue_pairs > ICE_MAX_RSS_QS_PER_VF ||
+ qci->num_queue_pairs > min_t(u16, vsi->alloc_txq, vsi->alloc_rxq)) {
+ dev_err(ice_pf_to_dev(pf), "VF-%d requesting more than supported number of queues: %d\n",
+ vf->vf_id, min_t(u16, vsi->alloc_txq, vsi->alloc_rxq));
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
+ goto error_param;
+ }
+
+@@ -3621,7 +3613,6 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
+ !ice_vc_isvalid_ring_len(qpi->txq.ring_len) ||
+ !ice_vc_isvalid_ring_len(qpi->rxq.ring_len) ||
+ !ice_vc_isvalid_q_id(vf, qci->vsi_id, qpi->txq.queue_id)) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
+ goto error_param;
+ }
+
+@@ -3631,7 +3622,6 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
+ * for selected "vsi"
+ */
+ if (q_idx >= vsi->alloc_txq || q_idx >= vsi->alloc_rxq) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
+ goto error_param;
+ }
+
+@@ -3641,14 +3631,13 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
+ vsi->tx_rings[i]->count = qpi->txq.ring_len;
+
+ /* Disable any existing queue first */
+- if (ice_vf_vsi_dis_single_txq(vf, vsi, q_idx)) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ if (ice_vf_vsi_dis_single_txq(vf, vsi, q_idx))
+ goto error_param;
+- }
+
+ /* Configure a queue with the requested settings */
+ if (ice_vsi_cfg_single_txq(vsi, vsi->tx_rings, q_idx)) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ dev_warn(ice_pf_to_dev(pf), "VF-%d failed to configure TX queue %d\n",
++ vf->vf_id, i);
+ goto error_param;
+ }
+ }
+@@ -3662,17 +3651,13 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
+
+ if (qpi->rxq.databuffer_size != 0 &&
+ (qpi->rxq.databuffer_size > ((16 * 1024) - 128) ||
+- qpi->rxq.databuffer_size < 1024)) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ qpi->rxq.databuffer_size < 1024))
+ goto error_param;
+- }
+ vsi->rx_buf_len = qpi->rxq.databuffer_size;
+ vsi->rx_rings[i]->rx_buf_len = vsi->rx_buf_len;
+ if (qpi->rxq.max_pkt_size > max_frame_size ||
+- qpi->rxq.max_pkt_size < 64) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ qpi->rxq.max_pkt_size < 64)
+ goto error_param;
+- }
+
+ vsi->max_frame = qpi->rxq.max_pkt_size;
+ /* add space for the port VLAN since the VF driver is not
+@@ -3682,16 +3667,30 @@ static int ice_vc_cfg_qs_msg(struct ice_vf *vf, u8 *msg)
+ vsi->max_frame += VLAN_HLEN;
+
+ if (ice_vsi_cfg_single_rxq(vsi, q_idx)) {
+- v_ret = VIRTCHNL_STATUS_ERR_PARAM;
++ dev_warn(ice_pf_to_dev(pf), "VF-%d failed to configure RX queue %d\n",
++ vf->vf_id, i);
+ goto error_param;
+ }
+ }
+ }
+
++ /* send the response to the VF */
++ return ice_vc_send_msg_to_vf(vf, VIRTCHNL_OP_CONFIG_VSI_QUEUES,
++ VIRTCHNL_STATUS_SUCCESS, NULL, 0);
+ error_param:
++ /* disable whatever we can */
++ for (; i >= 0; i--) {
++ if (ice_vsi_ctrl_one_rx_ring(vsi, false, i, true))
++ dev_err(ice_pf_to_dev(pf), "VF-%d could not disable RX queue %d\n",
++ vf->vf_id, i);
++ if (ice_vf_vsi_dis_single_txq(vf, vsi, i))
++ dev_err(ice_pf_to_dev(pf), "VF-%d could not disable TX queue %d\n",
++ vf->vf_id, i);
++ }
++
+ /* send the response to the VF */
+- return ice_vc_send_msg_to_vf(vf, VIRTCHNL_OP_CONFIG_VSI_QUEUES, v_ret,
+- NULL, 0);
++ return ice_vc_send_msg_to_vf(vf, VIRTCHNL_OP_CONFIG_VSI_QUEUES,
++ VIRTCHNL_STATUS_ERR_PARAM, NULL, 0);
+ }
+
+ /**
+--
+2.35.1
+
--- /dev/null
+From 74e172d1614c2fb3ee7ecc84e7bc3eac24258d8d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Jun 2022 15:22:29 +0200
+Subject: init: Initialize noop_backing_dev_info early
+
+From: Jan Kara <jack@suse.cz>
+
+[ Upstream commit 4bca7e80b6455772b4bf3f536dcbc19aac424d6a ]
+
+noop_backing_dev_info is used by superblocks of various
+pseudofilesystems such as kdevtmpfs. After commit 10e14073107d
+("writeback: Fix inode->i_io_list not be protected by inode->i_lock
+error") this broke because __mark_inode_dirty() started to access more
+fields from noop_backing_dev_info and this led to crashes inside
+locked_inode_to_wb_and_lock_list() called from __mark_inode_dirty().
+Fix the problem by initializing noop_backing_dev_info before the
+filesystems get mounted.
+
+Fixes: 10e14073107d ("writeback: Fix inode->i_io_list not be protected by inode->i_lock error")
+Reported-and-tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Reported-and-tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
+Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/base/init.c | 2 ++
+ include/linux/backing-dev.h | 2 ++
+ mm/backing-dev.c | 11 ++---------
+ 3 files changed, 6 insertions(+), 9 deletions(-)
+
+diff --git a/drivers/base/init.c b/drivers/base/init.c
+index a9f57c22fb9e..dab8aa5d2888 100644
+--- a/drivers/base/init.c
++++ b/drivers/base/init.c
+@@ -8,6 +8,7 @@
+ #include <linux/init.h>
+ #include <linux/memory.h>
+ #include <linux/of.h>
++#include <linux/backing-dev.h>
+
+ #include "base.h"
+
+@@ -20,6 +21,7 @@
+ void __init driver_init(void)
+ {
+ /* These are the core pieces */
++ bdi_init(&noop_backing_dev_info);
+ devtmpfs_init();
+ devices_init();
+ buses_init();
+diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
+index 483979c1b9f4..677fe99cc637 100644
+--- a/include/linux/backing-dev.h
++++ b/include/linux/backing-dev.h
+@@ -121,6 +121,8 @@ int bdi_set_max_ratio(struct backing_dev_info *bdi, unsigned int max_ratio);
+
+ extern struct backing_dev_info noop_backing_dev_info;
+
++int bdi_init(struct backing_dev_info *bdi);
++
+ /**
+ * writeback_in_progress - determine whether there is writeback in progress
+ * @wb: bdi_writeback of interest
+diff --git a/mm/backing-dev.c b/mm/backing-dev.c
+index eae96dfe0261..a48c66c3bf5f 100644
+--- a/mm/backing-dev.c
++++ b/mm/backing-dev.c
+@@ -230,20 +230,13 @@ static __init int bdi_class_init(void)
+ }
+ postcore_initcall(bdi_class_init);
+
+-static int bdi_init(struct backing_dev_info *bdi);
+-
+ static int __init default_bdi_init(void)
+ {
+- int err;
+-
+ bdi_wq = alloc_workqueue("writeback", WQ_MEM_RECLAIM | WQ_UNBOUND |
+ WQ_SYSFS, 0);
+ if (!bdi_wq)
+ return -ENOMEM;
+-
+- err = bdi_init(&noop_backing_dev_info);
+-
+- return err;
++ return 0;
+ }
+ subsys_initcall(default_bdi_init);
+
+@@ -782,7 +775,7 @@ static void cgwb_remove_from_bdi_list(struct bdi_writeback *wb)
+
+ #endif /* CONFIG_CGROUP_WRITEBACK */
+
+-static int bdi_init(struct backing_dev_info *bdi)
++int bdi_init(struct backing_dev_info *bdi)
+ {
+ int ret;
+
+--
+2.35.1
+
--- /dev/null
+From 0286ab47c5d95c81bec9373b423e3d2e0940f3e4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Jun 2022 06:30:06 +0100
+Subject: io_uring: fix races with buffer table unregister
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+[ Upstream commit d11d31fc5d8a96f707facee0babdcffaafa38de2 ]
+
+Fixed buffer table quiesce might unlock ->uring_lock, potentially
+letting new requests to be submitted, don't allow those requests to
+use the table as they will race with unregistration.
+
+Reported-and-tested-by: van fantasy <g1042620637@gmail.com>
+Fixes: bd54b6fe3316ec ("io_uring: implement fixed buffers registration similar to fixed files")
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/io_uring.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/fs/io_uring.c b/fs/io_uring.c
+index 61d1376e4d9c..f4db5fa2f332 100644
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -9074,12 +9074,19 @@ static void __io_sqe_buffers_unregister(struct io_ring_ctx *ctx)
+
+ static int io_sqe_buffers_unregister(struct io_ring_ctx *ctx)
+ {
++ unsigned nr = ctx->nr_user_bufs;
+ int ret;
+
+ if (!ctx->buf_data)
+ return -ENXIO;
+
++ /*
++ * Quiesce may unlock ->uring_lock, and while it's not held
++ * prevent new requests using the table.
++ */
++ ctx->nr_user_bufs = 0;
+ ret = io_rsrc_ref_quiesce(ctx->buf_data, ctx);
++ ctx->nr_user_bufs = nr;
+ if (!ret)
+ __io_sqe_buffers_unregister(ctx);
+ return ret;
+--
+2.35.1
+
--- /dev/null
+From 33e7fb0f20c393157ee5eebc5934f240629e242a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Jun 2022 06:32:44 +0100
+Subject: io_uring: fix races with file table unregister
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+[ Upstream commit b0380bf6dad4601d92025841e2b7a135d566c6e3 ]
+
+Fixed file table quiesce might unlock ->uring_lock, potentially letting
+new requests to be submitted, don't allow those requests to use the
+table as they will race with unregistration.
+
+Reported-and-tested-by: van fantasy <g1042620637@gmail.com>
+Fixes: 05f3fb3c53975 ("io_uring: avoid ring quiesce for fixed file set unregister and update")
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/io_uring.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/fs/io_uring.c b/fs/io_uring.c
+index 0bd592af1bf7..61d1376e4d9c 100644
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -8098,11 +8098,19 @@ static void __io_sqe_files_unregister(struct io_ring_ctx *ctx)
+
+ static int io_sqe_files_unregister(struct io_ring_ctx *ctx)
+ {
++ unsigned nr = ctx->nr_user_files;
+ int ret;
+
+ if (!ctx->file_data)
+ return -ENXIO;
++
++ /*
++ * Quiesce may unlock ->uring_lock, and while it's not held
++ * prevent new requests using the table.
++ */
++ ctx->nr_user_files = 0;
+ ret = io_rsrc_ref_quiesce(ctx->file_data, ctx);
++ ctx->nr_user_files = nr;
+ if (!ret)
+ __io_sqe_files_unregister(ctx);
+ return ret;
+--
+2.35.1
+
--- /dev/null
+From 977ce07e7b80fbcdf258700815c486a5d65a08e5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 1 Jun 2022 16:30:26 +0400
+Subject: misc: atmel-ssc: Fix IRQ check in ssc_probe
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+[ Upstream commit 1c245358ce0b13669f6d1625f7a4e05c41f28980 ]
+
+platform_get_irq() returns negative error number instead 0 on failure.
+And the doc of platform_get_irq() provides a usage example:
+
+ int irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+Fix the check of return value to catch errors correctly.
+
+Fixes: eb1f2930609b ("Driver for the Atmel on-chip SSC on AT32AP and AT91")
+Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Link: https://lore.kernel.org/r/20220601123026.7119-1-linmq006@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/misc/atmel-ssc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
+index d6cd5537126c..69f9b0336410 100644
+--- a/drivers/misc/atmel-ssc.c
++++ b/drivers/misc/atmel-ssc.c
+@@ -232,9 +232,9 @@ static int ssc_probe(struct platform_device *pdev)
+ clk_disable_unprepare(ssc->clk);
+
+ ssc->irq = platform_get_irq(pdev, 0);
+- if (!ssc->irq) {
++ if (ssc->irq < 0) {
+ dev_dbg(&pdev->dev, "could not get irq\n");
+- return -ENXIO;
++ return ssc->irq;
+ }
+
+ mutex_lock(&user_lock);
+--
+2.35.1
+
--- /dev/null
+From 3e58796aa3c384b1175c8771959218078844af19 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Jun 2022 15:50:17 +0300
+Subject: mlxsw: spectrum_cnt: Reorder counter pools
+
+From: Petr Machata <petrm@nvidia.com>
+
+[ Upstream commit 4b7a632ac4e7101ceefee8484d5c2ca505d347b3 ]
+
+Both RIF and ACL flow counters use a 24-bit SW-managed counter address to
+communicate which counter they want to bind.
+
+In a number of Spectrum FW releases, binding a RIF counter is broken and
+slices the counter index to 16 bits. As a result, on Spectrum-2 and above,
+no more than about 410 RIF counters can be effectively used. This
+translates to 205 netdevices for which L3 HW stats can be enabled. (This
+does not happen on Spectrum-1, because there are fewer counters available
+overall and the counter index never exceeds 16 bits.)
+
+Binding counters to ACLs does not have this issue. Therefore reorder the
+counter allocation scheme so that RIF counters come first and therefore get
+lower indices that are below the 16-bit barrier.
+
+Fixes: 98e60dce4da1 ("Merge branch 'mlxsw-Introduce-initial-Spectrum-2-support'")
+Reported-by: Maksym Yaremchuk <maksymy@nvidia.com>
+Signed-off-by: Petr Machata <petrm@nvidia.com>
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Link: https://lore.kernel.org/r/20220613125017.2018162-1-idosch@nvidia.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.h
+index a68d931090dd..15c8d4de8350 100644
+--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.h
++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.h
+@@ -8,8 +8,8 @@
+ #include "spectrum.h"
+
+ enum mlxsw_sp_counter_sub_pool_id {
+- MLXSW_SP_COUNTER_SUB_POOL_FLOW,
+ MLXSW_SP_COUNTER_SUB_POOL_RIF,
++ MLXSW_SP_COUNTER_SUB_POOL_FLOW,
+ };
+
+ int mlxsw_sp_counter_alloc(struct mlxsw_sp *mlxsw_sp,
+--
+2.35.1
+
--- /dev/null
+From fe07aea6af8ba29d8c8b535cc63d20b77a1cec62 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Jun 2022 17:25:57 +0800
+Subject: net: ax25: Fix deadlock caused by skb_recv_datagram in ax25_recvmsg
+
+From: Duoming Zhou <duoming@zju.edu.cn>
+
+[ Upstream commit 219b51a6f040fa5367adadd7d58c4dda0896a01d ]
+
+The skb_recv_datagram() in ax25_recvmsg() will hold lock_sock
+and block until it receives a packet from the remote. If the client
+doesn`t connect to server and calls read() directly, it will not
+receive any packets forever. As a result, the deadlock will happen.
+
+The fail log caused by deadlock is shown below:
+
+[ 369.606973] INFO: task ax25_deadlock:157 blocked for more than 245 seconds.
+[ 369.608919] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+[ 369.613058] Call Trace:
+[ 369.613315] <TASK>
+[ 369.614072] __schedule+0x2f9/0xb20
+[ 369.615029] schedule+0x49/0xb0
+[ 369.615734] __lock_sock+0x92/0x100
+[ 369.616763] ? destroy_sched_domains_rcu+0x20/0x20
+[ 369.617941] lock_sock_nested+0x6e/0x70
+[ 369.618809] ax25_bind+0xaa/0x210
+[ 369.619736] __sys_bind+0xca/0xf0
+[ 369.620039] ? do_futex+0xae/0x1b0
+[ 369.620387] ? __x64_sys_futex+0x7c/0x1c0
+[ 369.620601] ? fpregs_assert_state_consistent+0x19/0x40
+[ 369.620613] __x64_sys_bind+0x11/0x20
+[ 369.621791] do_syscall_64+0x3b/0x90
+[ 369.622423] entry_SYSCALL_64_after_hwframe+0x46/0xb0
+[ 369.623319] RIP: 0033:0x7f43c8aa8af7
+[ 369.624301] RSP: 002b:00007f43c8197ef8 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
+[ 369.625756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f43c8aa8af7
+[ 369.626724] RDX: 0000000000000010 RSI: 000055768e2021d0 RDI: 0000000000000005
+[ 369.628569] RBP: 00007f43c8197f00 R08: 0000000000000011 R09: 00007f43c8198700
+[ 369.630208] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff845e6afe
+[ 369.632240] R13: 00007fff845e6aff R14: 00007f43c8197fc0 R15: 00007f43c8198700
+
+This patch replaces skb_recv_datagram() with an open-coded variant of it
+releasing the socket lock before the __skb_wait_for_more_packets() call
+and re-acquiring it after such call in order that other functions that
+need socket lock could be executed.
+
+what's more, the socket lock will be released only when recvmsg() will
+block and that should produce nicer overall behavior.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Suggested-by: Thomas Osterried <thomas@osterried.de>
+Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
+Reported-by: Thomas Habets <thomas@@habets.se>
+Acked-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ax25/af_ax25.c | 34 ++++++++++++++++++++++++++++------
+ 1 file changed, 28 insertions(+), 6 deletions(-)
+
+diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
+index 289f355e1853..4c7030ed8d33 100644
+--- a/net/ax25/af_ax25.c
++++ b/net/ax25/af_ax25.c
+@@ -1661,9 +1661,12 @@ static int ax25_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
+ int flags)
+ {
+ struct sock *sk = sock->sk;
+- struct sk_buff *skb;
++ struct sk_buff *skb, *last;
++ struct sk_buff_head *sk_queue;
+ int copied;
+ int err = 0;
++ int off = 0;
++ long timeo;
+
+ lock_sock(sk);
+ /*
+@@ -1675,11 +1678,29 @@ static int ax25_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
+ goto out;
+ }
+
+- /* Now we can treat all alike */
+- skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT,
+- flags & MSG_DONTWAIT, &err);
+- if (skb == NULL)
+- goto out;
++ /* We need support for non-blocking reads. */
++ sk_queue = &sk->sk_receive_queue;
++ skb = __skb_try_recv_datagram(sk, sk_queue, flags, &off, &err, &last);
++ /* If no packet is available, release_sock(sk) and try again. */
++ if (!skb) {
++ if (err != -EAGAIN)
++ goto out;
++ release_sock(sk);
++ timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
++ while (timeo && !__skb_wait_for_more_packets(sk, sk_queue, &err,
++ &timeo, last)) {
++ skb = __skb_try_recv_datagram(sk, sk_queue, flags, &off,
++ &err, &last);
++ if (skb)
++ break;
++
++ if (err != -EAGAIN)
++ goto done;
++ }
++ if (!skb)
++ goto done;
++ lock_sock(sk);
++ }
+
+ if (!sk_to_ax25(sk)->pidincl)
+ skb_pull(skb, 1); /* Remove PID */
+@@ -1726,6 +1747,7 @@ static int ax25_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
+ out:
+ release_sock(sk);
+
++done:
+ return err;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 9a781ea267afc90d4752b6719c21d3396b96cfce Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Jun 2022 22:53:50 +0200
+Subject: net: bgmac: Fix an erroneous kfree() in bgmac_remove()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit d7dd6eccfbc95ac47a12396f84e7e1b361db654b ]
+
+'bgmac' is part of a managed resource allocated with bgmac_alloc(). It
+should not be freed explicitly.
+
+Remove the erroneous kfree() from the .remove() function.
+
+Fixes: 34a5102c3235 ("net: bgmac: allocate struct bgmac just once & don't copy it")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
+Link: https://lore.kernel.org/r/a026153108dd21239036a032b95c25b5cece253b.1655153616.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/bgmac-bcma.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c
+index e6f48786949c..02bd3cf9a260 100644
+--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
++++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
+@@ -332,7 +332,6 @@ static void bgmac_remove(struct bcma_device *core)
+ bcma_mdio_mii_unregister(bgmac->mii_bus);
+ bgmac_enet_remove(bgmac);
+ bcma_set_drvdata(core, NULL);
+- kfree(bgmac);
+ }
+
+ static struct bcma_driver bgmac_bcma_driver = {
+--
+2.35.1
+
--- /dev/null
+From 0a844a90330e069f74c38d0f23427735f8530419 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Jun 2022 20:25:25 +0800
+Subject: net: hns3: don't push link state to VF if unalive
+
+From: Jian Shen <shenjian15@huawei.com>
+
+[ Upstream commit 283847e3ef6dbf79bf67083b5ce7b8033e8b6f34 ]
+
+It's unnecessary to push link state to unalive VF, and the VF will
+query link state from PF when it being start works.
+
+Fixes: 18b6e31f8bf4 ("net: hns3: PF add support for pushing link status to VFs")
+Signed-off-by: Jian Shen <shenjian15@huawei.com>
+Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+index 55dd3f5abc48..0c6c467d0905 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+@@ -3375,6 +3375,12 @@ static int hclge_set_vf_link_state(struct hnae3_handle *handle, int vf,
+ link_state_old = vport->vf_info.link_state;
+ vport->vf_info.link_state = link_state;
+
++ /* return success directly if the VF is unalive, VF will
++ * query link state itself when it starts work.
++ */
++ if (!test_bit(HCLGE_VPORT_STATE_ALIVE, &vport->state))
++ return 0;
++
+ ret = hclge_push_vf_link_status(vport);
+ if (ret) {
+ vport->vf_info.link_state = link_state_old;
+--
+2.35.1
+
--- /dev/null
+From 2c3cac0e9f996679700a6a9d178b86da84904f9f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Jun 2022 20:25:28 +0800
+Subject: net: hns3: fix PF rss size initialization bug
+
+From: Jie Wang <wangjie125@huawei.com>
+
+[ Upstream commit 71b215f36dca1a3d5d1c576b2099e6d7ea03047e ]
+
+Currently hns3 driver misuses the VF rss size to initialize the PF rss size
+in hclge_tm_vport_tc_info_update. So this patch fix it by checking the
+vport id before initialization.
+
+Fixes: 7347255ea389 ("net: hns3: refactor PF rss get APIs with new common rss get APIs")
+Signed-off-by: Jie Wang <wangjie125@huawei.com>
+Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+index 9fb0417c959e..6c31770842fa 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+@@ -681,7 +681,9 @@ static void hclge_tm_vport_tc_info_update(struct hclge_vport *vport)
+ kinfo->num_tqps = hclge_vport_get_tqp_num(vport);
+ vport->dwrr = 100; /* 100 percent as init */
+ vport->bw_limit = hdev->tm_info.pg_info[0].bw_limit;
+- hdev->rss_cfg.rss_size = kinfo->rss_size;
++
++ if (vport->vport_id == PF_VPORT_ID)
++ hdev->rss_cfg.rss_size = kinfo->rss_size;
+
+ /* when enable mqprio, the tc_info has been updated. */
+ if (kinfo->tc_info.mqprio_active)
+--
+2.35.1
+
--- /dev/null
+From 80d7ec1ebd6cef190cf681441e0df90c80585266 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Jun 2022 20:25:29 +0800
+Subject: net: hns3: fix tm port shapping of fibre port is incorrect after
+ driver initialization
+
+From: Guangbin Huang <huangguangbin2@huawei.com>
+
+[ Upstream commit 12a3670887725df364cc3e030cf3bede6f13b364 ]
+
+Currently in driver initialization process, driver will set shapping
+parameters of tm port to default speed read from firmware. However, the
+speed of SFP module may not be default speed, so shapping parameters of
+tm port may be incorrect.
+
+To fix this problem, driver sets new shapping parameters for tm port
+after getting exact speed of SFP module in this case.
+
+Fixes: 88d10bd6f730 ("net: hns3: add support for multiple media type")
+Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 11 ++++++++---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +-
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h | 1 +
+ 3 files changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+index 0c6c467d0905..95f1f1e89950 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+@@ -3267,7 +3267,7 @@ static int hclge_tp_port_init(struct hclge_dev *hdev)
+ static int hclge_update_port_info(struct hclge_dev *hdev)
+ {
+ struct hclge_mac *mac = &hdev->hw.mac;
+- int speed = HCLGE_MAC_SPEED_UNKNOWN;
++ int speed;
+ int ret;
+
+ /* get the port info from SFP cmd if not copper port */
+@@ -3278,10 +3278,13 @@ static int hclge_update_port_info(struct hclge_dev *hdev)
+ if (!hdev->support_sfp_query)
+ return 0;
+
+- if (hdev->ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V2)
++ if (hdev->ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V2) {
++ speed = mac->speed;
+ ret = hclge_get_sfp_info(hdev, mac);
+- else
++ } else {
++ speed = HCLGE_MAC_SPEED_UNKNOWN;
+ ret = hclge_get_sfp_speed(hdev, &speed);
++ }
+
+ if (ret == -EOPNOTSUPP) {
+ hdev->support_sfp_query = false;
+@@ -3293,6 +3296,8 @@ static int hclge_update_port_info(struct hclge_dev *hdev)
+ if (hdev->ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V2) {
+ if (mac->speed_type == QUERY_ACTIVE_SPEED) {
+ hclge_update_port_capability(hdev, mac);
++ if (mac->speed != speed)
++ (void)hclge_tm_port_shaper_cfg(hdev);
+ return 0;
+ }
+ return hclge_cfg_mac_speed_dup(hdev, mac->speed,
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+index 6c31770842fa..084e190602d6 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+@@ -420,7 +420,7 @@ static int hclge_tm_pg_shapping_cfg(struct hclge_dev *hdev,
+ return hclge_cmd_send(&hdev->hw, &desc, 1);
+ }
+
+-static int hclge_tm_port_shaper_cfg(struct hclge_dev *hdev)
++int hclge_tm_port_shaper_cfg(struct hclge_dev *hdev)
+ {
+ struct hclge_port_shapping_cmd *shap_cfg_cmd;
+ struct hclge_shaper_ir_para ir_para;
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h
+index 619cc30a2dfc..d943943912f7 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h
+@@ -237,6 +237,7 @@ int hclge_pause_addr_cfg(struct hclge_dev *hdev, const u8 *mac_addr);
+ void hclge_pfc_rx_stats_get(struct hclge_dev *hdev, u64 *stats);
+ void hclge_pfc_tx_stats_get(struct hclge_dev *hdev, u64 *stats);
+ int hclge_tm_qs_shaper_cfg(struct hclge_vport *vport, int max_tx_rate);
++int hclge_tm_port_shaper_cfg(struct hclge_dev *hdev);
+ int hclge_tm_get_qset_num(struct hclge_dev *hdev, u16 *qset_num);
+ int hclge_tm_get_pri_num(struct hclge_dev *hdev, u8 *pri_num);
+ int hclge_tm_get_qset_map_pri(struct hclge_dev *hdev, u16 qset_id, u8 *priority,
+--
+2.35.1
+
--- /dev/null
+From 74c1fd6c3e43bf6557d72c539c0645398ce9e19d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Jun 2022 20:25:27 +0800
+Subject: net: hns3: restore tm priority/qset to default settings when tc
+ disabled
+
+From: Guangbin Huang <huangguangbin2@huawei.com>
+
+[ Upstream commit e93530ae0e5d8fcf2d908933d206e0c93bc3c09b ]
+
+Currently, settings parameters of schedule mode, dwrr, shaper of tm
+priority or qset of one tc are only be set when tc is enabled, they are
+not restored to the default settings when tc is disabled. It confuses
+users when they cat tm_priority or tm_qset files of debugfs. So this
+patch fixes it.
+
+Fixes: 848440544b41 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver")
+Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
+ .../ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 95 +++++++++++++------
+ 2 files changed, 65 insertions(+), 31 deletions(-)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+index 8184a954f648..3e343ea15ba5 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
++++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+@@ -764,6 +764,7 @@ struct hnae3_tc_info {
+ u8 prio_tc[HNAE3_MAX_USER_PRIO]; /* TC indexed by prio */
+ u16 tqp_count[HNAE3_MAX_TC];
+ u16 tqp_offset[HNAE3_MAX_TC];
++ u8 max_tc; /* Total number of TCs */
+ u8 num_tc; /* Total number of enabled TCs */
+ bool mqprio_active;
+ };
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+index 089f4444b7e3..9fb0417c959e 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+@@ -282,8 +282,8 @@ static int hclge_tm_pg_to_pri_map_cfg(struct hclge_dev *hdev,
+ return hclge_cmd_send(&hdev->hw, &desc, 1);
+ }
+
+-static int hclge_tm_qs_to_pri_map_cfg(struct hclge_dev *hdev,
+- u16 qs_id, u8 pri)
++static int hclge_tm_qs_to_pri_map_cfg(struct hclge_dev *hdev, u16 qs_id, u8 pri,
++ bool link_vld)
+ {
+ struct hclge_qs_to_pri_link_cmd *map;
+ struct hclge_desc desc;
+@@ -294,7 +294,7 @@ static int hclge_tm_qs_to_pri_map_cfg(struct hclge_dev *hdev,
+
+ map->qs_id = cpu_to_le16(qs_id);
+ map->priority = pri;
+- map->link_vld = HCLGE_TM_QS_PRI_LINK_VLD_MSK;
++ map->link_vld = link_vld ? HCLGE_TM_QS_PRI_LINK_VLD_MSK : 0;
+
+ return hclge_cmd_send(&hdev->hw, &desc, 1);
+ }
+@@ -642,11 +642,13 @@ static void hclge_tm_update_kinfo_rss_size(struct hclge_vport *vport)
+ * one tc for VF for simplicity. VF's vport_id is non zero.
+ */
+ if (vport->vport_id) {
++ kinfo->tc_info.max_tc = 1;
+ kinfo->tc_info.num_tc = 1;
+ vport->qs_offset = HNAE3_MAX_TC +
+ vport->vport_id - HCLGE_VF_VPORT_START_NUM;
+ vport_max_rss_size = hdev->vf_rss_size_max;
+ } else {
++ kinfo->tc_info.max_tc = hdev->tc_max;
+ kinfo->tc_info.num_tc =
+ min_t(u16, vport->alloc_tqps, hdev->tm_info.num_tc);
+ vport->qs_offset = 0;
+@@ -714,14 +716,22 @@ static void hclge_tm_vport_info_update(struct hclge_dev *hdev)
+
+ static void hclge_tm_tc_info_init(struct hclge_dev *hdev)
+ {
+- u8 i;
++ u8 i, tc_sch_mode;
++ u32 bw_limit;
++
++ for (i = 0; i < hdev->tc_max; i++) {
++ if (i < hdev->tm_info.num_tc) {
++ tc_sch_mode = HCLGE_SCH_MODE_DWRR;
++ bw_limit = hdev->tm_info.pg_info[0].bw_limit;
++ } else {
++ tc_sch_mode = HCLGE_SCH_MODE_SP;
++ bw_limit = 0;
++ }
+
+- for (i = 0; i < hdev->tm_info.num_tc; i++) {
+ hdev->tm_info.tc_info[i].tc_id = i;
+- hdev->tm_info.tc_info[i].tc_sch_mode = HCLGE_SCH_MODE_DWRR;
++ hdev->tm_info.tc_info[i].tc_sch_mode = tc_sch_mode;
+ hdev->tm_info.tc_info[i].pgid = 0;
+- hdev->tm_info.tc_info[i].bw_limit =
+- hdev->tm_info.pg_info[0].bw_limit;
++ hdev->tm_info.tc_info[i].bw_limit = bw_limit;
+ }
+
+ for (i = 0; i < HNAE3_MAX_USER_PRIO; i++)
+@@ -926,10 +936,13 @@ static int hclge_tm_pri_q_qs_cfg_tc_base(struct hclge_dev *hdev)
+ for (k = 0; k < hdev->num_alloc_vport; k++) {
+ struct hnae3_knic_private_info *kinfo = &vport[k].nic.kinfo;
+
+- for (i = 0; i < kinfo->tc_info.num_tc; i++) {
++ for (i = 0; i < kinfo->tc_info.max_tc; i++) {
++ u8 pri = i < kinfo->tc_info.num_tc ? i : 0;
++ bool link_vld = i < kinfo->tc_info.num_tc;
++
+ ret = hclge_tm_qs_to_pri_map_cfg(hdev,
+ vport[k].qs_offset + i,
+- i);
++ pri, link_vld);
+ if (ret)
+ return ret;
+ }
+@@ -949,7 +962,7 @@ static int hclge_tm_pri_q_qs_cfg_vnet_base(struct hclge_dev *hdev)
+ for (i = 0; i < HNAE3_MAX_TC; i++) {
+ ret = hclge_tm_qs_to_pri_map_cfg(hdev,
+ vport[k].qs_offset + i,
+- k);
++ k, true);
+ if (ret)
+ return ret;
+ }
+@@ -989,33 +1002,39 @@ static int hclge_tm_pri_tc_base_shaper_cfg(struct hclge_dev *hdev)
+ {
+ u32 max_tm_rate = hdev->ae_dev->dev_specs.max_tm_rate;
+ struct hclge_shaper_ir_para ir_para;
+- u32 shaper_para;
++ u32 shaper_para_c, shaper_para_p;
+ int ret;
+ u32 i;
+
+- for (i = 0; i < hdev->tm_info.num_tc; i++) {
++ for (i = 0; i < hdev->tc_max; i++) {
+ u32 rate = hdev->tm_info.tc_info[i].bw_limit;
+
+- ret = hclge_shaper_para_calc(rate, HCLGE_SHAPER_LVL_PRI,
+- &ir_para, max_tm_rate);
+- if (ret)
+- return ret;
++ if (rate) {
++ ret = hclge_shaper_para_calc(rate, HCLGE_SHAPER_LVL_PRI,
++ &ir_para, max_tm_rate);
++ if (ret)
++ return ret;
++
++ shaper_para_c = hclge_tm_get_shapping_para(0, 0, 0,
++ HCLGE_SHAPER_BS_U_DEF,
++ HCLGE_SHAPER_BS_S_DEF);
++ shaper_para_p = hclge_tm_get_shapping_para(ir_para.ir_b,
++ ir_para.ir_u,
++ ir_para.ir_s,
++ HCLGE_SHAPER_BS_U_DEF,
++ HCLGE_SHAPER_BS_S_DEF);
++ } else {
++ shaper_para_c = 0;
++ shaper_para_p = 0;
++ }
+
+- shaper_para = hclge_tm_get_shapping_para(0, 0, 0,
+- HCLGE_SHAPER_BS_U_DEF,
+- HCLGE_SHAPER_BS_S_DEF);
+ ret = hclge_tm_pri_shapping_cfg(hdev, HCLGE_TM_SHAP_C_BUCKET, i,
+- shaper_para, rate);
++ shaper_para_c, rate);
+ if (ret)
+ return ret;
+
+- shaper_para = hclge_tm_get_shapping_para(ir_para.ir_b,
+- ir_para.ir_u,
+- ir_para.ir_s,
+- HCLGE_SHAPER_BS_U_DEF,
+- HCLGE_SHAPER_BS_S_DEF);
+ ret = hclge_tm_pri_shapping_cfg(hdev, HCLGE_TM_SHAP_P_BUCKET, i,
+- shaper_para, rate);
++ shaper_para_p, rate);
+ if (ret)
+ return ret;
+ }
+@@ -1125,7 +1144,7 @@ static int hclge_tm_pri_tc_base_dwrr_cfg(struct hclge_dev *hdev)
+ int ret;
+ u32 i, k;
+
+- for (i = 0; i < hdev->tm_info.num_tc; i++) {
++ for (i = 0; i < hdev->tc_max; i++) {
+ pg_info =
+ &hdev->tm_info.pg_info[hdev->tm_info.tc_info[i].pgid];
+ dwrr = pg_info->tc_dwrr[i];
+@@ -1135,9 +1154,15 @@ static int hclge_tm_pri_tc_base_dwrr_cfg(struct hclge_dev *hdev)
+ return ret;
+
+ for (k = 0; k < hdev->num_alloc_vport; k++) {
++ struct hnae3_knic_private_info *kinfo = &vport[k].nic.kinfo;
++
++ if (i >= kinfo->tc_info.max_tc)
++ continue;
++
++ dwrr = i < kinfo->tc_info.num_tc ? vport[k].dwrr : 0;
+ ret = hclge_tm_qs_weight_cfg(
+ hdev, vport[k].qs_offset + i,
+- vport[k].dwrr);
++ dwrr);
+ if (ret)
+ return ret;
+ }
+@@ -1303,6 +1328,7 @@ static int hclge_tm_schd_mode_tc_base_cfg(struct hclge_dev *hdev, u8 pri_id)
+ {
+ struct hclge_vport *vport = hdev->vport;
+ int ret;
++ u8 mode;
+ u16 i;
+
+ ret = hclge_tm_pri_schd_mode_cfg(hdev, pri_id);
+@@ -1310,9 +1336,16 @@ static int hclge_tm_schd_mode_tc_base_cfg(struct hclge_dev *hdev, u8 pri_id)
+ return ret;
+
+ for (i = 0; i < hdev->num_alloc_vport; i++) {
++ struct hnae3_knic_private_info *kinfo = &vport[i].nic.kinfo;
++
++ if (pri_id >= kinfo->tc_info.max_tc)
++ continue;
++
++ mode = pri_id < kinfo->tc_info.num_tc ? HCLGE_SCH_MODE_DWRR :
++ HCLGE_SCH_MODE_SP;
+ ret = hclge_tm_qs_schd_mode_cfg(hdev,
+ vport[i].qs_offset + pri_id,
+- HCLGE_SCH_MODE_DWRR);
++ mode);
+ if (ret)
+ return ret;
+ }
+@@ -1353,7 +1386,7 @@ static int hclge_tm_lvl34_schd_mode_cfg(struct hclge_dev *hdev)
+ u8 i;
+
+ if (hdev->tx_sch_mode == HCLGE_FLAG_TC_BASE_SCH_MODE) {
+- for (i = 0; i < hdev->tm_info.num_tc; i++) {
++ for (i = 0; i < hdev->tc_max; i++) {
+ ret = hclge_tm_schd_mode_tc_base_cfg(hdev, i);
+ if (ret)
+ return ret;
+--
+2.35.1
+
--- /dev/null
+From a7838424a6ad4e7f422f0dbc3b615d181682f41c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Jun 2022 20:25:24 +0800
+Subject: net: hns3: set port base vlan tbl_sta to false before removing old
+ vlan
+
+From: Guangbin Huang <huangguangbin2@huawei.com>
+
+[ Upstream commit 9eda7d8bcbdb6909f202edeedff51948f1cad1e5 ]
+
+When modify port base vlan, the port base vlan tbl_sta needs to set to
+false before removing old vlan, to indicate this operation is not finish.
+
+Fixes: c0f46de30c96 ("net: hns3: fix port base vlan add fail when concurrent with reset")
+Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+index e96bc61a0a87..55dd3f5abc48 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+@@ -10127,6 +10127,7 @@ static int hclge_modify_port_base_vlan_tag(struct hclge_vport *vport,
+ if (ret)
+ return ret;
+
++ vport->port_base_vlan_cfg.tbl_sta = false;
+ /* remove old VLAN tag */
+ if (old_info->vlan_tag == 0)
+ ret = hclge_set_vf_vlan_common(hdev, vport->vport_id,
+--
+2.35.1
+
--- /dev/null
+From b27e09c4de32c81313a0ef9531f478aa5477d467 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 7 Jun 2022 17:55:55 +0200
+Subject: nvme: add device name to warning in uuid_show()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Weißschuh <linux@weissschuh.net>
+
+[ Upstream commit 1fc766b5c08417248e0008bca14c3572ac0f1c26 ]
+
+This provides more context to users.
+
+Old message:
+
+[ 00.000000] No UUID available providing old NGUID
+
+New message:
+
+[ 00.000000] block nvme0n1: No UUID available providing old NGUID
+
+Fixes: d934f9848a77 ("nvme: provide UUID value to userspace")
+Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
+index e086440a2042..cec0d4256204 100644
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -3246,8 +3246,8 @@ static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
+ * we have no UUID set
+ */
+ if (uuid_is_null(&ids->uuid)) {
+- printk_ratelimited(KERN_WARNING
+- "No UUID available providing old NGUID\n");
++ dev_warn_ratelimited(dev,
++ "No UUID available providing old NGUID\n");
+ return sysfs_emit(buf, "%pU\n", ids->nguid);
+ }
+ return sysfs_emit(buf, "%pU\n", &ids->uuid);
+--
+2.35.1
+
--- /dev/null
+From cc4c0b462400191154a292a6f892454fe0b02f2e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 31 May 2022 11:03:07 -0400
+Subject: pNFS: Avoid a live lock condition in pnfs_update_layout()
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+[ Upstream commit 880265c77ac415090090d1fe72a188fee71cb458 ]
+
+If we're about to send the first layoutget for an empty layout, we want
+to make sure that we drain out the existing pending layoutget calls
+first. The reason is that these layouts may have been already implicitly
+returned to the server by a recall to which the client gave a
+NFS4ERR_NOMATCHING_LAYOUT response.
+
+The problem is that wait_var_event_killable() could in principle see the
+plh_outstanding count go back to '1' when the first process to wake up
+starts sending a new layoutget. If it fails to get a layout, then this
+loop can continue ad infinitum...
+
+Fixes: 0b77f97a7e42 ("NFSv4/pnfs: Fix layoutget behaviour after invalidation")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/callback_proc.c | 1 +
+ fs/nfs/pnfs.c | 15 +++++++++------
+ fs/nfs/pnfs.h | 1 +
+ 3 files changed, 11 insertions(+), 6 deletions(-)
+
+diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c
+index 6464dde03705..ea8176287c0a 100644
+--- a/fs/nfs/callback_proc.c
++++ b/fs/nfs/callback_proc.c
+@@ -288,6 +288,7 @@ static u32 initiate_file_draining(struct nfs_client *clp,
+ rv = NFS4_OK;
+ break;
+ case -ENOENT:
++ set_bit(NFS_LAYOUT_DRAIN, &lo->plh_flags);
+ /* Embrace your forgetfulness! */
+ rv = NFS4ERR_NOMATCHING_LAYOUT;
+
+diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
+index 9b2549222391..7217f3eeb069 100644
+--- a/fs/nfs/pnfs.c
++++ b/fs/nfs/pnfs.c
+@@ -469,6 +469,7 @@ pnfs_mark_layout_stateid_invalid(struct pnfs_layout_hdr *lo,
+ pnfs_clear_lseg_state(lseg, lseg_list);
+ pnfs_clear_layoutreturn_info(lo);
+ pnfs_free_returned_lsegs(lo, lseg_list, &range, 0);
++ set_bit(NFS_LAYOUT_DRAIN, &lo->plh_flags);
+ if (test_bit(NFS_LAYOUT_RETURN, &lo->plh_flags) &&
+ !test_and_set_bit(NFS_LAYOUT_RETURN_LOCK, &lo->plh_flags))
+ pnfs_clear_layoutreturn_waitbit(lo);
+@@ -1917,8 +1918,9 @@ static void nfs_layoutget_begin(struct pnfs_layout_hdr *lo)
+
+ static void nfs_layoutget_end(struct pnfs_layout_hdr *lo)
+ {
+- if (atomic_dec_and_test(&lo->plh_outstanding))
+- wake_up_var(&lo->plh_outstanding);
++ if (atomic_dec_and_test(&lo->plh_outstanding) &&
++ test_and_clear_bit(NFS_LAYOUT_DRAIN, &lo->plh_flags))
++ wake_up_bit(&lo->plh_flags, NFS_LAYOUT_DRAIN);
+ }
+
+ static bool pnfs_is_first_layoutget(struct pnfs_layout_hdr *lo)
+@@ -2025,11 +2027,11 @@ pnfs_update_layout(struct inode *ino,
+ * If the layout segment list is empty, but there are outstanding
+ * layoutget calls, then they might be subject to a layoutrecall.
+ */
+- if ((list_empty(&lo->plh_segs) || !pnfs_layout_is_valid(lo)) &&
++ if (test_bit(NFS_LAYOUT_DRAIN, &lo->plh_flags) &&
+ atomic_read(&lo->plh_outstanding) != 0) {
+ spin_unlock(&ino->i_lock);
+- lseg = ERR_PTR(wait_var_event_killable(&lo->plh_outstanding,
+- !atomic_read(&lo->plh_outstanding)));
++ lseg = ERR_PTR(wait_on_bit(&lo->plh_flags, NFS_LAYOUT_DRAIN,
++ TASK_KILLABLE));
+ if (IS_ERR(lseg))
+ goto out_put_layout_hdr;
+ pnfs_put_layout_hdr(lo);
+@@ -2413,7 +2415,8 @@ pnfs_layout_process(struct nfs4_layoutget *lgp)
+ goto out_forget;
+ }
+
+- if (!pnfs_layout_is_valid(lo) && !pnfs_is_first_layoutget(lo))
++ if (test_bit(NFS_LAYOUT_DRAIN, &lo->plh_flags) &&
++ !pnfs_is_first_layoutget(lo))
+ goto out_forget;
+
+ if (nfs4_stateid_match_other(&lo->plh_stateid, &res->stateid)) {
+diff --git a/fs/nfs/pnfs.h b/fs/nfs/pnfs.h
+index 07f11489e4e9..f331f067691b 100644
+--- a/fs/nfs/pnfs.h
++++ b/fs/nfs/pnfs.h
+@@ -105,6 +105,7 @@ enum {
+ NFS_LAYOUT_FIRST_LAYOUTGET, /* Serialize first layoutget */
+ NFS_LAYOUT_INODE_FREEING, /* The inode is being freed */
+ NFS_LAYOUT_HASHED, /* The layout visible */
++ NFS_LAYOUT_DRAIN,
+ };
+
+ enum layoutdriver_policy_flags {
+--
+2.35.1
+
--- /dev/null
+From c8620ff4753b1ad84499662c9887d449f752cdc7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 31 May 2022 11:03:06 -0400
+Subject: pNFS: Don't keep retrying if the server replied
+ NFS4ERR_LAYOUTUNAVAILABLE
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+[ Upstream commit fe44fb23d6ccde4c914c44ef74ab8d9d9ba02bea ]
+
+If the server tells us that a pNFS layout is not available for a
+specific file, then we should not keep pounding it with further
+layoutget requests.
+
+Fixes: 183d9e7b112a ("pnfs: rework LAYOUTGET retry handling")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/pnfs.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
+index 1b4dd8b828de..9b2549222391 100644
+--- a/fs/nfs/pnfs.c
++++ b/fs/nfs/pnfs.c
+@@ -2152,6 +2152,12 @@ pnfs_update_layout(struct inode *ino,
+ case -ERECALLCONFLICT:
+ case -EAGAIN:
+ break;
++ case -ENODATA:
++ /* The server returned NFS4ERR_LAYOUTUNAVAILABLE */
++ pnfs_layout_set_fail_bit(
++ lo, pnfs_iomode_to_fail_bit(iomode));
++ lseg = NULL;
++ goto out_put_layout_hdr;
+ default:
+ if (!nfs_error_is_fatal(PTR_ERR(lseg))) {
+ pnfs_layout_clear_fail_bit(lo, pnfs_iomode_to_fail_bit(iomode));
+--
+2.35.1
+
platform-x86-gigabyte-wmi-add-z690m-aorus-elite-ax-d.patch
platform-x86-gigabyte-wmi-add-support-for-b450m-ds3h.patch
platform-x86-intel-hid-add-surface-go-to-vgbs-allow-.patch
+staging-r8188eu-fix-rtw_alloc_hwxmits-error-detectio.patch
+staging-r8188eu-fix-warning-of-array-overflow-in-ioc.patch
+pnfs-don-t-keep-retrying-if-the-server-replied-nfs4e.patch
+pnfs-avoid-a-live-lock-condition-in-pnfs_update_layo.patch
+sunrpc-set-cl_max_connect-when-cloning-an-rpc_clnt.patch
+clocksource-hyper-v-unexport-__init-annotated-hv_ini.patch
+i40e-fix-adding-adq-filter-to-tc0.patch
+i40e-fix-calculating-the-number-of-queue-pairs.patch
+i40e-fix-call-trace-in-setup_tx_descriptors.patch
+drivers-hv-vmbus-release-cpu-lock-in-error-case.patch
+tty-goldfish-fix-free_irq-on-remove.patch
+misc-atmel-ssc-fix-irq-check-in-ssc_probe.patch
+io_uring-fix-races-with-file-table-unregister.patch
+io_uring-fix-races-with-buffer-table-unregister.patch
+drm-i915-reset-fix-error_state_read-ptr-offset-use.patch
+net-hns3-set-port-base-vlan-tbl_sta-to-false-before-.patch
+net-hns3-don-t-push-link-state-to-vf-if-unalive.patch
+net-hns3-restore-tm-priority-qset-to-default-setting.patch
+net-hns3-fix-pf-rss-size-initialization-bug.patch
+net-hns3-fix-tm-port-shapping-of-fibre-port-is-incor.patch
+nvme-add-device-name-to-warning-in-uuid_show.patch
+mlxsw-spectrum_cnt-reorder-counter-pools.patch
+ice-fix-ptp-tx-timestamp-offset-calculation.patch
+ice-fix-queue-config-fail-handling.patch
+net-bgmac-fix-an-erroneous-kfree-in-bgmac_remove.patch
+net-ax25-fix-deadlock-caused-by-skb_recv_datagram-in.patch
+arm64-ftrace-fix-branch-range-checks.patch
+arm64-ftrace-consistently-handle-plts.patch
+certs-blacklist_hashes.c-fix-const-confusion-in-cert.patch
+init-initialize-noop_backing_dev_info-early.patch
+block-fix-handling-of-offline-queues-in-blk_mq_alloc.patch
--- /dev/null
+From c8791afb585e78ea84596ad0c12daf345a2d990f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 May 2022 21:47:41 +0100
+Subject: staging: r8188eu: fix rtw_alloc_hwxmits error detection for now
+
+From: Phillip Potter <phil@philpotter.co.uk>
+
+[ Upstream commit 5b7419ae1d208cab1e2826d473d8dab045aa75c7 ]
+
+In _rtw_init_xmit_priv, we use the res variable to store the error
+return from the newly converted rtw_alloc_hwxmits function. Sadly, the
+calling function interprets res using _SUCCESS and _FAIL still, meaning
+we change the semantics of the variable, even in the success case.
+
+This leads to the following on boot:
+r8188eu 1-2:1.0: _rtw_init_xmit_priv failed
+
+In the long term, we should reverse these semantics, but for now, this
+fixes the driver. Also, inside rtw_alloc_hwxmits remove the if blocks,
+as HWXMIT_ENTRY is always 4.
+
+Fixes: f94b47c6bde6 ("staging: r8188eu: add check for kzalloc")
+Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
+Link: https://lore.kernel.org/r/20220521204741.921-1-phil@philpotter.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/r8188eu/core/rtw_xmit.c | 20 +++++---------------
+ 1 file changed, 5 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/staging/r8188eu/core/rtw_xmit.c b/drivers/staging/r8188eu/core/rtw_xmit.c
+index f4e9f6102539..cc176ee29257 100644
+--- a/drivers/staging/r8188eu/core/rtw_xmit.c
++++ b/drivers/staging/r8188eu/core/rtw_xmit.c
+@@ -179,8 +179,7 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct adapter *padapter)
+
+ pxmitpriv->free_xmit_extbuf_cnt = num_xmit_extbuf;
+
+- res = rtw_alloc_hwxmits(padapter);
+- if (res) {
++ if (rtw_alloc_hwxmits(padapter)) {
+ res = _FAIL;
+ goto exit;
+ }
+@@ -1514,19 +1513,10 @@ int rtw_alloc_hwxmits(struct adapter *padapter)
+
+ hwxmits = pxmitpriv->hwxmits;
+
+- if (pxmitpriv->hwxmit_entry == 5) {
+- hwxmits[0] .sta_queue = &pxmitpriv->bm_pending;
+- hwxmits[1] .sta_queue = &pxmitpriv->vo_pending;
+- hwxmits[2] .sta_queue = &pxmitpriv->vi_pending;
+- hwxmits[3] .sta_queue = &pxmitpriv->bk_pending;
+- hwxmits[4] .sta_queue = &pxmitpriv->be_pending;
+- } else if (pxmitpriv->hwxmit_entry == 4) {
+- hwxmits[0] .sta_queue = &pxmitpriv->vo_pending;
+- hwxmits[1] .sta_queue = &pxmitpriv->vi_pending;
+- hwxmits[2] .sta_queue = &pxmitpriv->be_pending;
+- hwxmits[3] .sta_queue = &pxmitpriv->bk_pending;
+- } else {
+- }
++ hwxmits[0].sta_queue = &pxmitpriv->vo_pending;
++ hwxmits[1].sta_queue = &pxmitpriv->vi_pending;
++ hwxmits[2].sta_queue = &pxmitpriv->be_pending;
++ hwxmits[3].sta_queue = &pxmitpriv->bk_pending;
+
+ return 0;
+ }
+--
+2.35.1
+
--- /dev/null
+From c17dc52ec879a5fc755157321dc74a6a810a8623 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 30 May 2022 20:31:03 -0500
+Subject: staging: r8188eu: Fix warning of array overflow in ioctl_linux.c
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+[ Upstream commit 96f0a54e8e65a765b3a4ad4b53751581f23279f3 ]
+
+Building with -Warray-bounds results in the following warning plus others
+related to the same problem:
+
+CC [M] drivers/staging/r8188eu/os_dep/ioctl_linux.o
+In function ‘wpa_set_encryption’,
+ inlined from ‘rtw_wx_set_enc_ext’ at drivers/staging/r8188eu/os_dep/ioctl_linux.c:1868:9:
+drivers/staging/r8188eu/os_dep/ioctl_linux.c:412:41: warning: array subscript ‘struct ndis_802_11_wep[0]’ is partly outside array bounds of ‘void[25]’ [-Warray-bounds]
+ 412 | pwep->KeyLength = wep_key_len;
+ | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
+In file included from drivers/staging/r8188eu/os_dep/../include/osdep_service.h:19,
+ from drivers/staging/r8188eu/os_dep/ioctl_linux.c:4:
+In function ‘kmalloc’,
+ inlined from ‘kzalloc’ at ./include/linux/slab.h:733:9,
+ inlined from ‘wpa_set_encryption’ at drivers/staging/r8188eu/os_dep/ioctl_linux.c:408:11,
+ inlined from ‘rtw_wx_set_enc_ext’ at drivers/staging/r8188eu/os_dep/ioctl_linux.c:1868:9:
+./include/linux/slab.h:605:16: note: object of size [17, 25] allocated by ‘__kmalloc’
+ 605 | return __kmalloc(size, flags);
+ | ^~~~~~~~~~~~~~~~~~~~~~
+./include/linux/slab.h:600:24: note: object of size [17, 25] allocated by ‘kmem_cache_alloc_trace’
+ 600 | return kmem_cache_alloc_trace(
+ | ^~~~~~~~~~~~~~~~~~~~~~~
+ 601 | kmalloc_caches[kmalloc_type(flags)][index],
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 602 | flags, size);
+ | ~~~~~~~~~~~~
+
+Although it is unlikely that anyone is still using WEP encryption, the
+size of the allocation needs to be increased just in case.
+
+Fixes commit 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver")
+
+Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver")
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Cc: Phillip Potter <phil@philpotter.co.uk>
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/20220531013103.2175-3-Larry.Finger@lwfinger.net
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/r8188eu/os_dep/ioctl_linux.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/staging/r8188eu/os_dep/ioctl_linux.c b/drivers/staging/r8188eu/os_dep/ioctl_linux.c
+index dac2343569e5..ea20c177d3e4 100644
+--- a/drivers/staging/r8188eu/os_dep/ioctl_linux.c
++++ b/drivers/staging/r8188eu/os_dep/ioctl_linux.c
+@@ -416,7 +416,7 @@ static int wpa_set_encryption(struct net_device *dev, struct ieee_param *param,
+
+ if (wep_key_len > 0) {
+ wep_key_len = wep_key_len <= 5 ? 5 : 13;
+- wep_total_len = wep_key_len + FIELD_OFFSET(struct ndis_802_11_wep, KeyMaterial);
++ wep_total_len = wep_key_len + sizeof(*pwep);
+ pwep = kzalloc(wep_total_len, GFP_KERNEL);
+ if (!pwep)
+ goto exit;
+--
+2.35.1
+
--- /dev/null
+From 31d2c60cc35508a878244fb93b7c18fd6ed71196 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 1 Jun 2022 13:34:49 -0400
+Subject: sunrpc: set cl_max_connect when cloning an rpc_clnt
+
+From: Scott Mayhew <smayhew@redhat.com>
+
+[ Upstream commit 304791255a2dc1c9be7e7c8a6cbdb31b6847b0e5 ]
+
+If the initial attempt at trunking detection using the krb5i auth flavor
+fails with -EACCES, -NFS4ERR_CLID_INUSE, or -NFS4ERR_WRONGSEC, then the
+NFS client tries again using auth_sys, cloning the rpc_clnt in the
+process. If this second attempt at trunking detection succeeds, then
+the resulting nfs_client->cl_rpcclient winds up having cl_max_connect=0
+and subsequent attempts to add additional transport connections to the
+rpc_clnt will fail with a message similar to the following being logged:
+
+[502044.312640] SUNRPC: reached max allowed number (0) did not add
+transport to server: 192.168.122.3
+
+Signed-off-by: Scott Mayhew <smayhew@redhat.com>
+Fixes: dc48e0abee24 ("SUNRPC enforce creation of no more than max_connect xprts")
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sunrpc/clnt.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
+index 1dacd669faad..fe119f111eab 100644
+--- a/net/sunrpc/clnt.c
++++ b/net/sunrpc/clnt.c
+@@ -651,6 +651,7 @@ static struct rpc_clnt *__rpc_clone_client(struct rpc_create_args *args,
+ new->cl_discrtry = clnt->cl_discrtry;
+ new->cl_chatty = clnt->cl_chatty;
+ new->cl_principal = clnt->cl_principal;
++ new->cl_max_connect = clnt->cl_max_connect;
+ return new;
+
+ out_err:
+--
+2.35.1
+
--- /dev/null
+From 9a81e9d5a791b87ceb1b9eed3780a89d8166770a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 9 Jun 2022 16:17:04 +0200
+Subject: tty: goldfish: Fix free_irq() on remove
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ Upstream commit 499e13aac6c762e1e828172b0f0f5275651d6512 ]
+
+Pass the correct dev_id to free_irq() to fix this splat when the driver
+is unbound:
+
+ WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq
+ Trying to free already-free IRQ 65
+ Call Trace:
+ warn_slowpath_fmt
+ free_irq
+ goldfish_tty_remove
+ platform_remove
+ device_remove
+ device_release_driver_internal
+ device_driver_detach
+ unbind_store
+ drv_attr_store
+ ...
+
+Fixes: 465893e18878e119 ("tty: goldfish: support platform_device with id -1")
+Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Link: https://lore.kernel.org/r/20220609141704.1080024-1-vincent.whitchurch@axis.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/goldfish.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/tty/goldfish.c b/drivers/tty/goldfish.c
+index 9355d97ff591..65d8cb55edba 100644
+--- a/drivers/tty/goldfish.c
++++ b/drivers/tty/goldfish.c
+@@ -426,7 +426,7 @@ static int goldfish_tty_remove(struct platform_device *pdev)
+ tty_unregister_device(goldfish_tty_driver, qtty->console.index);
+ iounmap(qtty->base);
+ qtty->base = NULL;
+- free_irq(qtty->irq, pdev);
++ free_irq(qtty->irq, qtty);
+ tty_port_destroy(&qtty->port);
+ goldfish_tty_current_line_count--;
+ if (goldfish_tty_current_line_count == 0)
+--
+2.35.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
