--- /dev/null
+From ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 Mon Sep 17 00:00:00 2001
+From: Antoine Tenart <atenart@kernel.org>
+Date: Tue, 26 Mar 2024 12:33:59 +0100
+Subject: gro: fix ownership transfer
+
+From: Antoine Tenart <atenart@kernel.org>
+
+commit ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 upstream.
+
+If packets are GROed with fraglist they might be segmented later on and
+continue their journey in the stack. In skb_segment_list those skbs can
+be reused as-is. This is an issue as their destructor was removed in
+skb_gro_receive_list but not the reference to their socket, and then
+they can't be orphaned. Fix this by also removing the reference to the
+socket.
+
+For example this could be observed,
+
+ kernel BUG at include/linux/skbuff.h:3131! (skb_orphan)
+ RIP: 0010:ip6_rcv_core+0x11bc/0x19a0
+ Call Trace:
+ ipv6_list_rcv+0x250/0x3f0
+ __netif_receive_skb_list_core+0x49d/0x8f0
+ netif_receive_skb_list_internal+0x634/0xd40
+ napi_complete_done+0x1d2/0x7d0
+ gro_cell_poll+0x118/0x1f0
+
+A similar construction is found in skb_gro_receive, apply the same
+change there.
+
+Fixes: 5e10da5385d2 ("skbuff: allow 'slow_gro' for skb carring sock reference")
+Signed-off-by: Antoine Tenart <atenart@kernel.org>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/gro.c | 3 ++-
+ net/ipv4/udp_offload.c | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/net/core/gro.c
++++ b/net/core/gro.c
+@@ -252,8 +252,9 @@ int skb_gro_receive(struct sk_buff *p, s
+ }
+
+ merge:
+- /* sk owenrship - if any - completely transferred to the aggregated packet */
++ /* sk ownership - if any - completely transferred to the aggregated packet */
+ skb->destructor = NULL;
++ skb->sk = NULL;
+ delta_truesize = skb->truesize;
+ if (offset > headlen) {
+ unsigned int eat = offset - headlen;
+--- a/net/ipv4/udp_offload.c
++++ b/net/ipv4/udp_offload.c
+@@ -441,8 +441,9 @@ static int skb_gro_receive_list(struct s
+ NAPI_GRO_CB(p)->count++;
+ p->data_len += skb->len;
+
+- /* sk owenrship - if any - completely transferred to the aggregated packet */
++ /* sk ownership - if any - completely transferred to the aggregated packet */
+ skb->destructor = NULL;
++ skb->sk = NULL;
+ p->truesize += skb->truesize;
+ p->len += skb->len;
+
--- /dev/null
+From 96c155943a703f0655c0c4cab540f67055960e91 Mon Sep 17 00:00:00 2001
+From: Aleksandr Mishin <amishin@t-argos.ru>
+Date: Fri, 29 Mar 2024 09:16:31 +0300
+Subject: net: phy: micrel: Fix potential null pointer dereference
+
+From: Aleksandr Mishin <amishin@t-argos.ru>
+
+commit 96c155943a703f0655c0c4cab540f67055960e91 upstream.
+
+In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may
+return NULL as ptp_header due to abnormal packet type or corrupted packet.
+Fix this bug by adding ptp_header check.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy")
+Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://lore.kernel.org/r/20240329061631.33199-1-amishin@t-argos.ru
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/phy/micrel.c | 21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/phy/micrel.c
++++ b/drivers/net/phy/micrel.c
+@@ -2303,7 +2303,7 @@ static void lan8814_txtstamp(struct mii_
+ }
+ }
+
+-static void lan8814_get_sig_rx(struct sk_buff *skb, u16 *sig)
++static bool lan8814_get_sig_rx(struct sk_buff *skb, u16 *sig)
+ {
+ struct ptp_header *ptp_header;
+ u32 type;
+@@ -2313,7 +2313,11 @@ static void lan8814_get_sig_rx(struct sk
+ ptp_header = ptp_parse_header(skb, type);
+ skb_pull_inline(skb, ETH_HLEN);
+
++ if (!ptp_header)
++ return false;
++
+ *sig = (__force u16)(ntohs(ptp_header->sequence_id));
++ return true;
+ }
+
+ static bool lan8814_match_rx_ts(struct kszphy_ptp_priv *ptp_priv,
+@@ -2325,7 +2329,8 @@ static bool lan8814_match_rx_ts(struct k
+ bool ret = false;
+ u16 skb_sig;
+
+- lan8814_get_sig_rx(skb, &skb_sig);
++ if (!lan8814_get_sig_rx(skb, &skb_sig))
++ return ret;
+
+ /* Iterate over all RX timestamps and match it with the received skbs */
+ spin_lock_irqsave(&ptp_priv->rx_ts_lock, flags);
+@@ -2605,7 +2610,7 @@ static int lan8814_ptpci_adjfine(struct
+ return 0;
+ }
+
+-static void lan8814_get_sig_tx(struct sk_buff *skb, u16 *sig)
++static bool lan8814_get_sig_tx(struct sk_buff *skb, u16 *sig)
+ {
+ struct ptp_header *ptp_header;
+ u32 type;
+@@ -2613,7 +2618,11 @@ static void lan8814_get_sig_tx(struct sk
+ type = ptp_classify_raw(skb);
+ ptp_header = ptp_parse_header(skb, type);
+
++ if (!ptp_header)
++ return false;
++
+ *sig = (__force u16)(ntohs(ptp_header->sequence_id));
++ return true;
+ }
+
+ static void lan8814_dequeue_tx_skb(struct kszphy_ptp_priv *ptp_priv)
+@@ -2631,7 +2640,8 @@ static void lan8814_dequeue_tx_skb(struc
+
+ spin_lock_irqsave(&ptp_priv->tx_queue.lock, flags);
+ skb_queue_walk_safe(&ptp_priv->tx_queue, skb, skb_tmp) {
+- lan8814_get_sig_tx(skb, &skb_sig);
++ if (!lan8814_get_sig_tx(skb, &skb_sig))
++ continue;
+
+ if (memcmp(&skb_sig, &seq_id, sizeof(seq_id)))
+ continue;
+@@ -2675,7 +2685,8 @@ static bool lan8814_match_skb(struct ksz
+
+ spin_lock_irqsave(&ptp_priv->rx_queue.lock, flags);
+ skb_queue_walk_safe(&ptp_priv->rx_queue, skb, skb_tmp) {
+- lan8814_get_sig_rx(skb, &skb_sig);
++ if (!lan8814_get_sig_rx(skb, &skb_sig))
++ continue;
+
+ if (memcmp(&skb_sig, &rx_ts->seq_id, sizeof(rx_ts->seq_id)))
+ continue;
--- /dev/null
+From de99e1ea3a35f23ff83a31d6b08f43d27b2c6345 Mon Sep 17 00:00:00 2001
+From: Horatiu Vultur <horatiu.vultur@microchip.com>
+Date: Tue, 2 Apr 2024 09:16:34 +0200
+Subject: net: phy: micrel: lan8814: Fix when enabling/disabling 1-step timestamping
+
+From: Horatiu Vultur <horatiu.vultur@microchip.com>
+
+commit de99e1ea3a35f23ff83a31d6b08f43d27b2c6345 upstream.
+
+There are 2 issues with the blamed commit.
+1. When the phy is initialized, it would enable the disabled of UDPv4
+ checksums. The UDPv6 checksum is already enabled by default. So when
+ 1-step is configured then it would clear these flags.
+2. After the 1-step is configured, then if 2-step is configured then the
+ 1-step would be still configured because it is not clearing the flag.
+ So the sync frames will still have origin timestamps set.
+
+Fix this by reading first the value of the register and then
+just change bit 12 as this one determines if the timestamp needs to
+be inserted in the frame, without changing any other bits.
+
+Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy")
+Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
+Reviewed-by: Divya Koppera <divya.koppera@microchip.com>
+Link: https://lore.kernel.org/r/20240402071634.2483524-1-horatiu.vultur@microchip.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/phy/micrel.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/phy/micrel.c
++++ b/drivers/net/phy/micrel.c
+@@ -2188,6 +2188,7 @@ static int lan8814_hwtstamp(struct mii_t
+ struct hwtstamp_config config;
+ int txcfg = 0, rxcfg = 0;
+ int pkt_ts_enable;
++ int tx_mod;
+
+ if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
+ return -EFAULT;
+@@ -2237,9 +2238,14 @@ static int lan8814_hwtstamp(struct mii_t
+ lanphy_write_page_reg(ptp_priv->phydev, 5, PTP_RX_TIMESTAMP_EN, pkt_ts_enable);
+ lanphy_write_page_reg(ptp_priv->phydev, 5, PTP_TX_TIMESTAMP_EN, pkt_ts_enable);
+
+- if (ptp_priv->hwts_tx_type == HWTSTAMP_TX_ONESTEP_SYNC)
++ tx_mod = lanphy_read_page_reg(ptp_priv->phydev, 5, PTP_TX_MOD);
++ if (ptp_priv->hwts_tx_type == HWTSTAMP_TX_ONESTEP_SYNC) {
+ lanphy_write_page_reg(ptp_priv->phydev, 5, PTP_TX_MOD,
+- PTP_TX_MOD_TX_PTP_SYNC_TS_INSERT_);
++ tx_mod | PTP_TX_MOD_TX_PTP_SYNC_TS_INSERT_);
++ } else if (ptp_priv->hwts_tx_type == HWTSTAMP_TX_ON) {
++ lanphy_write_page_reg(ptp_priv->phydev, 5, PTP_TX_MOD,
++ tx_mod & ~PTP_TX_MOD_TX_PTP_SYNC_TS_INSERT_);
++ }
+
+ if (config.rx_filter != HWTSTAMP_FILTER_NONE)
+ lan8814_config_ts_intr(ptp_priv->phydev, true);
--- /dev/null
+From d313eb8b77557a6d5855f42d2234bd592c7b50dd Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Wed, 3 Apr 2024 13:09:08 +0000
+Subject: net/sched: act_skbmod: prevent kernel-infoleak
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit d313eb8b77557a6d5855f42d2234bd592c7b50dd upstream.
+
+syzbot found that tcf_skbmod_dump() was copying four bytes
+from kernel stack to user space [1].
+
+The issue here is that 'struct tc_skbmod' has a four bytes hole.
+
+We need to clear the structure before filling fields.
+
+[1]
+BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
+ BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
+ BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
+ BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
+ BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
+ BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
+ instrument_copy_to_user include/linux/instrumented.h:114 [inline]
+ copy_to_user_iter lib/iov_iter.c:24 [inline]
+ iterate_ubuf include/linux/iov_iter.h:29 [inline]
+ iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
+ iterate_and_advance include/linux/iov_iter.h:271 [inline]
+ _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
+ copy_to_iter include/linux/uio.h:196 [inline]
+ simple_copy_to_iter net/core/datagram.c:532 [inline]
+ __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
+ skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
+ skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
+ netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
+ sock_recvmsg_nosec net/socket.c:1046 [inline]
+ sock_recvmsg+0x2c4/0x340 net/socket.c:1068
+ __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
+ __do_sys_recvfrom net/socket.c:2260 [inline]
+ __se_sys_recvfrom net/socket.c:2256 [inline]
+ __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
+ do_syscall_64+0xd5/0x1f0
+ entry_SYSCALL_64_after_hwframe+0x6d/0x75
+
+Uninit was stored to memory at:
+ pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
+ netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
+ netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
+ nlmsg_unicast include/net/netlink.h:1144 [inline]
+ nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
+ rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
+ rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
+ tcf_add_notify net/sched/act_api.c:2048 [inline]
+ tcf_action_add net/sched/act_api.c:2071 [inline]
+ tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
+ rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
+ netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
+ rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
+ netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
+ netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
+ netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
+ sock_sendmsg_nosec net/socket.c:730 [inline]
+ __sock_sendmsg+0x30f/0x380 net/socket.c:745
+ ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
+ ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
+ __sys_sendmsg net/socket.c:2667 [inline]
+ __do_sys_sendmsg net/socket.c:2676 [inline]
+ __se_sys_sendmsg net/socket.c:2674 [inline]
+ __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
+ do_syscall_64+0xd5/0x1f0
+ entry_SYSCALL_64_after_hwframe+0x6d/0x75
+
+Uninit was stored to memory at:
+ __nla_put lib/nlattr.c:1041 [inline]
+ nla_put+0x1c6/0x230 lib/nlattr.c:1099
+ tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
+ tcf_action_dump_old net/sched/act_api.c:1191 [inline]
+ tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
+ tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
+ tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
+ tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
+ tcf_add_notify net/sched/act_api.c:2042 [inline]
+ tcf_action_add net/sched/act_api.c:2071 [inline]
+ tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
+ rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
+ netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
+ rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
+ netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
+ netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
+ netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
+ sock_sendmsg_nosec net/socket.c:730 [inline]
+ __sock_sendmsg+0x30f/0x380 net/socket.c:745
+ ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
+ ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
+ __sys_sendmsg net/socket.c:2667 [inline]
+ __do_sys_sendmsg net/socket.c:2676 [inline]
+ __se_sys_sendmsg net/socket.c:2674 [inline]
+ __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
+ do_syscall_64+0xd5/0x1f0
+ entry_SYSCALL_64_after_hwframe+0x6d/0x75
+
+Local variable opt created at:
+ tcf_skbmod_dump+0x9d/0xc20 net/sched/act_skbmod.c:244
+ tcf_action_dump_old net/sched/act_api.c:1191 [inline]
+ tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
+
+Bytes 188-191 of 248 are uninitialized
+Memory access of size 248 starts at ffff888117697680
+Data copied to user address 00007ffe56d855f0
+
+Fixes: 86da71b57383 ("net_sched: Introduce skbmod action")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
+Link: https://lore.kernel.org/r/20240403130908.93421-1-edumazet@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/act_skbmod.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/net/sched/act_skbmod.c
++++ b/net/sched/act_skbmod.c
+@@ -239,13 +239,13 @@ static int tcf_skbmod_dump(struct sk_buf
+ struct tcf_skbmod *d = to_skbmod(a);
+ unsigned char *b = skb_tail_pointer(skb);
+ struct tcf_skbmod_params *p;
+- struct tc_skbmod opt = {
+- .index = d->tcf_index,
+- .refcnt = refcount_read(&d->tcf_refcnt) - ref,
+- .bindcnt = atomic_read(&d->tcf_bindcnt) - bind,
+- };
++ struct tc_skbmod opt;
+ struct tcf_t t;
+
++ memset(&opt, 0, sizeof(opt));
++ opt.index = d->tcf_index;
++ opt.refcnt = refcount_read(&d->tcf_refcnt) - ref,
++ opt.bindcnt = atomic_read(&d->tcf_bindcnt) - bind;
+ spin_lock_bh(&d->tcf_lock);
+ opt.action = d->tcf_action;
+ p = rcu_dereference_protected(d->skbmod_p,
--- /dev/null
+From 7eb322360b0266481e560d1807ee79e0cef5742b Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Tue, 2 Apr 2024 13:41:33 +0000
+Subject: net/sched: fix lockdep splat in qdisc_tree_reduce_backlog()
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit 7eb322360b0266481e560d1807ee79e0cef5742b upstream.
+
+qdisc_tree_reduce_backlog() is called with the qdisc lock held,
+not RTNL.
+
+We must use qdisc_lookup_rcu() instead of qdisc_lookup()
+
+syzbot reported:
+
+WARNING: suspicious RCU usage
+6.1.74-syzkaller #0 Not tainted
+-----------------------------
+net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!
+
+other info that might help us debug this:
+
+rcu_scheduler_active = 2, debug_locks = 1
+3 locks held by udevd/1142:
+ #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]
+ #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]
+ #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282
+ #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]
+ #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297
+ #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]
+ #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]
+ #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792
+
+stack backtrace:
+CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
+Call Trace:
+ <TASK>
+ [<ffffffff85b85f14>] __dump_stack lib/dump_stack.c:88 [inline]
+ [<ffffffff85b85f14>] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106
+ [<ffffffff85b86007>] dump_stack+0x15/0x1e lib/dump_stack.c:113
+ [<ffffffff81802299>] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592
+ [<ffffffff84f0054c>] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305
+ [<ffffffff84f037c3>] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811
+ [<ffffffff84f5b78c>] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51
+ [<ffffffff84fbcf63>] qdisc_enqueue include/net/sch_generic.h:833 [inline]
+ [<ffffffff84fbcf63>] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723
+ [<ffffffff84eecab9>] dequeue_skb net/sched/sch_generic.c:292 [inline]
+ [<ffffffff84eecab9>] qdisc_restart net/sched/sch_generic.c:397 [inline]
+ [<ffffffff84eecab9>] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415
+ [<ffffffff84d7aa96>] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125
+ [<ffffffff84d85d29>] net_tx_action+0x7c9/0x970 net/core/dev.c:5313
+ [<ffffffff85e002bd>] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616
+ [<ffffffff81568bca>] invoke_softirq kernel/softirq.c:447 [inline]
+ [<ffffffff81568bca>] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700
+ [<ffffffff81568ae9>] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712
+ [<ffffffff85b89f52>] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107
+ [<ffffffff85c00ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656
+
+Fixes: d636fc5dd692 ("net: sched: add rcu annotations around qdisc->qdisc_sleeping")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reviewed-by: Jiri Pirko <jiri@nvidia.com>
+Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
+Link: https://lore.kernel.org/r/20240402134133.2352776-1-edumazet@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/sch_api.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/sched/sch_api.c
++++ b/net/sched/sch_api.c
+@@ -806,7 +806,7 @@ void qdisc_tree_reduce_backlog(struct Qd
+ notify = !sch->q.qlen && !WARN_ON_ONCE(!n &&
+ !qdisc_is_offloaded);
+ /* TODO: perform the search on a per txq basis */
+- sch = qdisc_lookup(qdisc_dev(sch), TC_H_MAJ(parentid));
++ sch = qdisc_lookup_rcu(qdisc_dev(sch), TC_H_MAJ(parentid));
+ if (sch == NULL) {
+ WARN_ON_ONCE(parentid != TC_H_ROOT);
+ break;
--- /dev/null
+From b3da86d432b7cd65b025a11f68613e333d2483db Mon Sep 17 00:00:00 2001
+From: Piotr Wejman <piotrwejman90@gmail.com>
+Date: Mon, 1 Apr 2024 21:22:39 +0200
+Subject: net: stmmac: fix rx queue priority assignment
+
+From: Piotr Wejman <piotrwejman90@gmail.com>
+
+commit b3da86d432b7cd65b025a11f68613e333d2483db upstream.
+
+The driver should ensure that same priority is not mapped to multiple
+rx queues. From DesignWare Cores Ethernet Quality-of-Service
+Databook, section 17.1.29 MAC_RxQ_Ctrl2:
+"[...]The software must ensure that the content of this field is
+mutually exclusive to the PSRQ fields for other queues, that is,
+the same priority is not mapped to multiple Rx queues[...]"
+
+Previously rx_queue_priority() function was:
+- clearing all priorities from a queue
+- adding new priorities to that queue
+After this patch it will:
+- first assign new priorities to a queue
+- then remove those priorities from all other queues
+- keep other priorities previously assigned to that queue
+
+Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority configuration")
+Fixes: 2142754f8b9c ("net: stmmac: Add MAC related callbacks for XGMAC2")
+Signed-off-by: Piotr Wejman <piotrwejman90@gmail.com>
+Link: https://lore.kernel.org/r/20240401192239.33942-1-piotrwejman90@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 40 +++++++++++++++-----
+ drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 38 +++++++++++++++----
+ 2 files changed, 62 insertions(+), 16 deletions(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+@@ -87,19 +87,41 @@ static void dwmac4_rx_queue_priority(str
+ u32 prio, u32 queue)
+ {
+ void __iomem *ioaddr = hw->pcsr;
+- u32 base_register;
+- u32 value;
++ u32 clear_mask = 0;
++ u32 ctrl2, ctrl3;
++ int i;
+
+- base_register = (queue < 4) ? GMAC_RXQ_CTRL2 : GMAC_RXQ_CTRL3;
+- if (queue >= 4)
+- queue -= 4;
++ ctrl2 = readl(ioaddr + GMAC_RXQ_CTRL2);
++ ctrl3 = readl(ioaddr + GMAC_RXQ_CTRL3);
++
++ /* The software must ensure that the same priority
++ * is not mapped to multiple Rx queues
++ */
++ for (i = 0; i < 4; i++)
++ clear_mask |= ((prio << GMAC_RXQCTRL_PSRQX_SHIFT(i)) &
++ GMAC_RXQCTRL_PSRQX_MASK(i));
+
+- value = readl(ioaddr + base_register);
++ ctrl2 &= ~clear_mask;
++ ctrl3 &= ~clear_mask;
+
+- value &= ~GMAC_RXQCTRL_PSRQX_MASK(queue);
+- value |= (prio << GMAC_RXQCTRL_PSRQX_SHIFT(queue)) &
++ /* First assign new priorities to a queue, then
++ * clear them from others queues
++ */
++ if (queue < 4) {
++ ctrl2 |= (prio << GMAC_RXQCTRL_PSRQX_SHIFT(queue)) &
+ GMAC_RXQCTRL_PSRQX_MASK(queue);
+- writel(value, ioaddr + base_register);
++
++ writel(ctrl2, ioaddr + GMAC_RXQ_CTRL2);
++ writel(ctrl3, ioaddr + GMAC_RXQ_CTRL3);
++ } else {
++ queue -= 4;
++
++ ctrl3 |= (prio << GMAC_RXQCTRL_PSRQX_SHIFT(queue)) &
++ GMAC_RXQCTRL_PSRQX_MASK(queue);
++
++ writel(ctrl3, ioaddr + GMAC_RXQ_CTRL3);
++ writel(ctrl2, ioaddr + GMAC_RXQ_CTRL2);
++ }
+ }
+
+ static void dwmac4_tx_queue_priority(struct mac_device_info *hw,
+--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+@@ -97,17 +97,41 @@ static void dwxgmac2_rx_queue_prio(struc
+ u32 queue)
+ {
+ void __iomem *ioaddr = hw->pcsr;
+- u32 value, reg;
++ u32 clear_mask = 0;
++ u32 ctrl2, ctrl3;
++ int i;
+
+- reg = (queue < 4) ? XGMAC_RXQ_CTRL2 : XGMAC_RXQ_CTRL3;
+- if (queue >= 4)
++ ctrl2 = readl(ioaddr + XGMAC_RXQ_CTRL2);
++ ctrl3 = readl(ioaddr + XGMAC_RXQ_CTRL3);
++
++ /* The software must ensure that the same priority
++ * is not mapped to multiple Rx queues
++ */
++ for (i = 0; i < 4; i++)
++ clear_mask |= ((prio << XGMAC_PSRQ_SHIFT(i)) &
++ XGMAC_PSRQ(i));
++
++ ctrl2 &= ~clear_mask;
++ ctrl3 &= ~clear_mask;
++
++ /* First assign new priorities to a queue, then
++ * clear them from others queues
++ */
++ if (queue < 4) {
++ ctrl2 |= (prio << XGMAC_PSRQ_SHIFT(queue)) &
++ XGMAC_PSRQ(queue);
++
++ writel(ctrl2, ioaddr + XGMAC_RXQ_CTRL2);
++ writel(ctrl3, ioaddr + XGMAC_RXQ_CTRL3);
++ } else {
+ queue -= 4;
+
+- value = readl(ioaddr + reg);
+- value &= ~XGMAC_PSRQ(queue);
+- value |= (prio << XGMAC_PSRQ_SHIFT(queue)) & XGMAC_PSRQ(queue);
++ ctrl3 |= (prio << XGMAC_PSRQ_SHIFT(queue)) &
++ XGMAC_PSRQ(queue);
+
+- writel(value, ioaddr + reg);
++ writel(ctrl3, ioaddr + XGMAC_RXQ_CTRL3);
++ writel(ctrl2, ioaddr + XGMAC_RXQ_CTRL2);
++ }
+ }
+
+ static void dwxgmac2_tx_queue_prio(struct mac_device_info *hw, u32 prio,
--- /dev/null
+From 0fb101be97ca27850c5ecdbd1269423ce4d1f607 Mon Sep 17 00:00:00 2001
+From: Antoine Tenart <atenart@kernel.org>
+Date: Tue, 26 Mar 2024 12:34:02 +0100
+Subject: selftests: net: gro fwd: update vxlan GRO test expectations
+
+From: Antoine Tenart <atenart@kernel.org>
+
+commit 0fb101be97ca27850c5ecdbd1269423ce4d1f607 upstream.
+
+UDP tunnel packets can't be GRO in-between their endpoints as this
+causes different issues. The UDP GRO fwd vxlan tests were relying on
+this and their expectations have to be fixed.
+
+We keep both vxlan tests and expected no GRO from happening. The vxlan
+UDP GRO bench test was removed as it's not providing any valuable
+information now.
+
+Fixes: a062260a9d5f ("selftests: net: add UDP GRO forwarding self-tests")
+Signed-off-by: Antoine Tenart <atenart@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/udpgro_fwd.sh | 10 ++--------
+ 1 file changed, 2 insertions(+), 8 deletions(-)
+
+--- a/tools/testing/selftests/net/udpgro_fwd.sh
++++ b/tools/testing/selftests/net/udpgro_fwd.sh
+@@ -239,7 +239,7 @@ for family in 4 6; do
+
+ create_vxlan_pair
+ ip netns exec $NS_DST ethtool -K veth$DST rx-gro-list on
+- run_test "GRO frag list over UDP tunnel" $OL_NET$DST 1 1
++ run_test "GRO frag list over UDP tunnel" $OL_NET$DST 10 10
+ cleanup
+
+ # use NAT to circumvent GRO FWD check
+@@ -252,13 +252,7 @@ for family in 4 6; do
+ # load arp cache before running the test to reduce the amount of
+ # stray traffic on top of the UDP tunnel
+ ip netns exec $NS_SRC $PING -q -c 1 $OL_NET$DST_NAT >/dev/null
+- run_test "GRO fwd over UDP tunnel" $OL_NET$DST_NAT 1 1 $OL_NET$DST
+- cleanup
+-
+- create_vxlan_pair
+- run_bench "UDP tunnel fwd perf" $OL_NET$DST
+- ip netns exec $NS_DST ethtool -K veth$DST rx-udp-gro-forwarding on
+- run_bench "UDP tunnel GRO fwd perf" $OL_NET$DST
++ run_test "GRO fwd over UDP tunnel" $OL_NET$DST_NAT 10 10 $OL_NET$DST
+ cleanup
+ done
+
netfilter-validate-user-input-for-expected-length.patch
vboxsf-avoid-an-spurious-warning-if-load_nls_xxx-fails.patch
bpf-sockmap-prevent-lock-inversion-deadlock-in-map-delete-elem.patch
+net-sched-act_skbmod-prevent-kernel-infoleak.patch
+net-sched-fix-lockdep-splat-in-qdisc_tree_reduce_backlog.patch
+net-stmmac-fix-rx-queue-priority-assignment.patch
+net-phy-micrel-lan8814-fix-when-enabling-disabling-1-step-timestamping.patch
+net-phy-micrel-fix-potential-null-pointer-dereference.patch
+selftests-net-gro-fwd-update-vxlan-gro-test-expectations.patch
+gro-fix-ownership-transfer.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
