]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 5.10
authorSasha Levin <sashal@kernel.org>
Sun, 13 Nov 2022 22:41:32 +0000 (17:41 -0500)
committerSasha Levin <sashal@kernel.org>
Sun, 13 Nov 2022 22:41:32 +0000 (17:41 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
54 files changed:
queue-5.10/bnxt_en-fix-possible-crash-in-bnxt_hwrm_set_coal.patch [new file with mode: 0644]
queue-5.10/bnxt_en-fix-potentially-incorrect-return-value-for-n.patch [new file with mode: 0644]
queue-5.10/bpf-add-helper-macro-bpf_for_each_reg_in_vstate.patch [new file with mode: 0644]
queue-5.10/bpf-fix-wrong-reg-type-conversion-in-release_referen.patch [new file with mode: 0644]
queue-5.10/bpf-sockmap-fix-the-sk-sk_forward_alloc-warning-of-s.patch [new file with mode: 0644]
queue-5.10/bpf-support-for-pointers-beyond-pkt_end.patch [new file with mode: 0644]
queue-5.10/bpftool-fix-null-pointer-dereference-when-pin-prog-m.patch [new file with mode: 0644]
queue-5.10/can-af_can-fix-null-pointer-dereference-in-can_rx_re.patch [new file with mode: 0644]
queue-5.10/capabilities-fix-undefined-behavior-in-bit-shift-for.patch [new file with mode: 0644]
queue-5.10/cxgb4vf-shut-down-the-adapter-when-t4vf_update_port_.patch [new file with mode: 0644]
queue-5.10/dmaengine-mv_xor_v2-fix-a-resource-leak-in-mv_xor_v2.patch [new file with mode: 0644]
queue-5.10/dmaengine-pxa_dma-use-platform_get_irq_optional.patch [new file with mode: 0644]
queue-5.10/drivers-net-xgene-disable-napi-when-register-irq-fai.patch [new file with mode: 0644]
queue-5.10/drm-vc4-fix-missing-platform_unregister_drivers-call.patch [new file with mode: 0644]
queue-5.10/ethernet-s2io-disable-napi-when-start-nic-failed-in-.patch [new file with mode: 0644]
queue-5.10/ethernet-tundra-free-irq-when-alloc-ring-failed-in-t.patch [new file with mode: 0644]
queue-5.10/hamradio-fix-issue-of-dev-reference-count-leakage-in.patch [new file with mode: 0644]
queue-5.10/hid-hyperv-fix-possible-memory-leak-in-mousevsc_prob.patch [new file with mode: 0644]
queue-5.10/hwspinlock-qcom-correct-mmio-max-register-for-newer-.patch [new file with mode: 0644]
queue-5.10/ipv6-addrlabel-fix-infoleak-when-sending-struct-ifad.patch [new file with mode: 0644]
queue-5.10/kvm-s390-pv-don-t-allow-userspace-to-set-the-clock-u.patch [new file with mode: 0644]
queue-5.10/kvm-s390x-fix-sck-locking.patch [new file with mode: 0644]
queue-5.10/macsec-clear-encryption-keys-from-the-stack-after-se.patch [new file with mode: 0644]
queue-5.10/macsec-delete-new-rxsc-when-offload-fails.patch [new file with mode: 0644]
queue-5.10/macsec-fix-detection-of-rxscs-when-toggling-offloadi.patch [new file with mode: 0644]
queue-5.10/macsec-fix-secy-n_rx_sc-accounting.patch [new file with mode: 0644]
queue-5.10/net-atlantic-macsec-clear-encryption-keys-from-the-s.patch [new file with mode: 0644]
queue-5.10/net-broadcom-fix-bcmgenet-kconfig.patch [new file with mode: 0644]
queue-5.10/net-cpsw-disable-napi-in-cpsw_ndo_open.patch [new file with mode: 0644]
queue-5.10/net-cxgb3_main-disable-napi-when-bind-qsets-failed-i.patch [new file with mode: 0644]
queue-5.10/net-fman-unregister-ethernet-device-on-removal.patch [new file with mode: 0644]
queue-5.10/net-gso-fix-panic-on-frag_list-with-mixed-head-alloc.patch [new file with mode: 0644]
queue-5.10/net-lapbether-fix-issue-of-dev-reference-count-leaka.patch [new file with mode: 0644]
queue-5.10/net-macvlan-fix-memory-leaks-of-macvlan_common_newli.patch [new file with mode: 0644]
queue-5.10/net-marvell-prestera-fix-memory-leak-in-prestera_rxt.patch [new file with mode: 0644]
queue-5.10/net-mlx5-allow-async-trigger-completion-execution-on.patch [new file with mode: 0644]
queue-5.10/net-mlx5e-e-switch-fix-comparing-termination-table-i.patch [new file with mode: 0644]
queue-5.10/net-mv643xx_eth-disable-napi-when-init-rxq-or-txq-fa.patch [new file with mode: 0644]
queue-5.10/net-nixge-disable-napi-when-enable-interrupts-failed.patch [new file with mode: 0644]
queue-5.10/net-phy-mscc-macsec-clear-encryption-keys-when-freei.patch [new file with mode: 0644]
queue-5.10/net-stmmac-dwmac-meson8b-fix-meson8b_devm_clk_prepar.patch [new file with mode: 0644]
queue-5.10/net-tun-fix-memory-leaks-of-napi_get_frags.patch [new file with mode: 0644]
queue-5.10/perf-stat-fix-printing-os-prefix-in-csv-metrics-outp.patch [new file with mode: 0644]
queue-5.10/phy-stm32-fix-an-error-code-in-probe.patch [new file with mode: 0644]
queue-5.10/riscv-enable-cma-support.patch [new file with mode: 0644]
queue-5.10/riscv-fix-reserved-memory-setup.patch [new file with mode: 0644]
queue-5.10/riscv-process-fix-kernel-info-leakage.patch [new file with mode: 0644]
queue-5.10/riscv-separate-memory-init-from-paging-init.patch [new file with mode: 0644]
queue-5.10/riscv-vdso-fix-build-with-llvm.patch [new file with mode: 0644]
queue-5.10/series
queue-5.10/tcp-prohibit-tcp_repair_options-if-data-was-already-.patch [new file with mode: 0644]
queue-5.10/tipc-fix-the-msg-req-tlv-len-check-in-tipc_nl_compat.patch [new file with mode: 0644]
queue-5.10/wifi-cfg80211-fix-memory-leak-in-query_regdb_file.patch [new file with mode: 0644]
queue-5.10/wifi-cfg80211-silence-a-sparse-rcu-warning.patch [new file with mode: 0644]

diff --git a/queue-5.10/bnxt_en-fix-possible-crash-in-bnxt_hwrm_set_coal.patch b/queue-5.10/bnxt_en-fix-possible-crash-in-bnxt_hwrm_set_coal.patch
new file mode 100644 (file)
index 0000000..0915108
--- /dev/null
@@ -0,0 +1,81 @@
+From 66ba29cc0101a47d9bbdcec25bf972a99f6d4317 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 19:33:26 -0400
+Subject: bnxt_en: Fix possible crash in bnxt_hwrm_set_coal()
+
+From: Michael Chan <michael.chan@broadcom.com>
+
+[ Upstream commit 6d81ea3765dfa6c8a20822613c81edad1c4a16a0 ]
+
+During the error recovery sequence, the rtnl_lock is not held for the
+entire duration and some datastructures may be freed during the sequence.
+Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure
+that the device is fully operational before proceeding to reconfigure
+the coalescing settings.
+
+This will fix a possible crash like this:
+
+BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
+PGD 0 P4D 0
+Oops: 0000 [#1] SMP NOPTI
+CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-348.el8.x86_64 #1
+Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019
+RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en]
+Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6
+RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246
+RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5
+RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28
+RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000
+R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c
+R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0
+FS:  00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000
+CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+PKRU: 55555554
+Call Trace:
+ ethnl_set_coalesce+0x3ce/0x4c0
+ genl_family_rcv_msg_doit.isra.15+0x10f/0x150
+ genl_family_rcv_msg+0xb3/0x160
+ ? coalesce_fill_reply+0x480/0x480
+ genl_rcv_msg+0x47/0x90
+ ? genl_family_rcv_msg+0x160/0x160
+ netlink_rcv_skb+0x4c/0x120
+ genl_rcv+0x24/0x40
+ netlink_unicast+0x196/0x230
+ netlink_sendmsg+0x204/0x3d0
+ sock_sendmsg+0x4c/0x50
+ __sys_sendto+0xee/0x160
+ ? syscall_trace_enter+0x1d3/0x2c0
+ ? __audit_syscall_exit+0x249/0x2a0
+ __x64_sys_sendto+0x24/0x30
+ do_syscall_64+0x5b/0x1a0
+ entry_SYSCALL_64_after_hwframe+0x65/0xca
+RIP: 0033:0x7f38524163bb
+
+Fixes: 2151fe0830fd ("bnxt_en: Handle RESET_NOTIFY async event from firmware.")
+Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
+Signed-off-by: Michael Chan <michael.chan@broadcom.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+index f8f775619520..81b63d1c2391 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+@@ -125,7 +125,7 @@ static int bnxt_set_coalesce(struct net_device *dev,
+       }
+ reset_coalesce:
+-      if (netif_running(dev)) {
++      if (test_bit(BNXT_STATE_OPEN, &bp->state)) {
+               if (update_stats) {
+                       rc = bnxt_close_nic(bp, true, false);
+                       if (!rc)
+-- 
+2.35.1
+
diff --git a/queue-5.10/bnxt_en-fix-potentially-incorrect-return-value-for-n.patch b/queue-5.10/bnxt_en-fix-potentially-incorrect-return-value-for-n.patch
new file mode 100644 (file)
index 0000000..c88c091
--- /dev/null
@@ -0,0 +1,45 @@
+From 2b4962f6b680e9b0d0923b2859f36745468ce02b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 19:33:27 -0400
+Subject: bnxt_en: fix potentially incorrect return value for ndo_rx_flow_steer
+
+From: Alex Barba <alex.barba@broadcom.com>
+
+[ Upstream commit 02597d39145bb0aa81d04bf39b6a913ce9a9d465 ]
+
+In the bnxt_en driver ndo_rx_flow_steer returns '0' whenever an entry
+that we are attempting to steer is already found.  This is not the
+correct behavior.  The return code should be the value/index that
+corresponds to the entry.  Returning zero all the time causes the
+RFS records to be incorrect unless entry '0' is the correct one.  As
+flows migrate to different cores this can create entries that are not
+correct.
+
+Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
+Reported-by: Akshay Navgire <anavgire@purestorage.com>
+Signed-off-by: Alex Barba <alex.barba@broadcom.com>
+Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
+Signed-off-by: Michael Chan <michael.chan@broadcom.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+index b818d5f342d5..8311473d537b 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+@@ -12008,8 +12008,8 @@ static int bnxt_rx_flow_steer(struct net_device *dev, const struct sk_buff *skb,
+       rcu_read_lock();
+       hlist_for_each_entry_rcu(fltr, head, hash) {
+               if (bnxt_fltr_match(fltr, new_fltr)) {
++                      rc = fltr->sw_id;
+                       rcu_read_unlock();
+-                      rc = 0;
+                       goto err_free;
+               }
+       }
+-- 
+2.35.1
+
diff --git a/queue-5.10/bpf-add-helper-macro-bpf_for_each_reg_in_vstate.patch b/queue-5.10/bpf-add-helper-macro-bpf_for_each_reg_in_vstate.patch
new file mode 100644 (file)
index 0000000..64e0cc6
--- /dev/null
@@ -0,0 +1,304 @@
+From 94bed4537a530f0c381670c5aa9294cb67e8c6d9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 4 Sep 2022 22:41:28 +0200
+Subject: bpf: Add helper macro bpf_for_each_reg_in_vstate
+
+From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
+
+[ Upstream commit b239da34203f49c40b5d656220c39647c3ff0b3c ]
+
+For a lot of use cases in future patches, we will want to modify the
+state of registers part of some same 'group' (e.g. same ref_obj_id). It
+won't just be limited to releasing reference state, but setting a type
+flag dynamically based on certain actions, etc.
+
+Hence, we need a way to easily pass a callback to the function that
+iterates over all registers in current bpf_verifier_state in all frames
+upto (and including) the curframe.
+
+While in C++ we would be able to easily use a lambda to pass state and
+the callback together, sadly we aren't using C++ in the kernel. The next
+best thing to avoid defining a function for each case seems like
+statement expressions in GNU C. The kernel already uses them heavily,
+hence they can passed to the macro in the style of a lambda. The
+statement expression will then be substituted in the for loop bodies.
+
+Variables __state and __reg are set to current bpf_func_state and reg
+for each invocation of the expression inside the passed in verifier
+state.
+
+Then, convert mark_ptr_or_null_regs, clear_all_pkt_pointers,
+release_reference, find_good_pkt_pointers, find_equal_scalars to
+use bpf_for_each_reg_in_vstate.
+
+Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
+Link: https://lore.kernel.org/r/20220904204145.3089-16-memxor@gmail.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Stable-dep-of: f1db20814af5 ("bpf: Fix wrong reg type conversion in release_reference()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/bpf_verifier.h |  21 ++++++
+ kernel/bpf/verifier.c        | 135 ++++++++---------------------------
+ 2 files changed, 49 insertions(+), 107 deletions(-)
+
+diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
+index f49165f9229c..4d37c69e76b1 100644
+--- a/include/linux/bpf_verifier.h
++++ b/include/linux/bpf_verifier.h
+@@ -290,6 +290,27 @@ struct bpf_verifier_state {
+            iter < frame->allocated_stack / BPF_REG_SIZE;              \
+            iter++, reg = bpf_get_spilled_reg(iter, frame))
++/* Invoke __expr over regsiters in __vst, setting __state and __reg */
++#define bpf_for_each_reg_in_vstate(__vst, __state, __reg, __expr)   \
++      ({                                                               \
++              struct bpf_verifier_state *___vstate = __vst;            \
++              int ___i, ___j;                                          \
++              for (___i = 0; ___i <= ___vstate->curframe; ___i++) {    \
++                      struct bpf_reg_state *___regs;                   \
++                      __state = ___vstate->frame[___i];                \
++                      ___regs = __state->regs;                         \
++                      for (___j = 0; ___j < MAX_BPF_REG; ___j++) {     \
++                              __reg = &___regs[___j];                  \
++                              (void)(__expr);                          \
++                      }                                                \
++                      bpf_for_each_spilled_reg(___j, __state, __reg) { \
++                              if (!__reg)                              \
++                                      continue;                        \
++                              (void)(__expr);                          \
++                      }                                                \
++              }                                                        \
++      })
++
+ /* linked list of verifier states used to prune search */
+ struct bpf_verifier_state_list {
+       struct bpf_verifier_state state;
+diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
+index 510a54471f13..3a0f288f538c 100644
+--- a/kernel/bpf/verifier.c
++++ b/kernel/bpf/verifier.c
+@@ -4993,31 +4993,15 @@ static int check_func_proto(const struct bpf_func_proto *fn, int func_id)
+ /* Packet data might have moved, any old PTR_TO_PACKET[_META,_END]
+  * are now invalid, so turn them into unknown SCALAR_VALUE.
+  */
+-static void __clear_all_pkt_pointers(struct bpf_verifier_env *env,
+-                                   struct bpf_func_state *state)
++static void clear_all_pkt_pointers(struct bpf_verifier_env *env)
+ {
+-      struct bpf_reg_state *regs = state->regs, *reg;
+-      int i;
+-
+-      for (i = 0; i < MAX_BPF_REG; i++)
+-              if (reg_is_pkt_pointer_any(&regs[i]))
+-                      mark_reg_unknown(env, regs, i);
++      struct bpf_func_state *state;
++      struct bpf_reg_state *reg;
+-      bpf_for_each_spilled_reg(i, state, reg) {
+-              if (!reg)
+-                      continue;
++      bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
+               if (reg_is_pkt_pointer_any(reg))
+                       __mark_reg_unknown(env, reg);
+-      }
+-}
+-
+-static void clear_all_pkt_pointers(struct bpf_verifier_env *env)
+-{
+-      struct bpf_verifier_state *vstate = env->cur_state;
+-      int i;
+-
+-      for (i = 0; i <= vstate->curframe; i++)
+-              __clear_all_pkt_pointers(env, vstate->frame[i]);
++      }));
+ }
+ enum {
+@@ -5046,41 +5030,24 @@ static void mark_pkt_end(struct bpf_verifier_state *vstate, int regn, bool range
+               reg->range = AT_PKT_END;
+ }
+-static void release_reg_references(struct bpf_verifier_env *env,
+-                                 struct bpf_func_state *state,
+-                                 int ref_obj_id)
+-{
+-      struct bpf_reg_state *regs = state->regs, *reg;
+-      int i;
+-
+-      for (i = 0; i < MAX_BPF_REG; i++)
+-              if (regs[i].ref_obj_id == ref_obj_id)
+-                      mark_reg_unknown(env, regs, i);
+-
+-      bpf_for_each_spilled_reg(i, state, reg) {
+-              if (!reg)
+-                      continue;
+-              if (reg->ref_obj_id == ref_obj_id)
+-                      __mark_reg_unknown(env, reg);
+-      }
+-}
+-
+ /* The pointer with the specified id has released its reference to kernel
+  * resources. Identify all copies of the same pointer and clear the reference.
+  */
+ static int release_reference(struct bpf_verifier_env *env,
+                            int ref_obj_id)
+ {
+-      struct bpf_verifier_state *vstate = env->cur_state;
++      struct bpf_func_state *state;
++      struct bpf_reg_state *reg;
+       int err;
+-      int i;
+       err = release_reference_state(cur_func(env), ref_obj_id);
+       if (err)
+               return err;
+-      for (i = 0; i <= vstate->curframe; i++)
+-              release_reg_references(env, vstate->frame[i], ref_obj_id);
++      bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
++              if (reg->ref_obj_id == ref_obj_id)
++                      __mark_reg_unknown(env, reg);
++      }));
+       return 0;
+ }
+@@ -7219,34 +7186,14 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
+       return 0;
+ }
+-static void __find_good_pkt_pointers(struct bpf_func_state *state,
+-                                   struct bpf_reg_state *dst_reg,
+-                                   enum bpf_reg_type type, int new_range)
+-{
+-      struct bpf_reg_state *reg;
+-      int i;
+-
+-      for (i = 0; i < MAX_BPF_REG; i++) {
+-              reg = &state->regs[i];
+-              if (reg->type == type && reg->id == dst_reg->id)
+-                      /* keep the maximum range already checked */
+-                      reg->range = max(reg->range, new_range);
+-      }
+-
+-      bpf_for_each_spilled_reg(i, state, reg) {
+-              if (!reg)
+-                      continue;
+-              if (reg->type == type && reg->id == dst_reg->id)
+-                      reg->range = max(reg->range, new_range);
+-      }
+-}
+-
+ static void find_good_pkt_pointers(struct bpf_verifier_state *vstate,
+                                  struct bpf_reg_state *dst_reg,
+                                  enum bpf_reg_type type,
+                                  bool range_right_open)
+ {
+-      int new_range, i;
++      struct bpf_func_state *state;
++      struct bpf_reg_state *reg;
++      int new_range;
+       if (dst_reg->off < 0 ||
+           (dst_reg->off == 0 && range_right_open))
+@@ -7311,9 +7258,11 @@ static void find_good_pkt_pointers(struct bpf_verifier_state *vstate,
+        * the range won't allow anything.
+        * dst_reg->off is known < MAX_PACKET_OFF, therefore it fits in a u16.
+        */
+-      for (i = 0; i <= vstate->curframe; i++)
+-              __find_good_pkt_pointers(vstate->frame[i], dst_reg, type,
+-                                       new_range);
++      bpf_for_each_reg_in_vstate(vstate, state, reg, ({
++              if (reg->type == type && reg->id == dst_reg->id)
++                      /* keep the maximum range already checked */
++                      reg->range = max(reg->range, new_range);
++      }));
+ }
+ static int is_branch32_taken(struct bpf_reg_state *reg, u32 val, u8 opcode)
+@@ -7826,7 +7775,7 @@ static void mark_ptr_or_null_reg(struct bpf_func_state *state,
+                       reg->ref_obj_id = 0;
+               } else if (!reg_may_point_to_spin_lock(reg)) {
+                       /* For not-NULL ptr, reg->ref_obj_id will be reset
+-                       * in release_reg_references().
++                       * in release_reference().
+                        *
+                        * reg->id is still used by spin_lock ptr. Other
+                        * than spin_lock ptr type, reg->id can be reset.
+@@ -7836,22 +7785,6 @@ static void mark_ptr_or_null_reg(struct bpf_func_state *state,
+       }
+ }
+-static void __mark_ptr_or_null_regs(struct bpf_func_state *state, u32 id,
+-                                  bool is_null)
+-{
+-      struct bpf_reg_state *reg;
+-      int i;
+-
+-      for (i = 0; i < MAX_BPF_REG; i++)
+-              mark_ptr_or_null_reg(state, &state->regs[i], id, is_null);
+-
+-      bpf_for_each_spilled_reg(i, state, reg) {
+-              if (!reg)
+-                      continue;
+-              mark_ptr_or_null_reg(state, reg, id, is_null);
+-      }
+-}
+-
+ /* The logic is similar to find_good_pkt_pointers(), both could eventually
+  * be folded together at some point.
+  */
+@@ -7859,10 +7792,9 @@ static void mark_ptr_or_null_regs(struct bpf_verifier_state *vstate, u32 regno,
+                                 bool is_null)
+ {
+       struct bpf_func_state *state = vstate->frame[vstate->curframe];
+-      struct bpf_reg_state *regs = state->regs;
++      struct bpf_reg_state *regs = state->regs, *reg;
+       u32 ref_obj_id = regs[regno].ref_obj_id;
+       u32 id = regs[regno].id;
+-      int i;
+       if (ref_obj_id && ref_obj_id == id && is_null)
+               /* regs[regno] is in the " == NULL" branch.
+@@ -7871,8 +7803,9 @@ static void mark_ptr_or_null_regs(struct bpf_verifier_state *vstate, u32 regno,
+                */
+               WARN_ON_ONCE(release_reference_state(state, id));
+-      for (i = 0; i <= vstate->curframe; i++)
+-              __mark_ptr_or_null_regs(vstate->frame[i], id, is_null);
++      bpf_for_each_reg_in_vstate(vstate, state, reg, ({
++              mark_ptr_or_null_reg(state, reg, id, is_null);
++      }));
+ }
+ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+@@ -7985,23 +7918,11 @@ static void find_equal_scalars(struct bpf_verifier_state *vstate,
+ {
+       struct bpf_func_state *state;
+       struct bpf_reg_state *reg;
+-      int i, j;
+-      for (i = 0; i <= vstate->curframe; i++) {
+-              state = vstate->frame[i];
+-              for (j = 0; j < MAX_BPF_REG; j++) {
+-                      reg = &state->regs[j];
+-                      if (reg->type == SCALAR_VALUE && reg->id == known_reg->id)
+-                              *reg = *known_reg;
+-              }
+-
+-              bpf_for_each_spilled_reg(j, state, reg) {
+-                      if (!reg)
+-                              continue;
+-                      if (reg->type == SCALAR_VALUE && reg->id == known_reg->id)
+-                              *reg = *known_reg;
+-              }
+-      }
++      bpf_for_each_reg_in_vstate(vstate, state, reg, ({
++              if (reg->type == SCALAR_VALUE && reg->id == known_reg->id)
++                      *reg = *known_reg;
++      }));
+ }
+ static int check_cond_jmp_op(struct bpf_verifier_env *env,
+-- 
+2.35.1
+
diff --git a/queue-5.10/bpf-fix-wrong-reg-type-conversion-in-release_referen.patch b/queue-5.10/bpf-fix-wrong-reg-type-conversion-in-release_referen.patch
new file mode 100644 (file)
index 0000000..102f8fe
--- /dev/null
@@ -0,0 +1,56 @@
+From 612513b535523e7fa83913f656af6baaa470b66d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 17:34:39 +0800
+Subject: bpf: Fix wrong reg type conversion in release_reference()
+
+From: Youlin Li <liulin063@gmail.com>
+
+[ Upstream commit f1db20814af532f85e091231223e5e4818e8464b ]
+
+Some helper functions will allocate memory. To avoid memory leaks, the
+verifier requires the eBPF program to release these memories by calling
+the corresponding helper functions.
+
+When a resource is released, all pointer registers corresponding to the
+resource should be invalidated. The verifier use release_references() to
+do this job, by apply  __mark_reg_unknown() to each relevant register.
+
+It will give these registers the type of SCALAR_VALUE. A register that
+will contain a pointer value at runtime, but of type SCALAR_VALUE, which
+may allow the unprivileged user to get a kernel pointer by storing this
+register into a map.
+
+Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this
+problem.
+
+Fixes: fd978bf7fd31 ("bpf: Add reference tracking to verifier")
+Signed-off-by: Youlin Li <liulin063@gmail.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Link: https://lore.kernel.org/bpf/20221103093440.3161-1-liulin063@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/bpf/verifier.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
+index 3a0f288f538c..50364031eb4d 100644
+--- a/kernel/bpf/verifier.c
++++ b/kernel/bpf/verifier.c
+@@ -5045,8 +5045,12 @@ static int release_reference(struct bpf_verifier_env *env,
+               return err;
+       bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
+-              if (reg->ref_obj_id == ref_obj_id)
+-                      __mark_reg_unknown(env, reg);
++              if (reg->ref_obj_id == ref_obj_id) {
++                      if (!env->allow_ptr_leaks)
++                              __mark_reg_not_init(env, reg);
++                      else
++                              __mark_reg_unknown(env, reg);
++              }
+       }));
+       return 0;
+-- 
+2.35.1
+
diff --git a/queue-5.10/bpf-sockmap-fix-the-sk-sk_forward_alloc-warning-of-s.patch b/queue-5.10/bpf-sockmap-fix-the-sk-sk_forward_alloc-warning-of-s.patch
new file mode 100644 (file)
index 0000000..4da7c59
--- /dev/null
@@ -0,0 +1,90 @@
+From 1f68f3bdec00071ef477bb045988174b769437c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 09:31:36 +0800
+Subject: bpf, sockmap: Fix the sk->sk_forward_alloc warning of
+ sk_stream_kill_queues
+
+From: Wang Yufen <wangyufen@huawei.com>
+
+[ Upstream commit 8ec95b94716a1e4d126edc3fb2bc426a717e2dba ]
+
+When running `test_sockmap` selftests, the following warning appears:
+
+  WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0
+  Call Trace:
+  <TASK>
+  inet_csk_destroy_sock+0x55/0x110
+  tcp_rcv_state_process+0xd28/0x1380
+  ? tcp_v4_do_rcv+0x77/0x2c0
+  tcp_v4_do_rcv+0x77/0x2c0
+  __release_sock+0x106/0x130
+  __tcp_close+0x1a7/0x4e0
+  tcp_close+0x20/0x70
+  inet_release+0x3c/0x80
+  __sock_release+0x3a/0xb0
+  sock_close+0x14/0x20
+  __fput+0xa3/0x260
+  task_work_run+0x59/0xb0
+  exit_to_user_mode_prepare+0x1b3/0x1c0
+  syscall_exit_to_user_mode+0x19/0x50
+  do_syscall_64+0x48/0x90
+  entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged
+while msg has more_data"), where I used msg->sg.size to replace the tosend,
+causing breakage:
+
+  if (msg->apply_bytes && msg->apply_bytes < tosend)
+    tosend = psock->apply_bytes;
+
+Fixes: 84472b436e76 ("bpf, sockmap: Fix more uncharged while msg has more_data")
+Reported-by: Jakub Sitnicki <jakub@cloudflare.com>
+Signed-off-by: Wang Yufen <wangyufen@huawei.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
+Link: https://lore.kernel.org/bpf/1667266296-8794-1-git-send-email-wangyufen@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/tcp_bpf.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
+index eaf2308c355a..809ee0f32d59 100644
+--- a/net/ipv4/tcp_bpf.c
++++ b/net/ipv4/tcp_bpf.c
+@@ -315,7 +315,7 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock,
+ {
+       bool cork = false, enospc = sk_msg_full(msg);
+       struct sock *sk_redir;
+-      u32 tosend, delta = 0;
++      u32 tosend, origsize, sent, delta = 0;
+       u32 eval = __SK_NONE;
+       int ret;
+@@ -370,10 +370,12 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock,
+                       cork = true;
+                       psock->cork = NULL;
+               }
+-              sk_msg_return(sk, msg, msg->sg.size);
++              sk_msg_return(sk, msg, tosend);
+               release_sock(sk);
++              origsize = msg->sg.size;
+               ret = tcp_bpf_sendmsg_redir(sk_redir, msg, tosend, flags);
++              sent = origsize - msg->sg.size;
+               if (eval == __SK_REDIRECT)
+                       sock_put(sk_redir);
+@@ -412,7 +414,7 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock,
+                   msg->sg.data[msg->sg.start].page_link &&
+                   msg->sg.data[msg->sg.start].length) {
+                       if (eval == __SK_REDIRECT)
+-                              sk_mem_charge(sk, msg->sg.size);
++                              sk_mem_charge(sk, tosend - sent);
+                       goto more_data;
+               }
+       }
+-- 
+2.35.1
+
diff --git a/queue-5.10/bpf-support-for-pointers-beyond-pkt_end.patch b/queue-5.10/bpf-support-for-pointers-beyond-pkt_end.patch
new file mode 100644 (file)
index 0000000..dabe165
--- /dev/null
@@ -0,0 +1,300 @@
+From 079226cf63103476b1bcbda035e4c279a5119f24 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Nov 2020 19:12:11 -0800
+Subject: bpf: Support for pointers beyond pkt_end.
+
+From: Alexei Starovoitov <ast@kernel.org>
+
+[ Upstream commit 6d94e741a8ff818e5518da8257f5ca0aaed1f269 ]
+
+This patch adds the verifier support to recognize inlined branch conditions.
+The LLVM knows that the branch evaluates to the same value, but the verifier
+couldn't track it. Hence causing valid programs to be rejected.
+The potential LLVM workaround: https://reviews.llvm.org/D87428
+can have undesired side effects, since LLVM doesn't know that
+skb->data/data_end are being compared. LLVM has to introduce extra boolean
+variable and use inline_asm trick to force easier for the verifier assembly.
+
+Instead teach the verifier to recognize that
+r1 = skb->data;
+r1 += 10;
+r2 = skb->data_end;
+if (r1 > r2) {
+  here r1 points beyond packet_end and
+  subsequent
+  if (r1 > r2) // always evaluates to "true".
+}
+
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Tested-by: Jiri Olsa <jolsa@redhat.com>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Link: https://lore.kernel.org/bpf/20201111031213.25109-2-alexei.starovoitov@gmail.com
+Stable-dep-of: f1db20814af5 ("bpf: Fix wrong reg type conversion in release_reference()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/bpf_verifier.h |   2 +-
+ kernel/bpf/verifier.c        | 129 +++++++++++++++++++++++++++++------
+ 2 files changed, 108 insertions(+), 23 deletions(-)
+
+diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
+index 391bc1480dfb..f49165f9229c 100644
+--- a/include/linux/bpf_verifier.h
++++ b/include/linux/bpf_verifier.h
+@@ -45,7 +45,7 @@ struct bpf_reg_state {
+       enum bpf_reg_type type;
+       union {
+               /* valid when type == PTR_TO_PACKET */
+-              u16 range;
++              int range;
+               /* valid when type == CONST_PTR_TO_MAP | PTR_TO_MAP_VALUE |
+                *   PTR_TO_MAP_VALUE_OR_NULL
+diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
+index e4dcc23b52c0..510a54471f13 100644
+--- a/kernel/bpf/verifier.c
++++ b/kernel/bpf/verifier.c
+@@ -2978,7 +2978,9 @@ static int check_packet_access(struct bpf_verifier_env *env, u32 regno, int off,
+                       regno);
+               return -EACCES;
+       }
+-      err = __check_mem_access(env, regno, off, size, reg->range,
++
++      err = reg->range < 0 ? -EINVAL :
++            __check_mem_access(env, regno, off, size, reg->range,
+                                zero_size_allowed);
+       if (err) {
+               verbose(env, "R%d offset is outside of the packet\n", regno);
+@@ -5018,6 +5020,32 @@ static void clear_all_pkt_pointers(struct bpf_verifier_env *env)
+               __clear_all_pkt_pointers(env, vstate->frame[i]);
+ }
++enum {
++      AT_PKT_END = -1,
++      BEYOND_PKT_END = -2,
++};
++
++static void mark_pkt_end(struct bpf_verifier_state *vstate, int regn, bool range_open)
++{
++      struct bpf_func_state *state = vstate->frame[vstate->curframe];
++      struct bpf_reg_state *reg = &state->regs[regn];
++
++      if (reg->type != PTR_TO_PACKET)
++              /* PTR_TO_PACKET_META is not supported yet */
++              return;
++
++      /* The 'reg' is pkt > pkt_end or pkt >= pkt_end.
++       * How far beyond pkt_end it goes is unknown.
++       * if (!range_open) it's the case of pkt >= pkt_end
++       * if (range_open) it's the case of pkt > pkt_end
++       * hence this pointer is at least 1 byte bigger than pkt_end
++       */
++      if (range_open)
++              reg->range = BEYOND_PKT_END;
++      else
++              reg->range = AT_PKT_END;
++}
++
+ static void release_reg_references(struct bpf_verifier_env *env,
+                                  struct bpf_func_state *state,
+                                  int ref_obj_id)
+@@ -7193,7 +7221,7 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
+ static void __find_good_pkt_pointers(struct bpf_func_state *state,
+                                    struct bpf_reg_state *dst_reg,
+-                                   enum bpf_reg_type type, u16 new_range)
++                                   enum bpf_reg_type type, int new_range)
+ {
+       struct bpf_reg_state *reg;
+       int i;
+@@ -7218,8 +7246,7 @@ static void find_good_pkt_pointers(struct bpf_verifier_state *vstate,
+                                  enum bpf_reg_type type,
+                                  bool range_right_open)
+ {
+-      u16 new_range;
+-      int i;
++      int new_range, i;
+       if (dst_reg->off < 0 ||
+           (dst_reg->off == 0 && range_right_open))
+@@ -7470,6 +7497,67 @@ static int is_branch_taken(struct bpf_reg_state *reg, u64 val, u8 opcode,
+       return is_branch64_taken(reg, val, opcode);
+ }
++static int flip_opcode(u32 opcode)
++{
++      /* How can we transform "a <op> b" into "b <op> a"? */
++      static const u8 opcode_flip[16] = {
++              /* these stay the same */
++              [BPF_JEQ  >> 4] = BPF_JEQ,
++              [BPF_JNE  >> 4] = BPF_JNE,
++              [BPF_JSET >> 4] = BPF_JSET,
++              /* these swap "lesser" and "greater" (L and G in the opcodes) */
++              [BPF_JGE  >> 4] = BPF_JLE,
++              [BPF_JGT  >> 4] = BPF_JLT,
++              [BPF_JLE  >> 4] = BPF_JGE,
++              [BPF_JLT  >> 4] = BPF_JGT,
++              [BPF_JSGE >> 4] = BPF_JSLE,
++              [BPF_JSGT >> 4] = BPF_JSLT,
++              [BPF_JSLE >> 4] = BPF_JSGE,
++              [BPF_JSLT >> 4] = BPF_JSGT
++      };
++      return opcode_flip[opcode >> 4];
++}
++
++static int is_pkt_ptr_branch_taken(struct bpf_reg_state *dst_reg,
++                                 struct bpf_reg_state *src_reg,
++                                 u8 opcode)
++{
++      struct bpf_reg_state *pkt;
++
++      if (src_reg->type == PTR_TO_PACKET_END) {
++              pkt = dst_reg;
++      } else if (dst_reg->type == PTR_TO_PACKET_END) {
++              pkt = src_reg;
++              opcode = flip_opcode(opcode);
++      } else {
++              return -1;
++      }
++
++      if (pkt->range >= 0)
++              return -1;
++
++      switch (opcode) {
++      case BPF_JLE:
++              /* pkt <= pkt_end */
++              fallthrough;
++      case BPF_JGT:
++              /* pkt > pkt_end */
++              if (pkt->range == BEYOND_PKT_END)
++                      /* pkt has at last one extra byte beyond pkt_end */
++                      return opcode == BPF_JGT;
++              break;
++      case BPF_JLT:
++              /* pkt < pkt_end */
++              fallthrough;
++      case BPF_JGE:
++              /* pkt >= pkt_end */
++              if (pkt->range == BEYOND_PKT_END || pkt->range == AT_PKT_END)
++                      return opcode == BPF_JGE;
++              break;
++      }
++      return -1;
++}
++
+ /* Adjusts the register min/max values in the case that the dst_reg is the
+  * variable register that we are working on, and src_reg is a constant or we're
+  * simply doing a BPF_K check.
+@@ -7640,23 +7728,7 @@ static void reg_set_min_max_inv(struct bpf_reg_state *true_reg,
+                               u64 val, u32 val32,
+                               u8 opcode, bool is_jmp32)
+ {
+-      /* How can we transform "a <op> b" into "b <op> a"? */
+-      static const u8 opcode_flip[16] = {
+-              /* these stay the same */
+-              [BPF_JEQ  >> 4] = BPF_JEQ,
+-              [BPF_JNE  >> 4] = BPF_JNE,
+-              [BPF_JSET >> 4] = BPF_JSET,
+-              /* these swap "lesser" and "greater" (L and G in the opcodes) */
+-              [BPF_JGE  >> 4] = BPF_JLE,
+-              [BPF_JGT  >> 4] = BPF_JLT,
+-              [BPF_JLE  >> 4] = BPF_JGE,
+-              [BPF_JLT  >> 4] = BPF_JGT,
+-              [BPF_JSGE >> 4] = BPF_JSLE,
+-              [BPF_JSGT >> 4] = BPF_JSLT,
+-              [BPF_JSLE >> 4] = BPF_JSGE,
+-              [BPF_JSLT >> 4] = BPF_JSGT
+-      };
+-      opcode = opcode_flip[opcode >> 4];
++      opcode = flip_opcode(opcode);
+       /* This uses zero as "not present in table"; luckily the zero opcode,
+        * BPF_JA, can't get here.
+        */
+@@ -7825,6 +7897,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_data' > pkt_end, pkt_meta' > pkt_data */
+                       find_good_pkt_pointers(this_branch, dst_reg,
+                                              dst_reg->type, false);
++                      mark_pkt_end(other_branch, insn->dst_reg, true);
+               } else if ((dst_reg->type == PTR_TO_PACKET_END &&
+                           src_reg->type == PTR_TO_PACKET) ||
+                          (reg_is_init_pkt_pointer(dst_reg, PTR_TO_PACKET) &&
+@@ -7832,6 +7905,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_end > pkt_data', pkt_data > pkt_meta' */
+                       find_good_pkt_pointers(other_branch, src_reg,
+                                              src_reg->type, true);
++                      mark_pkt_end(this_branch, insn->src_reg, false);
+               } else {
+                       return false;
+               }
+@@ -7844,6 +7918,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_data' < pkt_end, pkt_meta' < pkt_data */
+                       find_good_pkt_pointers(other_branch, dst_reg,
+                                              dst_reg->type, true);
++                      mark_pkt_end(this_branch, insn->dst_reg, false);
+               } else if ((dst_reg->type == PTR_TO_PACKET_END &&
+                           src_reg->type == PTR_TO_PACKET) ||
+                          (reg_is_init_pkt_pointer(dst_reg, PTR_TO_PACKET) &&
+@@ -7851,6 +7926,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_end < pkt_data', pkt_data > pkt_meta' */
+                       find_good_pkt_pointers(this_branch, src_reg,
+                                              src_reg->type, false);
++                      mark_pkt_end(other_branch, insn->src_reg, true);
+               } else {
+                       return false;
+               }
+@@ -7863,6 +7939,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_data' >= pkt_end, pkt_meta' >= pkt_data */
+                       find_good_pkt_pointers(this_branch, dst_reg,
+                                              dst_reg->type, true);
++                      mark_pkt_end(other_branch, insn->dst_reg, false);
+               } else if ((dst_reg->type == PTR_TO_PACKET_END &&
+                           src_reg->type == PTR_TO_PACKET) ||
+                          (reg_is_init_pkt_pointer(dst_reg, PTR_TO_PACKET) &&
+@@ -7870,6 +7947,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_end >= pkt_data', pkt_data >= pkt_meta' */
+                       find_good_pkt_pointers(other_branch, src_reg,
+                                              src_reg->type, false);
++                      mark_pkt_end(this_branch, insn->src_reg, true);
+               } else {
+                       return false;
+               }
+@@ -7882,6 +7960,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_data' <= pkt_end, pkt_meta' <= pkt_data */
+                       find_good_pkt_pointers(other_branch, dst_reg,
+                                              dst_reg->type, false);
++                      mark_pkt_end(this_branch, insn->dst_reg, true);
+               } else if ((dst_reg->type == PTR_TO_PACKET_END &&
+                           src_reg->type == PTR_TO_PACKET) ||
+                          (reg_is_init_pkt_pointer(dst_reg, PTR_TO_PACKET) &&
+@@ -7889,6 +7968,7 @@ static bool try_match_pkt_pointers(const struct bpf_insn *insn,
+                       /* pkt_end <= pkt_data', pkt_data <= pkt_meta' */
+                       find_good_pkt_pointers(this_branch, src_reg,
+                                              src_reg->type, true);
++                      mark_pkt_end(other_branch, insn->src_reg, false);
+               } else {
+                       return false;
+               }
+@@ -7988,6 +8068,10 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
+                                      src_reg->var_off.value,
+                                      opcode,
+                                      is_jmp32);
++      } else if (reg_is_pkt_pointer_any(dst_reg) &&
++                 reg_is_pkt_pointer_any(src_reg) &&
++                 !is_jmp32) {
++              pred = is_pkt_ptr_branch_taken(dst_reg, src_reg, opcode);
+       }
+       if (pred >= 0) {
+@@ -7996,7 +8080,8 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
+                */
+               if (!__is_pointer_value(false, dst_reg))
+                       err = mark_chain_precision(env, insn->dst_reg);
+-              if (BPF_SRC(insn->code) == BPF_X && !err)
++              if (BPF_SRC(insn->code) == BPF_X && !err &&
++                  !__is_pointer_value(false, src_reg))
+                       err = mark_chain_precision(env, insn->src_reg);
+               if (err)
+                       return err;
+-- 
+2.35.1
+
diff --git a/queue-5.10/bpftool-fix-null-pointer-dereference-when-pin-prog-m.patch b/queue-5.10/bpftool-fix-null-pointer-dereference-when-pin-prog-m.patch
new file mode 100644 (file)
index 0000000..9ea237c
--- /dev/null
@@ -0,0 +1,50 @@
+From 38ea79ddfccf3c13ff3af26b1e6e76d814066f1c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 16:40:34 +0800
+Subject: bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK}
+ without FILE
+
+From: Pu Lehui <pulehui@huawei.com>
+
+[ Upstream commit 34de8e6e0e1f66e431abf4123934a2581cb5f133 ]
+
+When using bpftool to pin {PROG, MAP, LINK} without FILE,
+segmentation fault will occur. The reson is that the lack
+of FILE will cause strlen to trigger NULL pointer dereference.
+The corresponding stacktrace is shown below:
+
+do_pin
+  do_pin_any
+    do_pin_fd
+      mount_bpffs_for_pin
+        strlen(name) <- NULL pointer dereference
+
+Fix it by adding validation to the common process.
+
+Fixes: 75a1e792c335 ("tools: bpftool: Allow all prog/map handles for pinning objects")
+Signed-off-by: Pu Lehui <pulehui@huawei.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Reviewed-by: Quentin Monnet <quentin@isovalent.com>
+Link: https://lore.kernel.org/bpf/20221102084034.3342995-1-pulehui@huaweicloud.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/bpf/bpftool/common.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/tools/bpf/bpftool/common.c b/tools/bpf/bpftool/common.c
+index 6ebf2b215ef4..eefa2b34e641 100644
+--- a/tools/bpf/bpftool/common.c
++++ b/tools/bpf/bpftool/common.c
+@@ -271,6 +271,9 @@ int do_pin_any(int argc, char **argv, int (*get_fd)(int *, char ***))
+       int err;
+       int fd;
++      if (!REQ_ARGS(3))
++              return -EINVAL;
++
+       fd = get_fd(&argc, &argv);
+       if (fd < 0)
+               return fd;
+-- 
+2.35.1
+
diff --git a/queue-5.10/can-af_can-fix-null-pointer-dereference-in-can_rx_re.patch b/queue-5.10/can-af_can-fix-null-pointer-dereference-in-can_rx_re.patch
new file mode 100644 (file)
index 0000000..4c63477
--- /dev/null
@@ -0,0 +1,64 @@
+From a2d518edac79dabc026c25207a4aa7192ae5240b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 16:56:50 +0800
+Subject: can: af_can: fix NULL pointer dereference in can_rx_register()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 8aa59e355949442c408408c2d836e561794c40a1 ]
+
+It causes NULL pointer dereference when testing as following:
+(a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.
+(b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan
+    link device, and bind vxcan device to bond device (can also use
+    ifenslave command to bind vxcan device to bond device).
+(c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.
+(d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.
+
+The bond device invokes the can-raw protocol registration interface to
+receive CAN packets. However, ml_priv is not allocated to the dev,
+dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,
+it will occur the NULL pointer dereference issue.
+
+The following is the stack information:
+BUG: kernel NULL pointer dereference, address: 0000000000000008
+PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0
+Oops: 0000 [#1] PREEMPT SMP
+RIP: 0010:can_rx_register+0x12d/0x1e0
+Call Trace:
+<TASK>
+raw_enable_filters+0x8d/0x120
+raw_enable_allfilters+0x3b/0x130
+raw_bind+0x118/0x4f0
+__sys_bind+0x163/0x1a0
+__x64_sys_bind+0x1e/0x30
+do_syscall_64+0x35/0x80
+entry_SYSCALL_64_after_hwframe+0x63/0xcd
+</TASK>
+
+Fixes: 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Link: https://lore.kernel.org/all/20221028085650.170470-1-shaozhengchao@huawei.com
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/can/af_can.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/can/af_can.c b/net/can/af_can.c
+index 1c95ede2c9a6..cf554e855521 100644
+--- a/net/can/af_can.c
++++ b/net/can/af_can.c
+@@ -451,7 +451,7 @@ int can_rx_register(struct net *net, struct net_device *dev, canid_t can_id,
+       /* insert new receiver  (dev,canid,mask) -> (func,data) */
+-      if (dev && dev->type != ARPHRD_CAN)
++      if (dev && (dev->type != ARPHRD_CAN || !can_get_ml_priv(dev)))
+               return -ENODEV;
+       if (dev && !net_eq(net, dev_net(dev)))
+-- 
+2.35.1
+
diff --git a/queue-5.10/capabilities-fix-undefined-behavior-in-bit-shift-for.patch b/queue-5.10/capabilities-fix-undefined-behavior-in-bit-shift-for.patch
new file mode 100644 (file)
index 0000000..c37fa69
--- /dev/null
@@ -0,0 +1,53 @@
+From 751ef26a383d5ac666c60a144d1ac06965e28a10 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 19:25:36 +0800
+Subject: capabilities: fix undefined behavior in bit shift for CAP_TO_MASK
+
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+
+[ Upstream commit 46653972e3ea64f79e7f8ae3aa41a4d3fdb70a13 ]
+
+Shifting signed 32-bit value by 31 bits is undefined, so changing
+significant bit to unsigned. The UBSAN warning calltrace like below:
+
+UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2
+left shift of 1 by 31 places cannot be represented in type 'int'
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x7d/0xa5
+ dump_stack+0x15/0x1b
+ ubsan_epilogue+0xe/0x4e
+ __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
+ cap_task_prctl+0x561/0x6f0
+ security_task_prctl+0x5a/0xb0
+ __x64_sys_prctl+0x61/0x8f0
+ do_syscall_64+0x58/0x80
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+ </TASK>
+
+Fixes: e338d263a76a ("Add 64-bit capability support to the kernel")
+Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Acked-by: Andrew G. Morgan <morgan@kernel.org>
+Reviewed-by: Serge Hallyn <serge@hallyn.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/uapi/linux/capability.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
+index 2ddb4226cd23..43a44538ec8d 100644
+--- a/include/uapi/linux/capability.h
++++ b/include/uapi/linux/capability.h
+@@ -427,7 +427,7 @@ struct vfs_ns_cap_data {
+  */
+ #define CAP_TO_INDEX(x)     ((x) >> 5)        /* 1 << 5 == bits in __u32 */
+-#define CAP_TO_MASK(x)      (1 << ((x) & 31)) /* mask for indexed __u32 */
++#define CAP_TO_MASK(x)      (1U << ((x) & 31)) /* mask for indexed __u32 */
+ #endif /* _UAPI_LINUX_CAPABILITY_H */
+-- 
+2.35.1
+
diff --git a/queue-5.10/cxgb4vf-shut-down-the-adapter-when-t4vf_update_port_.patch b/queue-5.10/cxgb4vf-shut-down-the-adapter-when-t4vf_update_port_.patch
new file mode 100644 (file)
index 0000000..71efea7
--- /dev/null
@@ -0,0 +1,39 @@
+From 0473545e81a746a1ce73fe872f842844a70613e8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 09:21:00 +0800
+Subject: cxgb4vf: shut down the adapter when t4vf_update_port_info() failed in
+ cxgb4vf_open()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit c6092ea1e6d7bd12acd881f6aa2b5054cd70e096 ]
+
+When t4vf_update_port_info() failed in cxgb4vf_open(), resources applied
+during adapter goes up are not cleared. Fix it. Only be compiled, not be
+tested.
+
+Fixes: 18d79f721e0a ("cxgb4vf: Update port information in cxgb4vf_open()")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221109012100.99132-1-shaozhengchao@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+index 2820a0bb971b..5e1e46425014 100644
+--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
++++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+@@ -858,7 +858,7 @@ static int cxgb4vf_open(struct net_device *dev)
+        */
+       err = t4vf_update_port_info(pi);
+       if (err < 0)
+-              return err;
++              goto err_unwind;
+       /*
+        * Note that this interface is up and start everything up ...
+-- 
+2.35.1
+
diff --git a/queue-5.10/dmaengine-mv_xor_v2-fix-a-resource-leak-in-mv_xor_v2.patch b/queue-5.10/dmaengine-mv_xor_v2-fix-a-resource-leak-in-mv_xor_v2.patch
new file mode 100644 (file)
index 0000000..d0384ad
--- /dev/null
@@ -0,0 +1,38 @@
+From 4518f8ed5b1ca23f1a4ef1ee6dc76be426eb0bdd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 24 Oct 2022 21:50:09 +0200
+Subject: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit 081195d17a0c4c636da2b869bd5809d42e8cbb13 ]
+
+A clk_prepare_enable() call in the probe is not balanced by a corresponding
+clk_disable_unprepare() in the remove function.
+
+Add the missing call.
+
+Fixes: 3cd2c313f1d6 ("dmaengine: mv_xor_v2: Fix clock resource by adding a register clock")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Link: https://lore.kernel.org/r/e9e3837a680c9bd2438e4db2b83270c6c052d005.1666640987.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/dma/mv_xor_v2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c
+index 9b0d463f89bb..4800c596433a 100644
+--- a/drivers/dma/mv_xor_v2.c
++++ b/drivers/dma/mv_xor_v2.c
+@@ -899,6 +899,7 @@ static int mv_xor_v2_remove(struct platform_device *pdev)
+       tasklet_kill(&xor_dev->irq_tasklet);
+       clk_disable_unprepare(xor_dev->clk);
++      clk_disable_unprepare(xor_dev->reg_clk);
+       return 0;
+ }
+-- 
+2.35.1
+
diff --git a/queue-5.10/dmaengine-pxa_dma-use-platform_get_irq_optional.patch b/queue-5.10/dmaengine-pxa_dma-use-platform_get_irq_optional.patch
new file mode 100644 (file)
index 0000000..55aa48f
--- /dev/null
@@ -0,0 +1,49 @@
+From ddb481e5aa3a7fc280f6b62b5366ce9d1722541f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 5 Sep 2022 17:07:09 -0700
+Subject: dmaengine: pxa_dma: use platform_get_irq_optional
+
+From: Doug Brown <doug@schmorgal.com>
+
+[ Upstream commit b3d726cb8497c6b12106fd617d46eef11763ea86 ]
+
+The first IRQ is required, but IRQs 1 through (nb_phy_chans - 1) are
+optional, because on some platforms (e.g. PXA168) there is a single IRQ
+shared between all channels.
+
+This change inhibits a flood of "IRQ index # not found" messages at
+startup. Tested on a PXA168-based device.
+
+Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
+Signed-off-by: Doug Brown <doug@schmorgal.com>
+Link: https://lore.kernel.org/r/20220906000709.52705-1-doug@schmorgal.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/dma/pxa_dma.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
+index b4ef4f19f7de..68d9d60c051d 100644
+--- a/drivers/dma/pxa_dma.c
++++ b/drivers/dma/pxa_dma.c
+@@ -1249,14 +1249,14 @@ static int pxad_init_phys(struct platform_device *op,
+               return -ENOMEM;
+       for (i = 0; i < nb_phy_chans; i++)
+-              if (platform_get_irq(op, i) > 0)
++              if (platform_get_irq_optional(op, i) > 0)
+                       nr_irq++;
+       for (i = 0; i < nb_phy_chans; i++) {
+               phy = &pdev->phys[i];
+               phy->base = pdev->base;
+               phy->idx = i;
+-              irq = platform_get_irq(op, i);
++              irq = platform_get_irq_optional(op, i);
+               if ((nr_irq > 1) && (irq > 0))
+                       ret = devm_request_irq(&op->dev, irq,
+                                              pxad_chan_handler,
+-- 
+2.35.1
+
diff --git a/queue-5.10/drivers-net-xgene-disable-napi-when-register-irq-fai.patch b/queue-5.10/drivers-net-xgene-disable-napi-when-register-irq-fai.patch
new file mode 100644 (file)
index 0000000..a07c1df
--- /dev/null
@@ -0,0 +1,42 @@
+From 6148ea7dff79ad7f61788a242d5d792abac06412 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Nov 2022 12:30:32 +0800
+Subject: drivers: net: xgene: disable napi when register irq failed in
+ xgene_enet_open()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit ce9e57feeed81d17d5e80ed86f516ff0d39c3867 ]
+
+When failed to register irq in xgene_enet_open() for opening device,
+napi isn't disabled. When open xgene device next time, it will reports
+a invalid opcode issue. Fix it. Only be compiled, not be tested.
+
+Fixes: aeb20b6b3f4e ("drivers: net: xgene: fix: ifconfig up/down crash")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221107043032.357673-1-shaozhengchao@huawei.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+index 78c7cbc372b0..71151f675a49 100644
+--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
++++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+@@ -1004,8 +1004,10 @@ static int xgene_enet_open(struct net_device *ndev)
+       xgene_enet_napi_enable(pdata);
+       ret = xgene_enet_register_irq(ndev);
+-      if (ret)
++      if (ret) {
++              xgene_enet_napi_disable(pdata);
+               return ret;
++      }
+       if (ndev->phydev) {
+               phy_start(ndev->phydev);
+-- 
+2.35.1
+
diff --git a/queue-5.10/drm-vc4-fix-missing-platform_unregister_drivers-call.patch b/queue-5.10/drm-vc4-fix-missing-platform_unregister_drivers-call.patch
new file mode 100644 (file)
index 0000000..c112422
--- /dev/null
@@ -0,0 +1,65 @@
+From c2db2c8b70dd5ef28897d9631cd965afc571cf9a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 01:47:05 +0000
+Subject: drm/vc4: Fix missing platform_unregister_drivers() call in
+ vc4_drm_register()
+
+From: Yuan Can <yuancan@huawei.com>
+
+[ Upstream commit cf53db768a8790fdaae2fa3a81322b080285f7e5 ]
+
+A problem about modprobe vc4 failed is triggered with the following log
+given:
+
+ [  420.327987] Error: Driver 'vc4_hvs' is already registered, aborting...
+ [  420.333904] failed to register platform driver vc4_hvs_driver [vc4]: -16
+ modprobe: ERROR: could not insert 'vc4': Device or resource busy
+
+The reason is that vc4_drm_register() returns platform_driver_register()
+directly without checking its return value, if platform_driver_register()
+fails, it returns without unregistering all the vc4 drivers, resulting the
+vc4 can never be installed later.
+A simple call graph is shown as below:
+
+ vc4_drm_register()
+   platform_register_drivers() # all vc4 drivers are registered
+   platform_driver_register()
+     driver_register()
+       bus_add_driver()
+         priv = kzalloc(...) # OOM happened
+   # return without unregister drivers
+
+Fixing this problem by checking the return value of
+platform_driver_register() and do platform_unregister_drivers() if
+error happened.
+
+Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
+Signed-off-by: Yuan Can <yuancan@huawei.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221103014705.109322-1-yuancan@huawei.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/vc4/vc4_drv.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
+index 52426bc8edb8..888aec1bbeee 100644
+--- a/drivers/gpu/drm/vc4/vc4_drv.c
++++ b/drivers/gpu/drm/vc4/vc4_drv.c
+@@ -404,7 +404,12 @@ static int __init vc4_drm_register(void)
+       if (ret)
+               return ret;
+-      return platform_driver_register(&vc4_platform_driver);
++      ret = platform_driver_register(&vc4_platform_driver);
++      if (ret)
++              platform_unregister_drivers(component_drivers,
++                                          ARRAY_SIZE(component_drivers));
++
++      return ret;
+ }
+ static void __exit vc4_drm_unregister(void)
+-- 
+2.35.1
+
diff --git a/queue-5.10/ethernet-s2io-disable-napi-when-start-nic-failed-in-.patch b/queue-5.10/ethernet-s2io-disable-napi-when-start-nic-failed-in-.patch
new file mode 100644 (file)
index 0000000..be4ed74
--- /dev/null
@@ -0,0 +1,86 @@
+From c380b87934f7245cf490f0e154a78d924a675887 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 10:37:41 +0800
+Subject: ethernet: s2io: disable napi when start nic failed in s2io_card_up()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 0348c1ab980c1d43fb37b758d4b760990c066cb5 ]
+
+When failed to start nic or add interrupt service routine in
+s2io_card_up() for opening device, napi isn't disabled. When open
+s2io device next time, it will trigger a BUG_ON()in napi_enable().
+Compile tested only.
+
+Fixes: 5f490c968056 ("S2io: Fixed synchronization between scheduling of napi with card reset and close")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221109023741.131552-1-shaozhengchao@huawei.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/neterion/s2io.c | 29 +++++++++++++++++++---------
+ 1 file changed, 20 insertions(+), 9 deletions(-)
+
+diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
+index 3cae8449fadb..8a30be698f99 100644
+--- a/drivers/net/ethernet/neterion/s2io.c
++++ b/drivers/net/ethernet/neterion/s2io.c
+@@ -7114,9 +7114,8 @@ static int s2io_card_up(struct s2io_nic *sp)
+               if (ret) {
+                       DBG_PRINT(ERR_DBG, "%s: Out of memory in Open\n",
+                                 dev->name);
+-                      s2io_reset(sp);
+-                      free_rx_buffers(sp);
+-                      return -ENOMEM;
++                      ret = -ENOMEM;
++                      goto err_fill_buff;
+               }
+               DBG_PRINT(INFO_DBG, "Buf in ring:%d is %d:\n", i,
+                         ring->rx_bufs_left);
+@@ -7154,18 +7153,16 @@ static int s2io_card_up(struct s2io_nic *sp)
+       /* Enable Rx Traffic and interrupts on the NIC */
+       if (start_nic(sp)) {
+               DBG_PRINT(ERR_DBG, "%s: Starting NIC failed\n", dev->name);
+-              s2io_reset(sp);
+-              free_rx_buffers(sp);
+-              return -ENODEV;
++              ret = -ENODEV;
++              goto err_out;
+       }
+       /* Add interrupt service routine */
+       if (s2io_add_isr(sp) != 0) {
+               if (sp->config.intr_type == MSI_X)
+                       s2io_rem_isr(sp);
+-              s2io_reset(sp);
+-              free_rx_buffers(sp);
+-              return -ENODEV;
++              ret = -ENODEV;
++              goto err_out;
+       }
+       timer_setup(&sp->alarm_timer, s2io_alarm_handle, 0);
+@@ -7185,6 +7182,20 @@ static int s2io_card_up(struct s2io_nic *sp)
+       }
+       return 0;
++
++err_out:
++      if (config->napi) {
++              if (config->intr_type == MSI_X) {
++                      for (i = 0; i < sp->config.rx_ring_num; i++)
++                              napi_disable(&sp->mac_control.rings[i].napi);
++              } else {
++                      napi_disable(&sp->napi);
++              }
++      }
++err_fill_buff:
++      s2io_reset(sp);
++      free_rx_buffers(sp);
++      return ret;
+ }
+ /**
+-- 
+2.35.1
+
diff --git a/queue-5.10/ethernet-tundra-free-irq-when-alloc-ring-failed-in-t.patch b/queue-5.10/ethernet-tundra-free-irq-when-alloc-ring-failed-in-t.patch
new file mode 100644 (file)
index 0000000..085444f
--- /dev/null
@@ -0,0 +1,45 @@
+From 76c44f6a02541340d998aaeee122eda4c0cb513e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 12:40:16 +0800
+Subject: ethernet: tundra: free irq when alloc ring failed in tsi108_open()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit acce40037041f97baad18142bb253064491ebde3 ]
+
+When alloc tx/rx ring failed in tsi108_open(), it doesn't free irq. Fix
+it.
+
+Fixes: 5e123b844a1c ("[PATCH] Add tsi108/9 On Chip Ethernet device driver support")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221109044016.126866-1-shaozhengchao@huawei.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/tundra/tsi108_eth.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/tundra/tsi108_eth.c b/drivers/net/ethernet/tundra/tsi108_eth.c
+index c62f474b6d08..fcebd2418dbd 100644
+--- a/drivers/net/ethernet/tundra/tsi108_eth.c
++++ b/drivers/net/ethernet/tundra/tsi108_eth.c
+@@ -1302,12 +1302,15 @@ static int tsi108_open(struct net_device *dev)
+       data->rxring = dma_alloc_coherent(&data->pdev->dev, rxring_size,
+                                         &data->rxdma, GFP_KERNEL);
+-      if (!data->rxring)
++      if (!data->rxring) {
++              free_irq(data->irq_num, dev);
+               return -ENOMEM;
++      }
+       data->txring = dma_alloc_coherent(&data->pdev->dev, txring_size,
+                                         &data->txdma, GFP_KERNEL);
+       if (!data->txring) {
++              free_irq(data->irq_num, dev);
+               dma_free_coherent(&data->pdev->dev, rxring_size, data->rxring,
+                                   data->rxdma);
+               return -ENOMEM;
+-- 
+2.35.1
+
diff --git a/queue-5.10/hamradio-fix-issue-of-dev-reference-count-leakage-in.patch b/queue-5.10/hamradio-fix-issue-of-dev-reference-count-leakage-in.patch
new file mode 100644 (file)
index 0000000..0f06bdf
--- /dev/null
@@ -0,0 +1,49 @@
+From 79ed717557acdb449a47eb42b78ba33094294945 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 17:09:05 +0800
+Subject: hamradio: fix issue of dev reference count leakage in
+ bpq_device_event()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 85cbaf032d3cd9f595152625eda5d4ecb1d6d78d ]
+
+When following tests are performed, it will cause dev reference counting
+leakage.
+a)ip link add bond2 type bond mode balance-rr
+b)ip link set bond2 up
+c)ifenslave -f bond2 rose1
+d)ip link del bond2
+
+When new bond device is created, the default type of the bond device is
+ether. And the bond device is up, bpq_device_event() receives the message
+and creates a new bpq device. In this case, the reference count value of
+dev is hold once. But after "ifenslave -f bond2 rose1" command is
+executed, the type of the bond device is changed to rose. When the bond
+device is unregistered, bpq_device_event() will not put the dev reference
+count.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/hamradio/bpqether.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c
+index 1ad6085994b1..5c17c92add8a 100644
+--- a/drivers/net/hamradio/bpqether.c
++++ b/drivers/net/hamradio/bpqether.c
+@@ -533,7 +533,7 @@ static int bpq_device_event(struct notifier_block *this,
+       if (!net_eq(dev_net(dev), &init_net))
+               return NOTIFY_DONE;
+-      if (!dev_is_ethdev(dev))
++      if (!dev_is_ethdev(dev) && !bpq_get_ax25_dev(dev))
+               return NOTIFY_DONE;
+       switch (event) {
+-- 
+2.35.1
+
diff --git a/queue-5.10/hid-hyperv-fix-possible-memory-leak-in-mousevsc_prob.patch b/queue-5.10/hid-hyperv-fix-possible-memory-leak-in-mousevsc_prob.patch
new file mode 100644 (file)
index 0000000..2b35e7d
--- /dev/null
@@ -0,0 +1,37 @@
+From ad2317069e3af0b8bcc04f2426d7daf93037d39c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 21:40:43 +0800
+Subject: HID: hyperv: fix possible memory leak in mousevsc_probe()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit b5bcb94b0954a026bbd671741fdb00e7141f9c91 ]
+
+If hid_add_device() returns error, it should call hid_destroy_device()
+to free hid_dev which is allocated in hid_allocate_device().
+
+Fixes: 74c4fb058083 ("HID: hv_mouse: Properly add the hid device")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Reviewed-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hid/hid-hyperv.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
+index 978ee2aab2d4..b7704dd6809d 100644
+--- a/drivers/hid/hid-hyperv.c
++++ b/drivers/hid/hid-hyperv.c
+@@ -498,7 +498,7 @@ static int mousevsc_probe(struct hv_device *device,
+       ret = hid_add_device(hid_dev);
+       if (ret)
+-              goto probe_err1;
++              goto probe_err2;
+       ret = hid_parse(hid_dev);
+-- 
+2.35.1
+
diff --git a/queue-5.10/hwspinlock-qcom-correct-mmio-max-register-for-newer-.patch b/queue-5.10/hwspinlock-qcom-correct-mmio-max-register-for-newer-.patch
new file mode 100644 (file)
index 0000000..5072085
--- /dev/null
@@ -0,0 +1,38 @@
+From ea7761d565f79c76e536ab8c82590a7c8bd3a701 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 9 Sep 2022 11:20:23 +0200
+Subject: hwspinlock: qcom: correct MMIO max register for newer SoCs
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+[ Upstream commit 90cb380f9ceb811059340d06ff5fd0c0e93ecbe1 ]
+
+Newer ARMv8 Qualcomm SoCs using 0x1000 register stride have maximum
+register 0x20000 (32 mutexes * 0x1000).
+
+Fixes: 7a1e6fb1c606 ("hwspinlock: qcom: Allow mmio usage in addition to syscon")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Link: https://lore.kernel.org/r/20220909092035.223915-4-krzysztof.kozlowski@linaro.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hwspinlock/qcom_hwspinlock.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/hwspinlock/qcom_hwspinlock.c b/drivers/hwspinlock/qcom_hwspinlock.c
+index 364710966665..e49914664863 100644
+--- a/drivers/hwspinlock/qcom_hwspinlock.c
++++ b/drivers/hwspinlock/qcom_hwspinlock.c
+@@ -105,7 +105,7 @@ static const struct regmap_config tcsr_mutex_config = {
+       .reg_bits               = 32,
+       .reg_stride             = 4,
+       .val_bits               = 32,
+-      .max_register           = 0x40000,
++      .max_register           = 0x20000,
+       .fast_io                = true,
+ };
+-- 
+2.35.1
+
diff --git a/queue-5.10/ipv6-addrlabel-fix-infoleak-when-sending-struct-ifad.patch b/queue-5.10/ipv6-addrlabel-fix-infoleak-when-sending-struct-ifad.patch
new file mode 100644 (file)
index 0000000..e8bb6f1
--- /dev/null
@@ -0,0 +1,77 @@
+From e3a7c4c75d2a57997545cd7b336584f27dfa8094 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Nov 2022 11:32:16 +0100
+Subject: ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to
+ network
+
+From: Alexander Potapenko <glider@google.com>
+
+[ Upstream commit c23fb2c82267638f9d206cb96bb93e1f93ad7828 ]
+
+When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved
+remained uninitialized, resulting in a 1-byte infoleak:
+
+  BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841
+   __netdev_start_xmit ./include/linux/netdevice.h:4841
+   netdev_start_xmit ./include/linux/netdevice.h:4857
+   xmit_one net/core/dev.c:3590
+   dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606
+   __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256
+   dev_queue_xmit ./include/linux/netdevice.h:3009
+   __netlink_deliver_tap_skb net/netlink/af_netlink.c:307
+   __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325
+   netlink_deliver_tap net/netlink/af_netlink.c:338
+   __netlink_sendskb net/netlink/af_netlink.c:1263
+   netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272
+   netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360
+   nlmsg_unicast ./include/net/netlink.h:1061
+   rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758
+   ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628
+   rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082
+  ...
+  Uninit was created at:
+   slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742
+   slab_alloc_node mm/slub.c:3398
+   __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437
+   __do_kmalloc_node mm/slab_common.c:954
+   __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975
+   kmalloc_reserve net/core/skbuff.c:437
+   __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509
+   alloc_skb ./include/linux/skbuff.h:1267
+   nlmsg_new ./include/net/netlink.h:964
+   ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608
+   rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082
+   netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540
+   rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109
+   netlink_unicast_kernel net/netlink/af_netlink.c:1319
+   netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345
+   netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921
+  ...
+
+This patch ensures that the reserved field is always initialized.
+
+Reported-by: syzbot+3553517af6020c4f2813f1003fe76ef3cbffe98d@syzkaller.appspotmail.com
+Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
+Signed-off-by: Alexander Potapenko <glider@google.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv6/addrlabel.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
+index 8a22486cf270..17ac45aa7194 100644
+--- a/net/ipv6/addrlabel.c
++++ b/net/ipv6/addrlabel.c
+@@ -437,6 +437,7 @@ static void ip6addrlbl_putmsg(struct nlmsghdr *nlh,
+ {
+       struct ifaddrlblmsg *ifal = nlmsg_data(nlh);
+       ifal->ifal_family = AF_INET6;
++      ifal->__ifal_reserved = 0;
+       ifal->ifal_prefixlen = prefixlen;
+       ifal->ifal_flags = 0;
+       ifal->ifal_index = ifindex;
+-- 
+2.35.1
+
diff --git a/queue-5.10/kvm-s390-pv-don-t-allow-userspace-to-set-the-clock-u.patch b/queue-5.10/kvm-s390-pv-don-t-allow-userspace-to-set-the-clock-u.patch
new file mode 100644 (file)
index 0000000..c00bb08
--- /dev/null
@@ -0,0 +1,166 @@
+From bb4860bd1f7fb699765395cb57d64f94ed7934b4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Oct 2022 18:07:12 +0200
+Subject: KVM: s390: pv: don't allow userspace to set the clock under PV
+
+From: Nico Boehr <nrb@linux.ibm.com>
+
+[ Upstream commit 6973091d1b50ab4042f6a2d495f59e9db3662ab8 ]
+
+When running under PV, the guest's TOD clock is under control of the
+ultravisor and the hypervisor isn't allowed to change it. Hence, don't
+allow userspace to change the guest's TOD clock by returning
+-EOPNOTSUPP.
+
+When userspace changes the guest's TOD clock, KVM updates its
+kvm.arch.epoch field and, in addition, the epoch field in all state
+descriptions of all VCPUs.
+
+But, under PV, the ultravisor will ignore the epoch field in the state
+description and simply overwrite it on next SIE exit with the actual
+guest epoch. This leads to KVM having an incorrect view of the guest's
+TOD clock: it has updated its internal kvm.arch.epoch field, but the
+ultravisor ignores the field in the state description.
+
+Whenever a guest is now waiting for a clock comparator, KVM will
+incorrectly calculate the time when the guest should wake up, possibly
+causing the guest to sleep for much longer than expected.
+
+With this change, kvm_s390_set_tod() will now take the kvm->lock to be
+able to call kvm_s390_pv_is_protected(). Since kvm_s390_set_tod_clock()
+also takes kvm->lock, use __kvm_s390_set_tod_clock() instead.
+
+The function kvm_s390_set_tod_clock is now unused, hence remove it.
+Update the documentation to indicate the TOD clock attr calls can now
+return -EOPNOTSUPP.
+
+Fixes: 0f3035047140 ("KVM: s390: protvirt: Do only reset registers that are accessible")
+Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
+Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
+Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
+Link: https://lore.kernel.org/r/20221011160712.928239-2-nrb@linux.ibm.com
+Message-Id: <20221011160712.928239-2-nrb@linux.ibm.com>
+Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ Documentation/virt/kvm/devices/vm.rst |  3 +++
+ arch/s390/kvm/kvm-s390.c              | 26 +++++++++++++++++---------
+ arch/s390/kvm/kvm-s390.h              |  1 -
+ 3 files changed, 20 insertions(+), 10 deletions(-)
+
+diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst
+index 0aa5b1cfd700..60acc39e0e93 100644
+--- a/Documentation/virt/kvm/devices/vm.rst
++++ b/Documentation/virt/kvm/devices/vm.rst
+@@ -215,6 +215,7 @@ KVM_S390_VM_TOD_EXT).
+ :Parameters: address of a buffer in user space to store the data (u8) to
+ :Returns:   -EFAULT if the given address is not accessible from kernel space;
+           -EINVAL if setting the TOD clock extension to != 0 is not supported
++          -EOPNOTSUPP for a PV guest (TOD managed by the ultravisor)
+ 3.2. ATTRIBUTE: KVM_S390_VM_TOD_LOW
+ -----------------------------------
+@@ -224,6 +225,7 @@ the POP (u64).
+ :Parameters: address of a buffer in user space to store the data (u64) to
+ :Returns:    -EFAULT if the given address is not accessible from kernel space
++           -EOPNOTSUPP for a PV guest (TOD managed by the ultravisor)
+ 3.3. ATTRIBUTE: KVM_S390_VM_TOD_EXT
+ -----------------------------------
+@@ -237,6 +239,7 @@ it, it is stored as 0 and not allowed to be set to a value != 0.
+            (kvm_s390_vm_tod_clock) to
+ :Returns:   -EFAULT if the given address is not accessible from kernel space;
+           -EINVAL if setting the TOD clock extension to != 0 is not supported
++          -EOPNOTSUPP for a PV guest (TOD managed by the ultravisor)
+ 4. GROUP: KVM_S390_VM_CRYPTO
+ ============================
+diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
+index d12042ab5d54..59db85fb63e1 100644
+--- a/arch/s390/kvm/kvm-s390.c
++++ b/arch/s390/kvm/kvm-s390.c
+@@ -1092,6 +1092,8 @@ static int kvm_s390_vm_get_migration(struct kvm *kvm,
+       return 0;
+ }
++static void __kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod);
++
+ static int kvm_s390_set_tod_ext(struct kvm *kvm, struct kvm_device_attr *attr)
+ {
+       struct kvm_s390_vm_tod_clock gtod;
+@@ -1101,7 +1103,7 @@ static int kvm_s390_set_tod_ext(struct kvm *kvm, struct kvm_device_attr *attr)
+       if (!test_kvm_facility(kvm, 139) && gtod.epoch_idx)
+               return -EINVAL;
+-      kvm_s390_set_tod_clock(kvm, &gtod);
++      __kvm_s390_set_tod_clock(kvm, &gtod);
+       VM_EVENT(kvm, 3, "SET: TOD extension: 0x%x, TOD base: 0x%llx",
+               gtod.epoch_idx, gtod.tod);
+@@ -1132,7 +1134,7 @@ static int kvm_s390_set_tod_low(struct kvm *kvm, struct kvm_device_attr *attr)
+                          sizeof(gtod.tod)))
+               return -EFAULT;
+-      kvm_s390_set_tod_clock(kvm, &gtod);
++      __kvm_s390_set_tod_clock(kvm, &gtod);
+       VM_EVENT(kvm, 3, "SET: TOD base: 0x%llx", gtod.tod);
+       return 0;
+ }
+@@ -1144,6 +1146,16 @@ static int kvm_s390_set_tod(struct kvm *kvm, struct kvm_device_attr *attr)
+       if (attr->flags)
+               return -EINVAL;
++      mutex_lock(&kvm->lock);
++      /*
++       * For protected guests, the TOD is managed by the ultravisor, so trying
++       * to change it will never bring the expected results.
++       */
++      if (kvm_s390_pv_is_protected(kvm)) {
++              ret = -EOPNOTSUPP;
++              goto out_unlock;
++      }
++
+       switch (attr->attr) {
+       case KVM_S390_VM_TOD_EXT:
+               ret = kvm_s390_set_tod_ext(kvm, attr);
+@@ -1158,6 +1170,9 @@ static int kvm_s390_set_tod(struct kvm *kvm, struct kvm_device_attr *attr)
+               ret = -ENXIO;
+               break;
+       }
++
++out_unlock:
++      mutex_unlock(&kvm->lock);
+       return ret;
+ }
+@@ -3890,13 +3905,6 @@ static void __kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_t
+       preempt_enable();
+ }
+-void kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod)
+-{
+-      mutex_lock(&kvm->lock);
+-      __kvm_s390_set_tod_clock(kvm, gtod);
+-      mutex_unlock(&kvm->lock);
+-}
+-
+ int kvm_s390_try_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod)
+ {
+       if (!mutex_trylock(&kvm->lock))
+diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
+index 80bfe9c3364a..b6ff64796af9 100644
+--- a/arch/s390/kvm/kvm-s390.h
++++ b/arch/s390/kvm/kvm-s390.h
+@@ -326,7 +326,6 @@ int kvm_s390_handle_sigp(struct kvm_vcpu *vcpu);
+ int kvm_s390_handle_sigp_pei(struct kvm_vcpu *vcpu);
+ /* implemented in kvm-s390.c */
+-void kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod);
+ int kvm_s390_try_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod);
+ long kvm_arch_fault_in_page(struct kvm_vcpu *vcpu, gpa_t gpa, int writable);
+ int kvm_s390_store_status_unloaded(struct kvm_vcpu *vcpu, unsigned long addr);
+-- 
+2.35.1
+
diff --git a/queue-5.10/kvm-s390x-fix-sck-locking.patch b/queue-5.10/kvm-s390x-fix-sck-locking.patch
new file mode 100644 (file)
index 0000000..64f89d9
--- /dev/null
@@ -0,0 +1,136 @@
+From 0533e10ace5670a0a64dd63b415c434883459b58 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Mar 2022 15:33:40 +0100
+Subject: KVM: s390x: fix SCK locking
+
+From: Claudio Imbrenda <imbrenda@linux.ibm.com>
+
+[ Upstream commit c0573ba5c5a2244dc02060b1f374d4593c1d20b7 ]
+
+When handling the SCK instruction, the kvm lock is taken, even though
+the vcpu lock is already being held. The normal locking order is kvm
+lock first and then vcpu lock. This is can (and in some circumstances
+does) lead to deadlocks.
+
+The function kvm_s390_set_tod_clock is called both by the SCK handler
+and by some IOCTLs to set the clock. The IOCTLs will not hold the vcpu
+lock, so they can safely take the kvm lock. The SCK handler holds the
+vcpu lock, but will also somehow need to acquire the kvm lock without
+relinquishing the vcpu lock.
+
+The solution is to factor out the code to set the clock, and provide
+two wrappers. One is called like the original function and does the
+locking, the other is called kvm_s390_try_set_tod_clock and uses
+trylock to try to acquire the kvm lock. This new wrapper is then used
+in the SCK handler. If locking fails, -EAGAIN is returned, which is
+eventually propagated to userspace, thus also freeing the vcpu lock and
+allowing for forward progress.
+
+This is not the most efficient or elegant way to solve this issue, but
+the SCK instruction is deprecated and its performance is not critical.
+
+The goal of this patch is just to provide a simple but correct way to
+fix the bug.
+
+Fixes: 6a3f95a6b04c ("KVM: s390: Intercept SCK instruction")
+Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
+Reviewed-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
+Link: https://lore.kernel.org/r/20220301143340.111129-1-imbrenda@linux.ibm.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
+Stable-dep-of: 6973091d1b50 ("KVM: s390: pv: don't allow userspace to set the clock under PV")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kvm/kvm-s390.c | 19 ++++++++++++++++---
+ arch/s390/kvm/kvm-s390.h |  4 ++--
+ arch/s390/kvm/priv.c     | 15 ++++++++++++++-
+ 3 files changed, 32 insertions(+), 6 deletions(-)
+
+diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
+index d8e9239c24ff..d12042ab5d54 100644
+--- a/arch/s390/kvm/kvm-s390.c
++++ b/arch/s390/kvm/kvm-s390.c
+@@ -3862,14 +3862,12 @@ static int kvm_s390_handle_requests(struct kvm_vcpu *vcpu)
+       return 0;
+ }
+-void kvm_s390_set_tod_clock(struct kvm *kvm,
+-                          const struct kvm_s390_vm_tod_clock *gtod)
++static void __kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod)
+ {
+       struct kvm_vcpu *vcpu;
+       struct kvm_s390_tod_clock_ext htod;
+       int i;
+-      mutex_lock(&kvm->lock);
+       preempt_disable();
+       get_tod_clock_ext((char *)&htod);
+@@ -3890,7 +3888,22 @@ void kvm_s390_set_tod_clock(struct kvm *kvm,
+       kvm_s390_vcpu_unblock_all(kvm);
+       preempt_enable();
++}
++
++void kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod)
++{
++      mutex_lock(&kvm->lock);
++      __kvm_s390_set_tod_clock(kvm, gtod);
++      mutex_unlock(&kvm->lock);
++}
++
++int kvm_s390_try_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod)
++{
++      if (!mutex_trylock(&kvm->lock))
++              return 0;
++      __kvm_s390_set_tod_clock(kvm, gtod);
+       mutex_unlock(&kvm->lock);
++      return 1;
+ }
+ /**
+diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
+index a3e9b71d426f..80bfe9c3364a 100644
+--- a/arch/s390/kvm/kvm-s390.h
++++ b/arch/s390/kvm/kvm-s390.h
+@@ -326,8 +326,8 @@ int kvm_s390_handle_sigp(struct kvm_vcpu *vcpu);
+ int kvm_s390_handle_sigp_pei(struct kvm_vcpu *vcpu);
+ /* implemented in kvm-s390.c */
+-void kvm_s390_set_tod_clock(struct kvm *kvm,
+-                          const struct kvm_s390_vm_tod_clock *gtod);
++void kvm_s390_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod);
++int kvm_s390_try_set_tod_clock(struct kvm *kvm, const struct kvm_s390_vm_tod_clock *gtod);
+ long kvm_arch_fault_in_page(struct kvm_vcpu *vcpu, gpa_t gpa, int writable);
+ int kvm_s390_store_status_unloaded(struct kvm_vcpu *vcpu, unsigned long addr);
+ int kvm_s390_vcpu_store_status(struct kvm_vcpu *vcpu, unsigned long addr);
+diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
+index 3b1a498e58d2..e34d518dd3d3 100644
+--- a/arch/s390/kvm/priv.c
++++ b/arch/s390/kvm/priv.c
+@@ -102,7 +102,20 @@ static int handle_set_clock(struct kvm_vcpu *vcpu)
+               return kvm_s390_inject_prog_cond(vcpu, rc);
+       VCPU_EVENT(vcpu, 3, "SCK: setting guest TOD to 0x%llx", gtod.tod);
+-      kvm_s390_set_tod_clock(vcpu->kvm, &gtod);
++      /*
++       * To set the TOD clock the kvm lock must be taken, but the vcpu lock
++       * is already held in handle_set_clock. The usual lock order is the
++       * opposite.  As SCK is deprecated and should not be used in several
++       * cases, for example when the multiple epoch facility or TOD clock
++       * steering facility is installed (see Principles of Operation),  a
++       * slow path can be used.  If the lock can not be taken via try_lock,
++       * the instruction will be retried via -EAGAIN at a later point in
++       * time.
++       */
++      if (!kvm_s390_try_set_tod_clock(vcpu->kvm, &gtod)) {
++              kvm_s390_retry_instr(vcpu);
++              return -EAGAIN;
++      }
+       kvm_s390_set_psw_cc(vcpu, 0);
+       return 0;
+-- 
+2.35.1
+
diff --git a/queue-5.10/macsec-clear-encryption-keys-from-the-stack-after-se.patch b/queue-5.10/macsec-clear-encryption-keys-from-the-stack-after-se.patch
new file mode 100644 (file)
index 0000000..eae39a6
--- /dev/null
@@ -0,0 +1,47 @@
+From 5b63beceef49212156a37e7a73be9b0eacd5fc28 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 22:33:16 +0100
+Subject: macsec: clear encryption keys from the stack after setting up offload
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit aaab73f8fba4fd38f4d2617440d541a1c334e819 ]
+
+macsec_add_rxsa and macsec_add_txsa copy the key to an on-stack
+offloading context to pass it to the drivers, but leaves it there when
+it's done. Clear it with memzero_explicit as soon as it's not needed
+anymore.
+
+Fixes: 3cf3227a21d1 ("net: macsec: hardware offloading infrastructure")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Antoine Tenart <atenart@kernel.org>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/macsec.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
+index 69108c1db130..f84e3cc0d3ec 100644
+--- a/drivers/net/macsec.c
++++ b/drivers/net/macsec.c
+@@ -1824,6 +1824,7 @@ static int macsec_add_rxsa(struct sk_buff *skb, struct genl_info *info)
+                      secy->key_len);
+               err = macsec_offload(ops->mdo_add_rxsa, &ctx);
++              memzero_explicit(ctx.sa.key, secy->key_len);
+               if (err)
+                       goto cleanup;
+       }
+@@ -2066,6 +2067,7 @@ static int macsec_add_txsa(struct sk_buff *skb, struct genl_info *info)
+                      secy->key_len);
+               err = macsec_offload(ops->mdo_add_txsa, &ctx);
++              memzero_explicit(ctx.sa.key, secy->key_len);
+               if (err)
+                       goto cleanup;
+       }
+-- 
+2.35.1
+
diff --git a/queue-5.10/macsec-delete-new-rxsc-when-offload-fails.patch b/queue-5.10/macsec-delete-new-rxsc-when-offload-fails.patch
new file mode 100644 (file)
index 0000000..11cd9e2
--- /dev/null
@@ -0,0 +1,59 @@
+From f2e8a4bcfacadcf63975437041fff557f3811785 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 22:33:13 +0100
+Subject: macsec: delete new rxsc when offload fails
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit 93a30947821c203d08865c4e17ea181c9668ce52 ]
+
+Currently we get an inconsistent state:
+ - netlink returns the error to userspace
+ - the RXSC is installed but not offloaded
+
+Then the device could get confused when we try to add an RXSA, because
+the RXSC isn't supposed to exist.
+
+Fixes: 3cf3227a21d1 ("net: macsec: hardware offloading infrastructure")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Antoine Tenart <atenart@kernel.org>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/macsec.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
+index 70c5905a916b..65e0af28c950 100644
+--- a/drivers/net/macsec.c
++++ b/drivers/net/macsec.c
+@@ -1867,7 +1867,6 @@ static int macsec_add_rxsc(struct sk_buff *skb, struct genl_info *info)
+       struct macsec_rx_sc *rx_sc;
+       struct nlattr *tb_rxsc[MACSEC_RXSC_ATTR_MAX + 1];
+       struct macsec_secy *secy;
+-      bool was_active;
+       int ret;
+       if (!attrs[MACSEC_ATTR_IFINDEX])
+@@ -1895,7 +1894,6 @@ static int macsec_add_rxsc(struct sk_buff *skb, struct genl_info *info)
+               return PTR_ERR(rx_sc);
+       }
+-      was_active = rx_sc->active;
+       if (tb_rxsc[MACSEC_RXSC_ATTR_ACTIVE])
+               rx_sc->active = !!nla_get_u8(tb_rxsc[MACSEC_RXSC_ATTR_ACTIVE]);
+@@ -1922,7 +1920,8 @@ static int macsec_add_rxsc(struct sk_buff *skb, struct genl_info *info)
+       return 0;
+ cleanup:
+-      rx_sc->active = was_active;
++      del_rx_sc(secy, sci);
++      free_rx_sc(rx_sc);
+       rtnl_unlock();
+       return ret;
+ }
+-- 
+2.35.1
+
diff --git a/queue-5.10/macsec-fix-detection-of-rxscs-when-toggling-offloadi.patch b/queue-5.10/macsec-fix-detection-of-rxscs-when-toggling-offloadi.patch
new file mode 100644 (file)
index 0000000..aa7ff41
--- /dev/null
@@ -0,0 +1,44 @@
+From 92b3dee058ab5234d25e6f0e85107f975b93bcf6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 22:33:15 +0100
+Subject: macsec: fix detection of RXSCs when toggling offloading
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit 80df4706357a5a06bbbc70273bf2611df1ceee04 ]
+
+macsec_is_configured incorrectly uses secy->n_rx_sc to check if some
+RXSCs exist. secy->n_rx_sc only counts the number of active RXSCs, but
+there can also be inactive SCs as well, which may be stored in the
+driver (in case we're disabling offloading), or would have to be
+pushed to the device (in case we're trying to enable offloading).
+
+As long as RXSCs active on creation and never turned off, the issue is
+not visible.
+
+Fixes: dcb780fb2795 ("net: macsec: add nla support for changing the offloading selection")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Antoine Tenart <atenart@kernel.org>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/macsec.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
+index a816fbbe23a7..69108c1db130 100644
+--- a/drivers/net/macsec.c
++++ b/drivers/net/macsec.c
+@@ -2562,7 +2562,7 @@ static bool macsec_is_configured(struct macsec_dev *macsec)
+       struct macsec_tx_sc *tx_sc = &secy->tx_sc;
+       int i;
+-      if (secy->n_rx_sc > 0)
++      if (secy->rx_sc)
+               return true;
+       for (i = 0; i < MACSEC_NUM_AN; i++)
+-- 
+2.35.1
+
diff --git a/queue-5.10/macsec-fix-secy-n_rx_sc-accounting.patch b/queue-5.10/macsec-fix-secy-n_rx_sc-accounting.patch
new file mode 100644 (file)
index 0000000..6ac2081
--- /dev/null
@@ -0,0 +1,82 @@
+From 20ca5cc5b1a29f1b84f2cbfb079397e1d7a3f4ce Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 22:33:14 +0100
+Subject: macsec: fix secy->n_rx_sc accounting
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit 73a4b31c9d11f98ae3bc5286d5382930adb0e9c7 ]
+
+secy->n_rx_sc is supposed to be the number of _active_ rxsc's within a
+secy. This is then used by macsec_send_sci to help decide if we should
+add the SCI to the header or not.
+
+This logic is currently broken when we create a new RXSC and turn it
+off at creation, as create_rx_sc always sets ->active to true (and
+immediately uses that to increment n_rx_sc), and only later
+macsec_add_rxsc sets rx_sc->active.
+
+Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Antoine Tenart <atenart@kernel.org>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/macsec.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
+index 65e0af28c950..a816fbbe23a7 100644
+--- a/drivers/net/macsec.c
++++ b/drivers/net/macsec.c
+@@ -1390,7 +1390,8 @@ static struct macsec_rx_sc *del_rx_sc(struct macsec_secy *secy, sci_t sci)
+       return NULL;
+ }
+-static struct macsec_rx_sc *create_rx_sc(struct net_device *dev, sci_t sci)
++static struct macsec_rx_sc *create_rx_sc(struct net_device *dev, sci_t sci,
++                                       bool active)
+ {
+       struct macsec_rx_sc *rx_sc;
+       struct macsec_dev *macsec;
+@@ -1414,7 +1415,7 @@ static struct macsec_rx_sc *create_rx_sc(struct net_device *dev, sci_t sci)
+       }
+       rx_sc->sci = sci;
+-      rx_sc->active = true;
++      rx_sc->active = active;
+       refcount_set(&rx_sc->refcnt, 1);
+       secy = &macsec_priv(dev)->secy;
+@@ -1867,6 +1868,7 @@ static int macsec_add_rxsc(struct sk_buff *skb, struct genl_info *info)
+       struct macsec_rx_sc *rx_sc;
+       struct nlattr *tb_rxsc[MACSEC_RXSC_ATTR_MAX + 1];
+       struct macsec_secy *secy;
++      bool active = true;
+       int ret;
+       if (!attrs[MACSEC_ATTR_IFINDEX])
+@@ -1888,15 +1890,15 @@ static int macsec_add_rxsc(struct sk_buff *skb, struct genl_info *info)
+       secy = &macsec_priv(dev)->secy;
+       sci = nla_get_sci(tb_rxsc[MACSEC_RXSC_ATTR_SCI]);
+-      rx_sc = create_rx_sc(dev, sci);
++      if (tb_rxsc[MACSEC_RXSC_ATTR_ACTIVE])
++              active = nla_get_u8(tb_rxsc[MACSEC_RXSC_ATTR_ACTIVE]);
++
++      rx_sc = create_rx_sc(dev, sci, active);
+       if (IS_ERR(rx_sc)) {
+               rtnl_unlock();
+               return PTR_ERR(rx_sc);
+       }
+-      if (tb_rxsc[MACSEC_RXSC_ATTR_ACTIVE])
+-              rx_sc->active = !!nla_get_u8(tb_rxsc[MACSEC_RXSC_ATTR_ACTIVE]);
+-
+       if (macsec_is_offloaded(netdev_priv(dev))) {
+               const struct macsec_ops *ops;
+               struct macsec_context ctx;
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-atlantic-macsec-clear-encryption-keys-from-the-s.patch b/queue-5.10/net-atlantic-macsec-clear-encryption-keys-from-the-s.patch
new file mode 100644 (file)
index 0000000..d6afedf
--- /dev/null
@@ -0,0 +1,98 @@
+From de5a51db8e9f981110b1671a000dc568e834a182 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 16:34:59 +0100
+Subject: net: atlantic: macsec: clear encryption keys from the stack
+
+From: Antoine Tenart <atenart@kernel.org>
+
+[ Upstream commit 879785def0f5e71d54399de0f8a5cb399db14171 ]
+
+Commit aaab73f8fba4 ("macsec: clear encryption keys from the stack after
+setting up offload") made sure to clean encryption keys from the stack
+after setting up offloading, but the atlantic driver made a copy and did
+not clear it. Fix this.
+
+[4 Fixes tags below, all part of the same series, no need to split this]
+
+Fixes: 9ff40a751a6f ("net: atlantic: MACSec ingress offload implementation")
+Fixes: b8f8a0b7b5cb ("net: atlantic: MACSec ingress offload HW bindings")
+Fixes: 27736563ce32 ("net: atlantic: MACSec egress offload implementation")
+Fixes: 9d106c6dd81b ("net: atlantic: MACSec egress offload HW bindings")
+Signed-off-by: Antoine Tenart <atenart@kernel.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/aquantia/atlantic/aq_macsec.c |  2 ++
+ .../aquantia/atlantic/macsec/macsec_api.c      | 18 +++++++++++-------
+ 2 files changed, 13 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_macsec.c b/drivers/net/ethernet/aquantia/atlantic/aq_macsec.c
+index 7c6e0811f2e6..ee823a18294c 100644
+--- a/drivers/net/ethernet/aquantia/atlantic/aq_macsec.c
++++ b/drivers/net/ethernet/aquantia/atlantic/aq_macsec.c
+@@ -585,6 +585,7 @@ static int aq_update_txsa(struct aq_nic_s *nic, const unsigned int sc_idx,
+       ret = aq_mss_set_egress_sakey_record(hw, &key_rec, sa_idx);
++      memzero_explicit(&key_rec, sizeof(key_rec));
+       return ret;
+ }
+@@ -932,6 +933,7 @@ static int aq_update_rxsa(struct aq_nic_s *nic, const unsigned int sc_idx,
+       ret = aq_mss_set_ingress_sakey_record(hw, &sa_key_record, sa_idx);
++      memzero_explicit(&sa_key_record, sizeof(sa_key_record));
+       return ret;
+ }
+diff --git a/drivers/net/ethernet/aquantia/atlantic/macsec/macsec_api.c b/drivers/net/ethernet/aquantia/atlantic/macsec/macsec_api.c
+index 36c7cf05630a..431924959520 100644
+--- a/drivers/net/ethernet/aquantia/atlantic/macsec/macsec_api.c
++++ b/drivers/net/ethernet/aquantia/atlantic/macsec/macsec_api.c
+@@ -757,6 +757,7 @@ set_ingress_sakey_record(struct aq_hw_s *hw,
+                        u16 table_index)
+ {
+       u16 packed_record[18];
++      int ret;
+       if (table_index >= NUMROWS_INGRESSSAKEYRECORD)
+               return -EINVAL;
+@@ -789,9 +790,12 @@ set_ingress_sakey_record(struct aq_hw_s *hw,
+       packed_record[16] = rec->key_len & 0x3;
+-      return set_raw_ingress_record(hw, packed_record, 18, 2,
+-                                    ROWOFFSET_INGRESSSAKEYRECORD +
+-                                            table_index);
++      ret = set_raw_ingress_record(hw, packed_record, 18, 2,
++                                   ROWOFFSET_INGRESSSAKEYRECORD +
++                                   table_index);
++
++      memzero_explicit(packed_record, sizeof(packed_record));
++      return ret;
+ }
+ int aq_mss_set_ingress_sakey_record(struct aq_hw_s *hw,
+@@ -1739,14 +1743,14 @@ static int set_egress_sakey_record(struct aq_hw_s *hw,
+       ret = set_raw_egress_record(hw, packed_record, 8, 2,
+                                   ROWOFFSET_EGRESSSAKEYRECORD + table_index);
+       if (unlikely(ret))
+-              return ret;
++              goto clear_key;
+       ret = set_raw_egress_record(hw, packed_record + 8, 8, 2,
+                                   ROWOFFSET_EGRESSSAKEYRECORD + table_index -
+                                           32);
+-      if (unlikely(ret))
+-              return ret;
+-      return 0;
++clear_key:
++      memzero_explicit(packed_record, sizeof(packed_record));
++      return ret;
+ }
+ int aq_mss_set_egress_sakey_record(struct aq_hw_s *hw,
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-broadcom-fix-bcmgenet-kconfig.patch b/queue-5.10/net-broadcom-fix-bcmgenet-kconfig.patch
new file mode 100644 (file)
index 0000000..924e9c0
--- /dev/null
@@ -0,0 +1,50 @@
+From 4fe122e397acb8ed4a9b81754caed78c09cc7771 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 5 Nov 2022 17:02:45 +0800
+Subject: net: broadcom: Fix BCMGENET Kconfig
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+[ Upstream commit 8d820bc9d12b8beebca836cceaf2bbe68216c2f8 ]
+
+While BCMGENET select BROADCOM_PHY as y, but PTP_1588_CLOCK_OPTIONAL is m,
+kconfig warning and build errors:
+
+WARNING: unmet direct dependencies detected for BROADCOM_PHY
+  Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && PTP_1588_CLOCK_OPTIONAL [=m]
+  Selected by [y]:
+  - BCMGENET [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && HAS_IOMEM [=y] && ARCH_BCM2835 [=y]
+
+drivers/net/phy/broadcom.o: In function `bcm54xx_suspend':
+broadcom.c:(.text+0x6ac): undefined reference to `bcm_ptp_stop'
+drivers/net/phy/broadcom.o: In function `bcm54xx_phy_probe':
+broadcom.c:(.text+0x784): undefined reference to `bcm_ptp_probe'
+drivers/net/phy/broadcom.o: In function `bcm54xx_config_init':
+broadcom.c:(.text+0xd4c): undefined reference to `bcm_ptp_config_init'
+
+Fixes: 99addbe31f55 ("net: broadcom: Select BROADCOM_PHY for BCMGENET")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Acked-by: Florian Fainelli <f.fainelli@broadcom.com>
+Link: https://lore.kernel.org/r/20221105090245.8508-1-yuehaibing@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
+index 7b79528d6eed..2b6d929d462f 100644
+--- a/drivers/net/ethernet/broadcom/Kconfig
++++ b/drivers/net/ethernet/broadcom/Kconfig
+@@ -69,7 +69,7 @@ config BCMGENET
+       select BCM7XXX_PHY
+       select MDIO_BCM_UNIMAC
+       select DIMLIB
+-      select BROADCOM_PHY if ARCH_BCM2835
++      select BROADCOM_PHY if (ARCH_BCM2835 && PTP_1588_CLOCK_OPTIONAL)
+       help
+         This driver supports the built-in Ethernet MACs found in the
+         Broadcom BCM7xxx Set Top Box family chipset.
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-cpsw-disable-napi-in-cpsw_ndo_open.patch b/queue-5.10/net-cpsw-disable-napi-in-cpsw_ndo_open.patch
new file mode 100644 (file)
index 0000000..f431623
--- /dev/null
@@ -0,0 +1,38 @@
+From 0192ce5a287efcad5f30c59b10c57108213c675d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 09:15:37 +0800
+Subject: net: cpsw: disable napi in cpsw_ndo_open()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 6d47b53fb3f363a74538a1dbd09954af3d8d4131 ]
+
+When failed to create xdp rxqs or fill rx channels in cpsw_ndo_open() for
+opening device, napi isn't disabled. When open cpsw device next time, it
+will report a invalid opcode issue. Compiled tested only.
+
+Fixes: d354eb85d618 ("drivers: net: cpsw: dual_emac: simplify napi usage")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221109011537.96975-1-shaozhengchao@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/ti/cpsw.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
+index b0f00b4edd94..5af0f9f8c097 100644
+--- a/drivers/net/ethernet/ti/cpsw.c
++++ b/drivers/net/ethernet/ti/cpsw.c
+@@ -864,6 +864,8 @@ static int cpsw_ndo_open(struct net_device *ndev)
+ err_cleanup:
+       if (!cpsw->usage_count) {
++              napi_disable(&cpsw->napi_rx);
++              napi_disable(&cpsw->napi_tx);
+               cpdma_ctlr_stop(cpsw->dma);
+               cpsw_destroy_xdp_rxqs(cpsw);
+       }
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-cxgb3_main-disable-napi-when-bind-qsets-failed-i.patch b/queue-5.10/net-cxgb3_main-disable-napi-when-bind-qsets-failed-i.patch
new file mode 100644 (file)
index 0000000..962d733
--- /dev/null
@@ -0,0 +1,37 @@
+From 62f96bf72b4f71849bdbf1be1d0c45d3de81ce41 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 10:14:51 +0800
+Subject: net: cxgb3_main: disable napi when bind qsets failed in cxgb_up()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit d75aed1428da787cbe42bc073d76f1354f364d92 ]
+
+When failed to bind qsets in cxgb_up() for opening device, napi isn't
+disabled. When open cxgb3 device next time, it will trigger a BUG_ON()
+in napi_enable(). Compile tested only.
+
+Fixes: 48c4b6dbb7e2 ("cxgb3 - fix port up/down error path")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221109021451.121490-1-shaozhengchao@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+index 84ad7261e243..8a167eea288c 100644
+--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
++++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+@@ -1302,6 +1302,7 @@ static int cxgb_up(struct adapter *adap)
+               if (ret < 0) {
+                       CH_ERR(adap, "failed to bind qsets, err %d\n", ret);
+                       t3_intr_disable(adap);
++                      quiesce_rx(adap);
+                       free_irq_resources(adap);
+                       err = ret;
+                       goto out;
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-fman-unregister-ethernet-device-on-removal.patch b/queue-5.10/net-fman-unregister-ethernet-device-on-removal.patch
new file mode 100644 (file)
index 0000000..b7af79a
--- /dev/null
@@ -0,0 +1,53 @@
+From ca1ffa90f2e945719ea1bd9574ff05dc46a10ebc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 14:28:30 -0400
+Subject: net: fman: Unregister ethernet device on removal
+
+From: Sean Anderson <sean.anderson@seco.com>
+
+[ Upstream commit b7cbc6740bd6ad5d43345a2504f7e4beff0d709f ]
+
+When the mac device gets removed, it leaves behind the ethernet device.
+This will result in a segfault next time the ethernet device accesses
+mac_dev. Remove the ethernet device when we get removed to prevent
+this. This is not completely reversible, since some resources aren't
+cleaned up properly, but that can be addressed later.
+
+Fixes: 3933961682a3 ("fsl/fman: Add FMan MAC driver")
+Signed-off-by: Sean Anderson <sean.anderson@seco.com>
+Link: https://lore.kernel.org/r/20221103182831.2248833-1-sean.anderson@seco.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/freescale/fman/mac.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
+index 6eeccc11b76e..3312dc4083a0 100644
+--- a/drivers/net/ethernet/freescale/fman/mac.c
++++ b/drivers/net/ethernet/freescale/fman/mac.c
+@@ -884,12 +884,21 @@ static int mac_probe(struct platform_device *_of_dev)
+       return err;
+ }
++static int mac_remove(struct platform_device *pdev)
++{
++      struct mac_device *mac_dev = platform_get_drvdata(pdev);
++
++      platform_device_unregister(mac_dev->priv->eth_dev);
++      return 0;
++}
++
+ static struct platform_driver mac_driver = {
+       .driver = {
+               .name           = KBUILD_MODNAME,
+               .of_match_table = mac_match,
+       },
+       .probe          = mac_probe,
++      .remove         = mac_remove,
+ };
+ builtin_platform_driver(mac_driver);
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-gso-fix-panic-on-frag_list-with-mixed-head-alloc.patch b/queue-5.10/net-gso-fix-panic-on-frag_list-with-mixed-head-alloc.patch
new file mode 100644 (file)
index 0000000..b67f69e
--- /dev/null
@@ -0,0 +1,105 @@
+From 0e6ad4ca54ab1c3c52334263a4f9dc4c44681899 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 17:53:25 +0100
+Subject: net: gso: fix panic on frag_list with mixed head alloc types
+
+From: Jiri Benc <jbenc@redhat.com>
+
+[ Upstream commit 9e4b7a99a03aefd37ba7bb1f022c8efab5019165 ]
+
+Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when
+splitting gso_size mangled skb having linear-headed frag_list"), it is
+allowed to change gso_size of a GRO packet. However, that commit assumes
+that "checking the first list_skb member suffices; i.e if either of the
+list_skb members have non head_frag head, then the first one has too".
+
+It turns out this assumption does not hold. We've seen BUG_ON being hit
+in skb_segment when skbs on the frag_list had differing head_frag with
+the vmxnet3 driver. This happens because __netdev_alloc_skb and
+__napi_alloc_skb can return a skb that is page backed or kmalloced
+depending on the requested size. As the result, the last small skb in
+the GRO packet can be kmalloced.
+
+There are three different locations where this can be fixed:
+
+(1) We could check head_frag in GRO and not allow GROing skbs with
+    different head_frag. However, that would lead to performance
+    regression on normal forward paths with unmodified gso_size, where
+    !head_frag in the last packet is not a problem.
+
+(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating
+    that NETIF_F_SG is undesirable. That would need to eat a bit in
+    sk_buff. Furthermore, that flag can be unset when all skbs on the
+    frag_list are page backed. To retain good performance,
+    bpf_skb_net_grow/shrink would have to walk the frag_list.
+
+(3) Walk the frag_list in skb_segment when determining whether
+    NETIF_F_SG should be cleared. This of course slows things down.
+
+This patch implements (3). To limit the performance impact in
+skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set
+that have gso_size changed. Normal paths thus will not hit it.
+
+We could check only the last skb but since we need to walk the whole
+list anyway, let's stay on the safe side.
+
+Fixes: 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list")
+Signed-off-by: Jiri Benc <jbenc@redhat.com>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Link: https://lore.kernel.org/r/e04426a6a91baf4d1081e1b478c82b5de25fdf21.1667407944.git.jbenc@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/skbuff.c | 36 +++++++++++++++++++-----------------
+ 1 file changed, 19 insertions(+), 17 deletions(-)
+
+diff --git a/net/core/skbuff.c b/net/core/skbuff.c
+index 7bdcdad58dc8..06169889b0ca 100644
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -3809,23 +3809,25 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
+       int i = 0;
+       int pos;
+-      if (list_skb && !list_skb->head_frag && skb_headlen(list_skb) &&
+-          (skb_shinfo(head_skb)->gso_type & SKB_GSO_DODGY)) {
+-              /* gso_size is untrusted, and we have a frag_list with a linear
+-               * non head_frag head.
+-               *
+-               * (we assume checking the first list_skb member suffices;
+-               * i.e if either of the list_skb members have non head_frag
+-               * head, then the first one has too).
+-               *
+-               * If head_skb's headlen does not fit requested gso_size, it
+-               * means that the frag_list members do NOT terminate on exact
+-               * gso_size boundaries. Hence we cannot perform skb_frag_t page
+-               * sharing. Therefore we must fallback to copying the frag_list
+-               * skbs; we do so by disabling SG.
+-               */
+-              if (mss != GSO_BY_FRAGS && mss != skb_headlen(head_skb))
+-                      features &= ~NETIF_F_SG;
++      if ((skb_shinfo(head_skb)->gso_type & SKB_GSO_DODGY) &&
++          mss != GSO_BY_FRAGS && mss != skb_headlen(head_skb)) {
++              struct sk_buff *check_skb;
++
++              for (check_skb = list_skb; check_skb; check_skb = check_skb->next) {
++                      if (skb_headlen(check_skb) && !check_skb->head_frag) {
++                              /* gso_size is untrusted, and we have a frag_list with
++                               * a linear non head_frag item.
++                               *
++                               * If head_skb's headlen does not fit requested gso_size,
++                               * it means that the frag_list members do NOT terminate
++                               * on exact gso_size boundaries. Hence we cannot perform
++                               * skb_frag_t page sharing. Therefore we must fallback to
++                               * copying the frag_list skbs; we do so by disabling SG.
++                               */
++                              features &= ~NETIF_F_SG;
++                              break;
++                      }
++              }
+       }
+       __skb_push(head_skb, doffset);
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-lapbether-fix-issue-of-dev-reference-count-leaka.patch b/queue-5.10/net-lapbether-fix-issue-of-dev-reference-count-leaka.patch
new file mode 100644 (file)
index 0000000..3de9e57
--- /dev/null
@@ -0,0 +1,49 @@
+From 0d4fe0ce9fbf77dbc54bd54be362f72cb6d11ecd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Nov 2022 17:05:37 +0800
+Subject: net: lapbether: fix issue of dev reference count leakage in
+ lapbeth_device_event()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 531705a765493655472c993627106e19f7e5a6d2 ]
+
+When following tests are performed, it will cause dev reference counting
+leakage.
+a)ip link add bond2 type bond mode balance-rr
+b)ip link set bond2 up
+c)ifenslave -f bond2 rose1
+d)ip link del bond2
+
+When new bond device is created, the default type of the bond device is
+ether. And the bond device is up, lapbeth_device_event() receives the
+message and creates a new lapbeth device. In this case, the reference
+count value of dev is hold once. But after "ifenslave -f bond2 rose1"
+command is executed, the type of the bond device is changed to rose. When
+the bond device is unregistered, lapbeth_device_event() will not put the
+dev reference count.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wan/lapbether.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
+index f6562a343cb4..b965eb6a4bb1 100644
+--- a/drivers/net/wan/lapbether.c
++++ b/drivers/net/wan/lapbether.c
+@@ -403,7 +403,7 @@ static int lapbeth_device_event(struct notifier_block *this,
+       if (dev_net(dev) != &init_net)
+               return NOTIFY_DONE;
+-      if (!dev_is_ethdev(dev))
++      if (!dev_is_ethdev(dev) && !lapbeth_get_x25_dev(dev))
+               return NOTIFY_DONE;
+       switch (event) {
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-macvlan-fix-memory-leaks-of-macvlan_common_newli.patch b/queue-5.10/net-macvlan-fix-memory-leaks-of-macvlan_common_newli.patch
new file mode 100644 (file)
index 0000000..0515edc
--- /dev/null
@@ -0,0 +1,68 @@
+From 2c8cf46889d6998d6fa14d77ab90bb0f94982900 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 17:07:34 +0800
+Subject: net: macvlan: fix memory leaks of macvlan_common_newlink
+
+From: Chuang Wang <nashuiliang@gmail.com>
+
+[ Upstream commit 23569b5652ee8e8e55a12f7835f59af6f3cefc30 ]
+
+kmemleak reports memory leaks in macvlan_common_newlink, as follows:
+
+ ip link add link eth0 name .. type macvlan mode source macaddr add
+ <MAC-ADDR>
+
+kmemleak reports:
+
+unreferenced object 0xffff8880109bb140 (size 64):
+  comm "ip", pid 284, jiffies 4294986150 (age 430.108s)
+  hex dump (first 32 bytes):
+    00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff  ..........Z.....
+    80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b  ..............kk
+  backtrace:
+    [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300
+    [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0
+    [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170
+    [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0
+    [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20
+    [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50
+    [<ffffffff81d98278>] rtnl_newlink+0x48/0x70
+    ...
+
+In the scenario where the macvlan mode is configured as 'source',
+macvlan_changelink_sources() will be execured to reconfigure list of
+remote source mac addresses, at the same time, if register_netdevice()
+return an error, the resource generated by macvlan_changelink_sources()
+is not cleaned up.
+
+Using this patch, in the case of an error, it will execute
+macvlan_flush_sources() to ensure that the resource is cleaned up.
+
+Fixes: aa5fd0fb7748 ("driver: macvlan: Destroy new macvlan port if macvlan_common_newlink failed.")
+Signed-off-by: Chuang Wang <nashuiliang@gmail.com>
+Link: https://lore.kernel.org/r/20221109090735.690500-1-nashuiliang@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/macvlan.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
+index c8d803d3616c..6b269a72388b 100644
+--- a/drivers/net/macvlan.c
++++ b/drivers/net/macvlan.c
+@@ -1509,8 +1509,10 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
+       /* the macvlan port may be freed by macvlan_uninit when fail to register.
+        * so we destroy the macvlan port only when it's valid.
+        */
+-      if (create && macvlan_port_get_rtnl(lowerdev))
++      if (create && macvlan_port_get_rtnl(lowerdev)) {
++              macvlan_flush_sources(port, vlan);
+               macvlan_port_destroy(port->dev);
++      }
+       return err;
+ }
+ EXPORT_SYMBOL_GPL(macvlan_common_newlink);
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-marvell-prestera-fix-memory-leak-in-prestera_rxt.patch b/queue-5.10/net-marvell-prestera-fix-memory-leak-in-prestera_rxt.patch
new file mode 100644 (file)
index 0000000..e5e4856
--- /dev/null
@@ -0,0 +1,51 @@
+From 29307d10cf2abd4a0feaa24dad91610746a4eb35 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 10:56:07 +0800
+Subject: net: marvell: prestera: fix memory leak in
+ prestera_rxtx_switch_init()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 519b58bbfa825f042fcf80261cc18e1e35f85ffd ]
+
+When prestera_sdma_switch_init() failed, the memory pointed to by
+sw->rxtx isn't released. Fix it. Only be compiled, not be tested.
+
+Fixes: 501ef3066c89 ("net: marvell: prestera: Add driver for Prestera family ASIC devices")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Reviewed-by: Vadym Kochan <vadym.kochan@plvision.eu>
+Link: https://lore.kernel.org/r/20221108025607.338450-1-shaozhengchao@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/prestera/prestera_rxtx.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c b/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c
+index 2a13c318048c..59a3ea02b8ad 100644
+--- a/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c
++++ b/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c
+@@ -771,6 +771,7 @@ static netdev_tx_t prestera_sdma_xmit(struct prestera_sdma *sdma,
+ int prestera_rxtx_switch_init(struct prestera_switch *sw)
+ {
+       struct prestera_rxtx *rxtx;
++      int err;
+       rxtx = kzalloc(sizeof(*rxtx), GFP_KERNEL);
+       if (!rxtx)
+@@ -778,7 +779,11 @@ int prestera_rxtx_switch_init(struct prestera_switch *sw)
+       sw->rxtx = rxtx;
+-      return prestera_sdma_switch_init(sw);
++      err = prestera_sdma_switch_init(sw);
++      if (err)
++              kfree(rxtx);
++
++      return err;
+ }
+ void prestera_rxtx_switch_fini(struct prestera_switch *sw)
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-mlx5-allow-async-trigger-completion-execution-on.patch b/queue-5.10/net-mlx5-allow-async-trigger-completion-execution-on.patch
new file mode 100644 (file)
index 0000000..507dd68
--- /dev/null
@@ -0,0 +1,58 @@
+From 158878a1d2dab783e1ec66d5aefc62636ada1907 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 23:55:38 -0700
+Subject: net/mlx5: Allow async trigger completion execution on single CPU
+ systems
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Roy Novich <royno@nvidia.com>
+
+[ Upstream commit 2808b37b59288ad8f1897e3546c2296df3384b65 ]
+
+For a single CPU system, the kernel thread executing mlx5_cmd_flush()
+never releases the CPU but calls down_trylock(&cmd→sem) in a busy loop.
+On a single processor system, this leads to a deadlock as the kernel
+thread which executes mlx5_cmd_invoke() never gets scheduled. Fix this,
+by adding the cond_resched() call to the loop, allow the command
+completion kernel thread to execute.
+
+Fixes: 8e715cd613a1 ("net/mlx5: Set command entry semaphore up once got index free")
+Signed-off-by: Alexander Schmidt <alexschm@de.ibm.com>
+Signed-off-by: Roy Novich <royno@nvidia.com>
+Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+index 6612b2c0be48..cf07318048df 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+@@ -1687,12 +1687,17 @@ void mlx5_cmd_flush(struct mlx5_core_dev *dev)
+       struct mlx5_cmd *cmd = &dev->cmd;
+       int i;
+-      for (i = 0; i < cmd->max_reg_cmds; i++)
+-              while (down_trylock(&cmd->sem))
++      for (i = 0; i < cmd->max_reg_cmds; i++) {
++              while (down_trylock(&cmd->sem)) {
+                       mlx5_cmd_trigger_completions(dev);
++                      cond_resched();
++              }
++      }
+-      while (down_trylock(&cmd->pages_sem))
++      while (down_trylock(&cmd->pages_sem)) {
+               mlx5_cmd_trigger_completions(dev);
++              cond_resched();
++      }
+       /* Unlock cmdif */
+       up(&cmd->pages_sem);
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-mlx5e-e-switch-fix-comparing-termination-table-i.patch b/queue-5.10/net-mlx5e-e-switch-fix-comparing-termination-table-i.patch
new file mode 100644 (file)
index 0000000..e915aa5
--- /dev/null
@@ -0,0 +1,60 @@
+From e46f8c88e678d61a58b6da4f560379d5183c01ff Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 23:55:46 -0700
+Subject: net/mlx5e: E-Switch, Fix comparing termination table instance
+
+From: Roi Dayan <roid@nvidia.com>
+
+[ Upstream commit f4f4096b410e8d31c3f07f39de3b17d144edd53d ]
+
+The pkt_reformat pointer being saved under flow_act and not
+dest attribute in the termination table instance.
+Fix the comparison pointers.
+
+Also fix returning success if one pkt_reformat pointer is null
+and the other is not.
+
+Fixes: 249ccc3c95bd ("net/mlx5e: Add support for offloading traffic from uplink to uplink")
+Signed-off-by: Roi Dayan <roid@nvidia.com>
+Reviewed-by: Chris Mi <cmi@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../mellanox/mlx5/core/eswitch_offloads_termtbl.c  | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
+index 1cbb330b9f42..6c865cb7f445 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c
+@@ -30,9 +30,9 @@ mlx5_eswitch_termtbl_hash(struct mlx5_flow_act *flow_act,
+                    sizeof(dest->vport.num), hash);
+       hash = jhash((const void *)&dest->vport.vhca_id,
+                    sizeof(dest->vport.num), hash);
+-      if (dest->vport.pkt_reformat)
+-              hash = jhash(dest->vport.pkt_reformat,
+-                           sizeof(*dest->vport.pkt_reformat),
++      if (flow_act->pkt_reformat)
++              hash = jhash(flow_act->pkt_reformat,
++                           sizeof(*flow_act->pkt_reformat),
+                            hash);
+       return hash;
+ }
+@@ -53,9 +53,11 @@ mlx5_eswitch_termtbl_cmp(struct mlx5_flow_act *flow_act1,
+       if (ret)
+               return ret;
+-      return dest1->vport.pkt_reformat && dest2->vport.pkt_reformat ?
+-             memcmp(dest1->vport.pkt_reformat, dest2->vport.pkt_reformat,
+-                    sizeof(*dest1->vport.pkt_reformat)) : 0;
++      if (flow_act1->pkt_reformat && flow_act2->pkt_reformat)
++              return memcmp(flow_act1->pkt_reformat, flow_act2->pkt_reformat,
++                            sizeof(*flow_act1->pkt_reformat));
++
++      return !(flow_act1->pkt_reformat == flow_act2->pkt_reformat);
+ }
+ static int
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-mv643xx_eth-disable-napi-when-init-rxq-or-txq-fa.patch b/queue-5.10/net-mv643xx_eth-disable-napi-when-init-rxq-or-txq-fa.patch
new file mode 100644 (file)
index 0000000..1368476
--- /dev/null
@@ -0,0 +1,38 @@
+From eff31d135fb46a4df7be8dfda1d382b2271f9f5e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Nov 2022 10:54:32 +0800
+Subject: net: mv643xx_eth: disable napi when init rxq or txq failed in
+ mv643xx_eth_open()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit f111606b63ff2282428ffbac0447c871eb957b6c ]
+
+When failed to init rxq or txq in mv643xx_eth_open() for opening device,
+napi isn't disabled. When open mv643xx_eth device next time, it will
+trigger a BUG_ON() in napi_enable(). Compile tested only.
+
+Fixes: 2257e05c1705 ("mv643xx_eth: get rid of receive-side locking")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221109025432.80900-1-shaozhengchao@huawei.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/mv643xx_eth.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
+index 90e6111ce534..735b76effc49 100644
+--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
++++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
+@@ -2471,6 +2471,7 @@ static int mv643xx_eth_open(struct net_device *dev)
+       for (i = 0; i < mp->rxq_count; i++)
+               rxq_deinit(mp->rxq + i);
+ out:
++      napi_disable(&mp->napi);
+       free_irq(dev->irq, dev);
+       return err;
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-nixge-disable-napi-when-enable-interrupts-failed.patch b/queue-5.10/net-nixge-disable-napi-when-enable-interrupts-failed.patch
new file mode 100644 (file)
index 0000000..38eafc9
--- /dev/null
@@ -0,0 +1,38 @@
+From 9ee353fe1942311d224dff914061ce4870d0badd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Nov 2022 18:14:43 +0800
+Subject: net: nixge: disable napi when enable interrupts failed in
+ nixge_open()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit b06334919c7a068d54ba5b219c05e919d89943f7 ]
+
+When failed to enable interrupts in nixge_open() for opening device,
+napi isn't disabled. When open nixge device next time, it will reports
+a invalid opcode issue. Fix it. Only be compiled, not be tested.
+
+Fixes: 492caffa8a1a ("net: ethernet: nixge: Add support for National Instruments XGE netdev")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Link: https://lore.kernel.org/r/20221107101443.120205-1-shaozhengchao@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/ni/nixge.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
+index a6861df9904f..9c48fd85c418 100644
+--- a/drivers/net/ethernet/ni/nixge.c
++++ b/drivers/net/ethernet/ni/nixge.c
+@@ -899,6 +899,7 @@ static int nixge_open(struct net_device *ndev)
+ err_rx_irq:
+       free_irq(priv->tx_irq, ndev);
+ err_tx_irq:
++      napi_disable(&priv->napi);
+       phy_stop(phy);
+       phy_disconnect(phy);
+       tasklet_kill(&priv->dma_err_tasklet);
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-phy-mscc-macsec-clear-encryption-keys-when-freei.patch b/queue-5.10/net-phy-mscc-macsec-clear-encryption-keys-when-freei.patch
new file mode 100644 (file)
index 0000000..1bcf9a3
--- /dev/null
@@ -0,0 +1,37 @@
+From ca196da9c883b51e302e8c934989a744e53a5838 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Nov 2022 16:34:58 +0100
+Subject: net: phy: mscc: macsec: clear encryption keys when freeing a flow
+
+From: Antoine Tenart <atenart@kernel.org>
+
+[ Upstream commit 1b16b3fdf675cca15a537572bac50cc5354368fc ]
+
+Commit aaab73f8fba4 ("macsec: clear encryption keys from the stack after
+setting up offload") made sure to clean encryption keys from the stack
+after setting up offloading, but the MSCC PHY driver made a copy, kept
+it in the flow data and did not clear it when freeing a flow. Fix this.
+
+Fixes: 28c5107aa904 ("net: phy: mscc: macsec support")
+Signed-off-by: Antoine Tenart <atenart@kernel.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/phy/mscc/mscc_macsec.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/phy/mscc/mscc_macsec.c b/drivers/net/phy/mscc/mscc_macsec.c
+index b7b2521c73fb..c00eef457b85 100644
+--- a/drivers/net/phy/mscc/mscc_macsec.c
++++ b/drivers/net/phy/mscc/mscc_macsec.c
+@@ -632,6 +632,7 @@ static void vsc8584_macsec_free_flow(struct vsc8531_private *priv,
+       list_del(&flow->list);
+       clear_bit(flow->index, bitmap);
++      memzero_explicit(flow->key, sizeof(flow->key));
+       kfree(flow);
+ }
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-stmmac-dwmac-meson8b-fix-meson8b_devm_clk_prepar.patch b/queue-5.10/net-stmmac-dwmac-meson8b-fix-meson8b_devm_clk_prepar.patch
new file mode 100644 (file)
index 0000000..4d70a38
--- /dev/null
@@ -0,0 +1,55 @@
+From 70d76926493d6419254e28a1c8fe891ba40607cc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Nov 2022 09:30:04 +0100
+Subject: net: stmmac: dwmac-meson8b: fix meson8b_devm_clk_prepare_enable()
+
+From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+
+[ Upstream commit ed4314f7729714d788698ade4f9905ee5378ebc0 ]
+
+There are two problems with meson8b_devm_clk_prepare_enable(),
+introduced in commit a54dc4a49045 ("net: stmmac: dwmac-meson8b:
+Make the clock enabling code re-usable"):
+
+- It doesn't pass the clk argument, but instead always the
+  rgmii_tx_clk of the device.
+
+- It silently ignores the return value of devm_add_action_or_reset().
+
+The former didn't become an actual bug until another user showed up in
+the next commit 9308c47640d5 ("net: stmmac: dwmac-meson8b: add support
+for the RX delay configuration"). The latter means the callers could
+end up with the clock not actually prepared/enabled.
+
+Fixes: a54dc4a49045 ("net: stmmac: dwmac-meson8b: Make the clock enabling code re-usable")
+Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Link: https://lore.kernel.org/r/20221104083004.2212520-1-linux@rasmusvillemoes.dk
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+index 752658ec7bee..50ef68497bce 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+@@ -261,11 +261,9 @@ static int meson8b_devm_clk_prepare_enable(struct meson8b_dwmac *dwmac,
+       if (ret)
+               return ret;
+-      devm_add_action_or_reset(dwmac->dev,
+-                               (void(*)(void *))clk_disable_unprepare,
+-                               dwmac->rgmii_tx_clk);
+-
+-      return 0;
++      return devm_add_action_or_reset(dwmac->dev,
++                                      (void(*)(void *))clk_disable_unprepare,
++                                      clk);
+ }
+ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
+-- 
+2.35.1
+
diff --git a/queue-5.10/net-tun-fix-memory-leaks-of-napi_get_frags.patch b/queue-5.10/net-tun-fix-memory-leaks-of-napi_get_frags.patch
new file mode 100644 (file)
index 0000000..d18a385
--- /dev/null
@@ -0,0 +1,73 @@
+From d6fb42a0c574bdb2e8e47ec1cb89e9611dee6bc8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 17:41:19 +0800
+Subject: net: tun: Fix memory leaks of napi_get_frags
+
+From: Wang Yufen <wangyufen@huawei.com>
+
+[ Upstream commit 1118b2049d77ca0b505775fc1a8d1909cf19a7ec ]
+
+kmemleak reports after running test_progs:
+
+unreferenced object 0xffff8881b1672dc0 (size 232):
+  comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s)
+  hex dump (first 32 bytes):
+    e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff  .........,g.....
+    00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00  .@..............
+  backtrace:
+    [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150
+    [<0000000041c7fc09>] __napi_build_skb+0x15/0x50
+    [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540
+    [<000000003ecfa30e>] napi_get_frags+0x59/0x140
+    [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun]
+    [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun]
+    [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320
+    [<000000008f338ea2>] do_iter_write+0x135/0x630
+    [<000000008a3377a4>] vfs_writev+0x12e/0x440
+    [<00000000a6b5639a>] do_writev+0x104/0x280
+    [<00000000ccf065d8>] do_syscall_64+0x3b/0x90
+    [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
+
+The issue occurs in the following scenarios:
+tun_get_user()
+  napi_gro_frags()
+    napi_frags_finish()
+      case GRO_NORMAL:
+        gro_normal_one()
+          list_add_tail(&skb->list, &napi->rx_list);
+          <-- While napi->rx_count < READ_ONCE(gro_normal_batch),
+          <-- gro_normal_list() is not called, napi->rx_list is not empty
+  <-- not ask to complete the gro work, will cause memory leaks in
+  <-- following tun_napi_del()
+...
+tun_napi_del()
+  netif_napi_del()
+    __netif_napi_del()
+    <-- &napi->rx_list is not empty, which caused memory leaks
+
+To fix, add napi_complete() after napi_gro_frags().
+
+Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
+Signed-off-by: Wang Yufen <wangyufen@huawei.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>
+---
+ drivers/net/tun.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/tun.c b/drivers/net/tun.c
+index 0c09f8e9d383..83662f616b67 100644
+--- a/drivers/net/tun.c
++++ b/drivers/net/tun.c
+@@ -1996,6 +1996,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
+               local_bh_disable();
+               napi_gro_frags(&tfile->napi);
++              napi_complete(&tfile->napi);
+               local_bh_enable();
+               mutex_unlock(&tfile->napi_mutex);
+       } else if (tfile->napi_enabled) {
+-- 
+2.35.1
+
diff --git a/queue-5.10/perf-stat-fix-printing-os-prefix-in-csv-metrics-outp.patch b/queue-5.10/perf-stat-fix-printing-os-prefix-in-csv-metrics-outp.patch
new file mode 100644 (file)
index 0000000..0f971c3
--- /dev/null
@@ -0,0 +1,124 @@
+From c924c8b830ad575fabb9ad4182afe3fe263c7d46 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Oct 2022 14:26:04 +0530
+Subject: perf stat: Fix printing os->prefix in CSV metrics output
+
+From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
+
+[ Upstream commit ad353b710c7493df3d4fc2d3a51819126bed2e81 ]
+
+'perf stat' with CSV output option prints an extra empty string as first
+field in metrics output line.  Sample output below:
+
+       # ./perf stat -x, --per-socket -a -C 1 ls
+       S0,1,1.78,msec,cpu-clock,1785146,100.00,0.973,CPUs utilized
+       S0,1,26,,context-switches,1781750,100.00,0.015,M/sec
+       S0,1,1,,cpu-migrations,1780526,100.00,0.561,K/sec
+       S0,1,1,,page-faults,1779060,100.00,0.561,K/sec
+       S0,1,875807,,cycles,1769826,100.00,0.491,GHz
+       S0,1,85281,,stalled-cycles-frontend,1767512,100.00,9.74,frontend cycles idle
+       S0,1,576839,,stalled-cycles-backend,1766260,100.00,65.86,backend cycles idle
+       S0,1,288430,,instructions,1762246,100.00,0.33,insn per cycle
+====>  ,S0,1,,,,,,,2.00,stalled cycles per insn
+
+The above command line uses field separator as "," via "-x," option and
+per-socket option displays socket value as first field. But here the
+last line for "stalled cycles per insn" has "," in the beginning.
+
+Sample output using interval mode:
+
+       # ./perf stat -I 1000 -x, --per-socket -a -C 1 ls
+       0.001813453,S0,1,1.87,msec,cpu-clock,1872052,100.00,0.002,CPUs utilized
+       0.001813453,S0,1,2,,context-switches,1868028,100.00,1.070,K/sec
+       ------
+       0.001813453,S0,1,85379,,instructions,1856754,100.00,0.32,insn per cycle
+====>  0.001813453,,S0,1,,,,,,,1.34,stalled cycles per insn
+
+Above result also has an extra CSV separator after
+the timestamp. Patch addresses extra field separator
+in the beginning of the metric output line.
+
+The counter stats are displayed by function
+"perf_stat__print_shadow_stats" in code
+"util/stat-shadow.c". While printing the stats info
+for "stalled cycles per insn", function "new_line_csv"
+is used as new_line callback.
+
+The new_line_csv function has check for "os->prefix"
+and if prefix is not null, it will be printed along
+with cvs separator.
+Snippet from "new_line_csv":
+       if (os->prefix)
+               fprintf(os->fh, "%s%s", os->prefix, config->csv_sep);
+
+Here os->prefix gets printed followed by ","
+which is the cvs separator. The os->prefix is
+used in interval mode option ( -I ), to print
+time stamp on every new line. But prefix is
+already set to contain CSV separator when used
+in interval mode for CSV option.
+
+Reference: Function "static void print_interval"
+Snippet:
+       sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, config->csv_sep);
+
+Also if prefix is not assigned (if not used with
+-I option), it gets set to empty string.
+Reference: function printout() in util/stat-display.c
+Snippet:
+       .prefix = prefix ? prefix : "",
+
+Since prefix already set to contain cvs_sep in interval
+option, patch removes printing config->csv_sep in
+new_line_csv function to avoid printing extra field.
+
+After the patch:
+
+       # ./perf stat -x, --per-socket -a -C 1 ls
+       S0,1,2.04,msec,cpu-clock,2045202,100.00,1.013,CPUs utilized
+       S0,1,2,,context-switches,2041444,100.00,979.289,/sec
+       S0,1,0,,cpu-migrations,2040820,100.00,0.000,/sec
+       S0,1,2,,page-faults,2040288,100.00,979.289,/sec
+       S0,1,254589,,cycles,2036066,100.00,0.125,GHz
+       S0,1,82481,,stalled-cycles-frontend,2032420,100.00,32.40,frontend cycles idle
+       S0,1,113170,,stalled-cycles-backend,2031722,100.00,44.45,backend cycles idle
+       S0,1,88766,,instructions,2030942,100.00,0.35,insn per cycle
+       S0,1,,,,,,,1.27,stalled cycles per insn
+
+Fixes: 92a61f6412d3a09d ("perf stat: Implement CSV metrics output")
+Reported-by: Disha Goel <disgoel@linux.vnet.ibm.com>
+Reviewed-By: Kajol Jain <kjain@linux.ibm.com>
+Signed-off-by: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
+Tested-by: Disha Goel <disgoel@linux.vnet.ibm.com>
+Cc: Andi Kleen <ak@linux.intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: James Clark <james.clark@arm.com>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: linuxppc-dev@lists.ozlabs.org
+Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
+Cc: Michael Ellerman <mpe@ellerman.id.au>
+Cc: Nageswara R Sastry <rnsastry@linux.ibm.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Link: https://lore.kernel.org/r/20221018085605.63834-1-atrajeev@linux.vnet.ibm.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/util/stat-display.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
+index 96fe9c1af336..4688e39de52a 100644
+--- a/tools/perf/util/stat-display.c
++++ b/tools/perf/util/stat-display.c
+@@ -203,7 +203,7 @@ static void new_line_csv(struct perf_stat_config *config, void *ctx)
+       fputc('\n', os->fh);
+       if (os->prefix)
+-              fprintf(os->fh, "%s%s", os->prefix, config->csv_sep);
++              fprintf(os->fh, "%s", os->prefix);
+       aggr_printout(config, os->evsel, os->id, os->nr);
+       for (i = 0; i < os->nfields; i++)
+               fputs(config->csv_sep, os->fh);
+-- 
+2.35.1
+
diff --git a/queue-5.10/phy-stm32-fix-an-error-code-in-probe.patch b/queue-5.10/phy-stm32-fix-an-error-code-in-probe.patch
new file mode 100644 (file)
index 0000000..431d297
--- /dev/null
@@ -0,0 +1,38 @@
+From 21d97a037c41b9cd54359190475744e51c0d7d3e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 14 Oct 2022 12:25:06 +0300
+Subject: phy: stm32: fix an error code in probe
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit ca1c73628f5bd0c1ef6e46073cc3be2450605b06 ]
+
+If "index > usbphyc->nphys" is true then this returns success but it
+should return -EINVAL.
+
+Fixes: 94c358da3a05 ("phy: stm32: add support for STM32 USB PHY Controller (USBPHYC)")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Link: https://lore.kernel.org/r/Y0kq8j6S+5nDdMpr@kili
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/phy/st/phy-stm32-usbphyc.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/phy/st/phy-stm32-usbphyc.c b/drivers/phy/st/phy-stm32-usbphyc.c
+index 2b3639cba51a..03fc567e9f18 100644
+--- a/drivers/phy/st/phy-stm32-usbphyc.c
++++ b/drivers/phy/st/phy-stm32-usbphyc.c
+@@ -393,6 +393,8 @@ static int stm32_usbphyc_probe(struct platform_device *pdev)
+               ret = of_property_read_u32(child, "reg", &index);
+               if (ret || index > usbphyc->nphys) {
+                       dev_err(&phy->dev, "invalid reg property: %d\n", ret);
++                      if (!ret)
++                              ret = -EINVAL;
+                       goto put_child;
+               }
+-- 
+2.35.1
+
diff --git a/queue-5.10/riscv-enable-cma-support.patch b/queue-5.10/riscv-enable-cma-support.patch
new file mode 100644 (file)
index 0000000..538f474
--- /dev/null
@@ -0,0 +1,69 @@
+From ed2ac729e9e16433f93e50b892f16d4f10560481 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 31 Oct 2020 14:01:12 +0800
+Subject: riscv: Enable CMA support
+
+From: Kefeng Wang <wangkefeng.wang@huawei.com>
+
+[ Upstream commit da815582cf4594e96defa1cddb72cd00b1e7aac5 ]
+
+riscv has selected HAVE_DMA_CONTIGUOUS, but doesn't call
+dma_contiguous_reserve().  This calls dma_contiguous_reserve(), which
+enables CMA.
+
+Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
+Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
+Stable-dep-of: 50e63dd8ed92 ("riscv: fix reserved memory setup")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/mm/init.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
+index e8921e78a292..56314e82f051 100644
+--- a/arch/riscv/mm/init.c
++++ b/arch/riscv/mm/init.c
+@@ -13,6 +13,7 @@
+ #include <linux/of_fdt.h>
+ #include <linux/libfdt.h>
+ #include <linux/set_memory.h>
++#include <linux/dma-map-ops.h>
+ #include <asm/fixmap.h>
+ #include <asm/tlbflush.h>
+@@ -41,13 +42,14 @@ struct pt_alloc_ops {
+ #endif
+ };
++static phys_addr_t dma32_phys_limit __ro_after_init;
++
+ static void __init zone_sizes_init(void)
+ {
+       unsigned long max_zone_pfns[MAX_NR_ZONES] = { 0, };
+ #ifdef CONFIG_ZONE_DMA32
+-      max_zone_pfns[ZONE_DMA32] = PFN_DOWN(min(4UL * SZ_1G,
+-                      (unsigned long) PFN_PHYS(max_low_pfn)));
++      max_zone_pfns[ZONE_DMA32] = PFN_DOWN(dma32_phys_limit);
+ #endif
+       max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+@@ -193,6 +195,7 @@ void __init setup_bootmem(void)
+       max_pfn = PFN_DOWN(dram_end);
+       max_low_pfn = max_pfn;
++      dma32_phys_limit = min(4UL * SZ_1G, (unsigned long)PFN_PHYS(max_low_pfn));
+       set_max_mapnr(max_low_pfn);
+ #ifdef CONFIG_BLK_DEV_INITRD
+@@ -206,6 +209,7 @@ void __init setup_bootmem(void)
+       memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va));
+       early_init_fdt_scan_reserved_mem();
++      dma_contiguous_reserve(dma32_phys_limit);
+       memblock_allow_resize();
+       memblock_dump_all();
+ }
+-- 
+2.35.1
+
diff --git a/queue-5.10/riscv-fix-reserved-memory-setup.patch b/queue-5.10/riscv-fix-reserved-memory-setup.patch
new file mode 100644 (file)
index 0000000..1076332
--- /dev/null
@@ -0,0 +1,106 @@
+From ae397d332b3311242fba38e9f09fd71a938f6ef9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Nov 2022 15:15:25 +0000
+Subject: riscv: fix reserved memory setup
+
+From: Conor Dooley <conor.dooley@microchip.com>
+
+[ Upstream commit 50e63dd8ed92045eb70a72d7ec725488320fb68b ]
+
+Currently, RISC-V sets up reserved memory using the "early" copy of the
+device tree. As a result, when trying to get a reserved memory region
+using of_reserved_mem_lookup(), the pointer to reserved memory regions
+is using the early, pre-virtual-memory address which causes a kernel
+panic when trying to use the buffer's name:
+
+ Unable to handle kernel paging request at virtual address 00000000401c31ac
+ Oops [#1]
+ Modules linked in:
+ CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1
+ Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
+ epc : string+0x4a/0xea
+  ra : vsnprintf+0x1e4/0x336
+ epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0
+  gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000
+  t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20
+  s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000
+  a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff
+  a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff
+  s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008
+  s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00
+  s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002
+  s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617
+  t5 : ffffffff812f3618 t6 : ffffffff81203d08
+ status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d
+ [<ffffffff80338936>] vsnprintf+0x1e4/0x336
+ [<ffffffff80055ae2>] vprintk_store+0xf6/0x344
+ [<ffffffff80055d86>] vprintk_emit+0x56/0x192
+ [<ffffffff80055ed8>] vprintk_default+0x16/0x1e
+ [<ffffffff800563d2>] vprintk+0x72/0x80
+ [<ffffffff806813b2>] _printk+0x36/0x50
+ [<ffffffff8068af48>] print_reserved_mem+0x1c/0x24
+ [<ffffffff808057ec>] paging_init+0x528/0x5bc
+ [<ffffffff808031ae>] setup_arch+0xd0/0x592
+ [<ffffffff8080070e>] start_kernel+0x82/0x73c
+
+early_init_fdt_scan_reserved_mem() takes no arguments as it operates on
+initial_boot_params, which is populated by early_init_dt_verify(). On
+RISC-V, early_init_dt_verify() is called twice. Once, directly, in
+setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,
+very early in the boot process, by parse_dtb() when it calls
+early_init_dt_scan_nodes().
+
+This first call uses dtb_early_va to set initial_boot_params, which is
+not usable later in the boot process when
+early_init_fdt_scan_reserved_mem() is called. On arm64 for example, the
+corresponding call to early_init_dt_scan_nodes() uses fixmap addresses
+and doesn't suffer the same fate.
+
+Move early_init_fdt_scan_reserved_mem() further along the boot sequence,
+after the direct call to early_init_dt_verify() in setup_arch() so that
+the names use the correct virtual memory addresses. The above supposed
+that CONFIG_BUILTIN_DTB was not set, but should work equally in the case
+where it is - unflatted_and_copy_device_tree() also updates
+initial_boot_params.
+
+Reported-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
+Reported-by: Evgenii Shatokhin <e.shatokhin@yadro.com>
+Link: https://lore.kernel.org/linux-riscv/f8e67f82-103d-156c-deb0-d6d6e2756f5e@microchip.com/
+Fixes: 922b0375fc93 ("riscv: Fix memblock reservation for device tree blob")
+Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
+Tested-by: Evgenii Shatokhin <e.shatokhin@yadro.com>
+Link: https://lore.kernel.org/r/20221107151524.3941467-1-conor.dooley@microchip.com
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/kernel/setup.c | 1 +
+ arch/riscv/mm/init.c      | 1 -
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
+index 57e1ab036edf..8e78a8ab6a34 100644
+--- a/arch/riscv/kernel/setup.c
++++ b/arch/riscv/kernel/setup.c
+@@ -96,6 +96,7 @@ void __init setup_arch(char **cmdline_p)
+       else
+               pr_err("No DTB found in kernel mappings\n");
+ #endif
++      early_init_fdt_scan_reserved_mem();
+       misc_mem_init();
+ #ifdef CONFIG_SWIOTLB
+diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
+index b6ab6a18dc1a..6c2f38aac544 100644
+--- a/arch/riscv/mm/init.c
++++ b/arch/riscv/mm/init.c
+@@ -208,7 +208,6 @@ void __init setup_bootmem(void)
+        */
+       memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va));
+-      early_init_fdt_scan_reserved_mem();
+       dma_contiguous_reserve(dma32_phys_limit);
+       memblock_allow_resize();
+       memblock_dump_all();
+-- 
+2.35.1
+
diff --git a/queue-5.10/riscv-process-fix-kernel-info-leakage.patch b/queue-5.10/riscv-process-fix-kernel-info-leakage.patch
new file mode 100644 (file)
index 0000000..c561398
--- /dev/null
@@ -0,0 +1,43 @@
+From 6a37947afb02d0e3c3e48a530e86f71388f6c4db Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 29 Oct 2022 19:34:50 +0800
+Subject: riscv: process: fix kernel info leakage
+
+From: Jisheng Zhang <jszhang@kernel.org>
+
+[ Upstream commit 6510c78490c490a6636e48b61eeaa6fb65981f4b ]
+
+thread_struct's s[12] may contain random kernel memory content, which
+may be finally leaked to userspace. This is a security hole. Fix it
+by clearing the s[12] array in thread_struct when fork.
+
+As for kthread case, it's better to clear the s[12] array as well.
+
+Fixes: 7db91e57a0ac ("RISC-V: Task implementation")
+Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
+Tested-by: Guo Ren <guoren@kernel.org>
+Link: https://lore.kernel.org/r/20221029113450.4027-1-jszhang@kernel.org
+Reviewed-by: Guo Ren <guoren@kernel.org>
+Link: https://lore.kernel.org/r/CAJF2gTSdVyAaM12T%2B7kXAdRPGS4VyuO08X1c7paE-n4Fr8OtRA@mail.gmail.com/
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/kernel/process.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
+index dd5f985b1f40..9a8b2e60adcf 100644
+--- a/arch/riscv/kernel/process.c
++++ b/arch/riscv/kernel/process.c
+@@ -111,6 +111,8 @@ int copy_thread(unsigned long clone_flags, unsigned long usp, unsigned long arg,
+ {
+       struct pt_regs *childregs = task_pt_regs(p);
++      memset(&p->thread.s, 0, sizeof(p->thread.s));
++
+       /* p->thread holds context to be restored by __switch_to() */
+       if (unlikely(p->flags & PF_KTHREAD)) {
+               /* Kernel thread */
+-- 
+2.35.1
+
diff --git a/queue-5.10/riscv-separate-memory-init-from-paging-init.patch b/queue-5.10/riscv-separate-memory-init-from-paging-init.patch
new file mode 100644 (file)
index 0000000..3443db0
--- /dev/null
@@ -0,0 +1,74 @@
+From e61fe7f4ba423e36ed148af04acebc8d2b495dad Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Nov 2020 16:38:27 -0800
+Subject: riscv: Separate memory init from paging init
+
+From: Atish Patra <atish.patra@wdc.com>
+
+[ Upstream commit cbd34f4bb37d62d8a027f54205bff07e73340da4 ]
+
+Currently, we perform some memory init functions in paging init. But,
+that will be an issue for NUMA support where DT needs to be flattened
+before numa initialization and memblock_present can only be called
+after numa initialization.
+
+Move memory initialization related functions to a separate function.
+
+Signed-off-by: Atish Patra <atish.patra@wdc.com>
+Reviewed-by: Greentime Hu <greentime.hu@sifive.com>
+Reviewed-by: Anup Patel <anup@brainfault.org>
+Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
+Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
+Stable-dep-of: 50e63dd8ed92 ("riscv: fix reserved memory setup")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/include/asm/pgtable.h | 1 +
+ arch/riscv/kernel/setup.c        | 1 +
+ arch/riscv/mm/init.c             | 6 +++++-
+ 3 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
+index 73e8b5e5bb65..b16304fdf448 100644
+--- a/arch/riscv/include/asm/pgtable.h
++++ b/arch/riscv/include/asm/pgtable.h
+@@ -470,6 +470,7 @@ extern void *dtb_early_va;
+ extern uintptr_t dtb_early_pa;
+ void setup_bootmem(void);
+ void paging_init(void);
++void misc_mem_init(void);
+ #define FIRST_USER_ADDRESS  0
+diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
+index cc85858f7fe8..57e1ab036edf 100644
+--- a/arch/riscv/kernel/setup.c
++++ b/arch/riscv/kernel/setup.c
+@@ -96,6 +96,7 @@ void __init setup_arch(char **cmdline_p)
+       else
+               pr_err("No DTB found in kernel mappings\n");
+ #endif
++      misc_mem_init();
+ #ifdef CONFIG_SWIOTLB
+       swiotlb_init(1);
+diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
+index 56314e82f051..b6ab6a18dc1a 100644
+--- a/arch/riscv/mm/init.c
++++ b/arch/riscv/mm/init.c
+@@ -669,8 +669,12 @@ static void __init resource_init(void)
+ void __init paging_init(void)
+ {
+       setup_vm_final();
+-      sparse_init();
+       setup_zero_page();
++}
++
++void __init misc_mem_init(void)
++{
++      sparse_init();
+       zone_sizes_init();
+       resource_init();
+ }
+-- 
+2.35.1
+
diff --git a/queue-5.10/riscv-vdso-fix-build-with-llvm.patch b/queue-5.10/riscv-vdso-fix-build-with-llvm.patch
new file mode 100644 (file)
index 0000000..b999798
--- /dev/null
@@ -0,0 +1,66 @@
+From 89f8391c53f64c942f5ca89fd94eec7841f1d362 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 02:29:43 +0800
+Subject: riscv: vdso: fix build with llvm
+
+From: Jisheng Zhang <jszhang@kernel.org>
+
+[ Upstream commit 50f4dd657a0fcf90aa8da8dc2794a8100ff4c37c ]
+
+Even after commit 89fd4a1df829 ("riscv: jump_label: mark arguments as
+const to satisfy asm constraints"), building with CC_OPTIMIZE_FOR_SIZE
++ LLVM=1 can reproduce below build error:
+
+  CC      arch/riscv/kernel/vdso/vgettimeofday.o
+In file included from <built-in>:4:
+In file included from lib/vdso/gettimeofday.c:5:
+In file included from include/vdso/datapage.h:17:
+In file included from include/vdso/processor.h:10:
+In file included from arch/riscv/include/asm/vdso/processor.h:7:
+In file included from include/linux/jump_label.h:112:
+arch/riscv/include/asm/jump_label.h:42:3: error:
+invalid operand for inline asm constraint 'i'
+                "       .option push                            \n\t"
+                ^
+1 error generated.
+
+I think the problem is when "-Os" is passed as CFLAGS, it's removed by
+"CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os" which is
+introduced in commit e05d57dcb8c7 ("riscv: Fixup __vdso_gettimeofday
+broke dynamic ftrace"), thus no optimization at all for vgettimeofday.c
+arm64 does remove "-Os" as well, but it forces "-O2" after removing
+"-Os".
+
+I compared the generated vgettimeofday.o with "-O2" and "-Os",
+I think no big performance difference. So let's tell the kbuild not
+to remove "-Os" rather than follow arm64 style.
+
+vdso related performance can be improved a lot when building kernel with
+CC_OPTIMIZE_FOR_SIZE after this commit, ("-Os" VS no optimization)
+
+Fixes: e05d57dcb8c7 ("riscv: Fixup __vdso_gettimeofday broke dynamic ftrace")
+Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
+Tested-by: Conor Dooley <conor.dooley@microchip.com>
+Link: https://lore.kernel.org/r/20221031182943.2453-1-jszhang@kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/kernel/vdso/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
+index 24d936c147cd..926ab3960f9e 100644
+--- a/arch/riscv/kernel/vdso/Makefile
++++ b/arch/riscv/kernel/vdso/Makefile
+@@ -30,7 +30,7 @@ obj-y += vdso.o vdso-syms.o
+ CPPFLAGS_vdso.lds += -P -C -U$(ARCH)
+ # Disable -pg to prevent insert call site
+-CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os
++CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE)
+ # Disable profiling and instrumentation for VDSO code
+ GCOV_PROFILE := n
+-- 
+2.35.1
+
index c3dfaf8a9c138b479743cbc04202a8c15be063e0..c2bbf93018ce7206f22bf482b22bccde64f4769f 100644 (file)
@@ -1 +1,54 @@
 fuse-fix-readdir-cache-race.patch
+hwspinlock-qcom-correct-mmio-max-register-for-newer-.patch
+phy-stm32-fix-an-error-code-in-probe.patch
+wifi-cfg80211-silence-a-sparse-rcu-warning.patch
+wifi-cfg80211-fix-memory-leak-in-query_regdb_file.patch
+bpf-sockmap-fix-the-sk-sk_forward_alloc-warning-of-s.patch
+bpftool-fix-null-pointer-dereference-when-pin-prog-m.patch
+hid-hyperv-fix-possible-memory-leak-in-mousevsc_prob.patch
+bpf-support-for-pointers-beyond-pkt_end.patch
+bpf-add-helper-macro-bpf_for_each_reg_in_vstate.patch
+bpf-fix-wrong-reg-type-conversion-in-release_referen.patch
+net-gso-fix-panic-on-frag_list-with-mixed-head-alloc.patch
+macsec-delete-new-rxsc-when-offload-fails.patch
+macsec-fix-secy-n_rx_sc-accounting.patch
+macsec-fix-detection-of-rxscs-when-toggling-offloadi.patch
+macsec-clear-encryption-keys-from-the-stack-after-se.patch
+net-tun-fix-memory-leaks-of-napi_get_frags.patch
+bnxt_en-fix-possible-crash-in-bnxt_hwrm_set_coal.patch
+bnxt_en-fix-potentially-incorrect-return-value-for-n.patch
+net-fman-unregister-ethernet-device-on-removal.patch
+capabilities-fix-undefined-behavior-in-bit-shift-for.patch
+kvm-s390x-fix-sck-locking.patch
+kvm-s390-pv-don-t-allow-userspace-to-set-the-clock-u.patch
+net-lapbether-fix-issue-of-dev-reference-count-leaka.patch
+hamradio-fix-issue-of-dev-reference-count-leakage-in.patch
+drm-vc4-fix-missing-platform_unregister_drivers-call.patch
+tcp-prohibit-tcp_repair_options-if-data-was-already-.patch
+ipv6-addrlabel-fix-infoleak-when-sending-struct-ifad.patch
+can-af_can-fix-null-pointer-dereference-in-can_rx_re.patch
+net-stmmac-dwmac-meson8b-fix-meson8b_devm_clk_prepar.patch
+net-broadcom-fix-bcmgenet-kconfig.patch
+tipc-fix-the-msg-req-tlv-len-check-in-tipc_nl_compat.patch
+dmaengine-pxa_dma-use-platform_get_irq_optional.patch
+dmaengine-mv_xor_v2-fix-a-resource-leak-in-mv_xor_v2.patch
+drivers-net-xgene-disable-napi-when-register-irq-fai.patch
+perf-stat-fix-printing-os-prefix-in-csv-metrics-outp.patch
+net-marvell-prestera-fix-memory-leak-in-prestera_rxt.patch
+net-nixge-disable-napi-when-enable-interrupts-failed.patch
+net-mlx5-allow-async-trigger-completion-execution-on.patch
+net-mlx5e-e-switch-fix-comparing-termination-table-i.patch
+net-cpsw-disable-napi-in-cpsw_ndo_open.patch
+net-cxgb3_main-disable-napi-when-bind-qsets-failed-i.patch
+cxgb4vf-shut-down-the-adapter-when-t4vf_update_port_.patch
+net-phy-mscc-macsec-clear-encryption-keys-when-freei.patch
+net-atlantic-macsec-clear-encryption-keys-from-the-s.patch
+ethernet-s2io-disable-napi-when-start-nic-failed-in-.patch
+net-mv643xx_eth-disable-napi-when-init-rxq-or-txq-fa.patch
+ethernet-tundra-free-irq-when-alloc-ring-failed-in-t.patch
+net-macvlan-fix-memory-leaks-of-macvlan_common_newli.patch
+riscv-process-fix-kernel-info-leakage.patch
+riscv-vdso-fix-build-with-llvm.patch
+riscv-enable-cma-support.patch
+riscv-separate-memory-init-from-paging-init.patch
+riscv-fix-reserved-memory-setup.patch
diff --git a/queue-5.10/tcp-prohibit-tcp_repair_options-if-data-was-already-.patch b/queue-5.10/tcp-prohibit-tcp_repair_options-if-data-was-already-.patch
new file mode 100644 (file)
index 0000000..f7f92ac
--- /dev/null
@@ -0,0 +1,78 @@
+From 0e8f1c6c3fd2ec8fc30ced8c6ae31bc2a690893d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Nov 2022 10:27:23 +0800
+Subject: tcp: prohibit TCP_REPAIR_OPTIONS if data was already sent
+
+From: Lu Wei <luwei32@huawei.com>
+
+[ Upstream commit 0c175da7b0378445f5ef53904247cfbfb87e0b78 ]
+
+If setsockopt with option name of TCP_REPAIR_OPTIONS and opt_code
+of TCPOPT_SACK_PERM is called to enable sack after data is sent
+and dupacks are received , it will trigger a warning in function
+tcp_verify_left_out() as follows:
+
+============================================
+WARNING: CPU: 8 PID: 0 at net/ipv4/tcp_input.c:2132
+tcp_timeout_mark_lost+0x154/0x160
+tcp_enter_loss+0x2b/0x290
+tcp_retransmit_timer+0x50b/0x640
+tcp_write_timer_handler+0x1c8/0x340
+tcp_write_timer+0xe5/0x140
+call_timer_fn+0x3a/0x1b0
+__run_timers.part.0+0x1bf/0x2d0
+run_timer_softirq+0x43/0xb0
+__do_softirq+0xfd/0x373
+__irq_exit_rcu+0xf6/0x140
+
+The warning is caused in the following steps:
+1. a socket named socketA is created
+2. socketA enters repair mode without build a connection
+3. socketA calls connect() and its state is changed to TCP_ESTABLISHED
+   directly
+4. socketA leaves repair mode
+5. socketA calls sendmsg() to send data, packets_out and sack_outs(dup
+   ack receives) increase
+6. socketA enters repair mode again
+7. socketA calls setsockopt with TCPOPT_SACK_PERM to enable sack
+8. retransmit timer expires, it calls tcp_timeout_mark_lost(), lost_out
+   increases
+9. sack_outs + lost_out > packets_out triggers since lost_out and
+   sack_outs increase repeatly
+
+In function tcp_timeout_mark_lost(), tp->sacked_out will be cleared if
+Step7 not happen and the warning will not be triggered. As suggested by
+Denis and Eric, TCP_REPAIR_OPTIONS should be prohibited if data was
+already sent.
+
+socket-tcp tests in CRIU has been tested as follows:
+$ sudo ./test/zdtm.py run -t zdtm/static/socket-tcp*  --keep-going \
+       --ignore-taint
+
+socket-tcp* represent all socket-tcp tests in test/zdtm/static/.
+
+Fixes: b139ba4e90dc ("tcp: Repair connection-time negotiated parameters")
+Signed-off-by: Lu Wei <luwei32@huawei.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/ipv4/tcp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
+index a7127364253c..cc588bc2b11d 100644
+--- a/net/ipv4/tcp.c
++++ b/net/ipv4/tcp.c
+@@ -3291,7 +3291,7 @@ static int do_tcp_setsockopt(struct sock *sk, int level, int optname,
+       case TCP_REPAIR_OPTIONS:
+               if (!tp->repair)
+                       err = -EINVAL;
+-              else if (sk->sk_state == TCP_ESTABLISHED)
++              else if (sk->sk_state == TCP_ESTABLISHED && !tp->bytes_sent)
+                       err = tcp_repair_options_est(sk, optval, optlen);
+               else
+                       err = -EPERM;
+-- 
+2.35.1
+
diff --git a/queue-5.10/tipc-fix-the-msg-req-tlv-len-check-in-tipc_nl_compat.patch b/queue-5.10/tipc-fix-the-msg-req-tlv-len-check-in-tipc_nl_compat.patch
new file mode 100644 (file)
index 0000000..691493b
--- /dev/null
@@ -0,0 +1,59 @@
+From e926cf8c09ab49b12e9a47e0a3a44fa6f18e9638 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Nov 2022 16:48:53 -0400
+Subject: tipc: fix the msg->req tlv len check in
+ tipc_nl_compat_name_table_dump_header
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit 1c075b192fe41030457cd4a5f7dea730412bca40 ]
+
+This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value
+in tipc_nl_compat_name_table_dump") where it should have type casted
+sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative
+value.
+
+syzbot reported a call trace because of it:
+
+  BUG: KMSAN: uninit-value in ...
+   tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934
+   __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238
+   tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321
+   tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324
+   genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
+   genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
+   genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792
+   netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501
+   genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803
+   netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
+   netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
+   netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
+   sock_sendmsg_nosec net/socket.c:714 [inline]
+   sock_sendmsg net/socket.c:734 [inline]
+
+Reported-by: syzbot+e5dbaaa238680ce206ea@syzkaller.appspotmail.com
+Fixes: 974cb0e3e7c9 ("tipc: fix uninit-value in tipc_nl_compat_name_table_dump")
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Link: https://lore.kernel.org/r/ccd6a7ea801b15aec092c3b532a883b4c5708695.1667594933.git.lucien.xin@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/tipc/netlink_compat.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
+index 49e893313652..2d62932b5987 100644
+--- a/net/tipc/netlink_compat.c
++++ b/net/tipc/netlink_compat.c
+@@ -877,7 +877,7 @@ static int tipc_nl_compat_name_table_dump_header(struct tipc_nl_compat_msg *msg)
+       };
+       ntq = (struct tipc_name_table_query *)TLV_DATA(msg->req);
+-      if (TLV_GET_DATA_LEN(msg->req) < sizeof(struct tipc_name_table_query))
++      if (TLV_GET_DATA_LEN(msg->req) < (int)sizeof(struct tipc_name_table_query))
+               return -EINVAL;
+       depth = ntohl(ntq->depth);
+-- 
+2.35.1
+
diff --git a/queue-5.10/wifi-cfg80211-fix-memory-leak-in-query_regdb_file.patch b/queue-5.10/wifi-cfg80211-fix-memory-leak-in-query_regdb_file.patch
new file mode 100644 (file)
index 0000000..5c17a4b
--- /dev/null
@@ -0,0 +1,55 @@
+From 5b15baa2de87bcc4405e03ceae4818e9029dade0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Oct 2022 13:40:40 +0200
+Subject: wifi: cfg80211: fix memory leak in query_regdb_file()
+
+From: Arend van Spriel <arend.vanspriel@broadcom.com>
+
+[ Upstream commit 57b962e627ec0ae53d4d16d7bd1033e27e67677a ]
+
+In the function query_regdb_file() the alpha2 parameter is duplicated
+using kmemdup() and subsequently freed in regdb_fw_cb(). However,
+request_firmware_nowait() can fail without calling regdb_fw_cb() and
+thus leak memory.
+
+Fixes: 007f6c5e6eb4 ("cfg80211: support loading regulatory database as firmware file")
+Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/wireless/reg.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/net/wireless/reg.c b/net/wireless/reg.c
+index fd848609e656..a1e64d967bd3 100644
+--- a/net/wireless/reg.c
++++ b/net/wireless/reg.c
+@@ -1064,6 +1064,8 @@ MODULE_FIRMWARE("regulatory.db");
+ static int query_regdb_file(const char *alpha2)
+ {
++      int err;
++
+       ASSERT_RTNL();
+       if (regdb)
+@@ -1073,9 +1075,13 @@ static int query_regdb_file(const char *alpha2)
+       if (!alpha2)
+               return -ENOMEM;
+-      return request_firmware_nowait(THIS_MODULE, true, "regulatory.db",
+-                                     &reg_pdev->dev, GFP_KERNEL,
+-                                     (void *)alpha2, regdb_fw_cb);
++      err = request_firmware_nowait(THIS_MODULE, true, "regulatory.db",
++                                    &reg_pdev->dev, GFP_KERNEL,
++                                    (void *)alpha2, regdb_fw_cb);
++      if (err)
++              kfree(alpha2);
++
++      return err;
+ }
+ int reg_reload_regdb(void)
+-- 
+2.35.1
+
diff --git a/queue-5.10/wifi-cfg80211-silence-a-sparse-rcu-warning.patch b/queue-5.10/wifi-cfg80211-silence-a-sparse-rcu-warning.patch
new file mode 100644 (file)
index 0000000..03318fa
--- /dev/null
@@ -0,0 +1,38 @@
+From 811c3c0940d2993e88a97433cfc631c3165149bb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 13 Oct 2022 19:41:51 +0200
+Subject: wifi: cfg80211: silence a sparse RCU warning
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+[ Upstream commit 03c0ad4b06c3566de624b4f4b78ac1a5d1e4c8e7 ]
+
+All we're going to do with this pointer is assign it to
+another __rcu pointer, but sparse can't see that, so
+use rcu_access_pointer() to silence the warning here.
+
+Fixes: c90b93b5b782 ("wifi: cfg80211: update hidden BSSes to avoid WARN_ON")
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/wireless/scan.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/wireless/scan.c b/net/wireless/scan.c
+index 22d169923261..15119c49c093 100644
+--- a/net/wireless/scan.c
++++ b/net/wireless/scan.c
+@@ -1669,7 +1669,9 @@ cfg80211_update_known_bss(struct cfg80211_registered_device *rdev,
+               if (old == rcu_access_pointer(known->pub.ies))
+                       rcu_assign_pointer(known->pub.ies, new->pub.beacon_ies);
+-              cfg80211_update_hidden_bsses(known, new->pub.beacon_ies, old);
++              cfg80211_update_hidden_bsses(known,
++                                           rcu_access_pointer(new->pub.beacon_ies),
++                                           old);
+               if (old)
+                       kfree_rcu((struct cfg80211_bss_ies *)old, rcu_head);
+-- 
+2.35.1
+