--- /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
+@@ -195,8 +195,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
+@@ -449,8 +449,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 4c36a156738887c1edd78589fe192d757989bcde Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Wed, 27 Mar 2024 12:48:53 +0000
+Subject: KVM: arm64: Ensure target address is granule-aligned for range TLBI
+
+From: Will Deacon <will@kernel.org>
+
+commit 4c36a156738887c1edd78589fe192d757989bcde upstream.
+
+When zapping a table entry in stage2_try_break_pte(), we issue range
+TLB invalidation for the region that was mapped by the table. However,
+we neglect to align the base address down to the granule size and so
+if we ended up reaching the table entry via a misaligned address then
+we will accidentally skip invalidation for some prefix of the affected
+address range.
+
+Align 'ctx->addr' down to the granule size when performing TLB
+invalidation for an unmapped table in stage2_try_break_pte().
+
+Cc: Raghavendra Rao Ananta <rananta@google.com>
+Cc: Gavin Shan <gshan@redhat.com>
+Cc: Shaoqin Huang <shahuang@redhat.com>
+Cc: Quentin Perret <qperret@google.com>
+Fixes: defc8cc7abf0 ("KVM: arm64: Invalidate the table entries upon a range")
+Signed-off-by: Will Deacon <will@kernel.org>
+Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20240327124853.11206-5-will@kernel.org
+Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/hyp/pgtable.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/arch/arm64/kvm/hyp/pgtable.c
++++ b/arch/arm64/kvm/hyp/pgtable.c
+@@ -829,12 +829,15 @@ static bool stage2_try_break_pte(const s
+ * Perform the appropriate TLB invalidation based on the
+ * evicted pte value (if any).
+ */
+- if (kvm_pte_table(ctx->old, ctx->level))
+- kvm_tlb_flush_vmid_range(mmu, ctx->addr,
+- kvm_granule_size(ctx->level));
+- else if (kvm_pte_valid(ctx->old))
++ if (kvm_pte_table(ctx->old, ctx->level)) {
++ u64 size = kvm_granule_size(ctx->level);
++ u64 addr = ALIGN_DOWN(ctx->addr, size);
++
++ kvm_tlb_flush_vmid_range(mmu, addr, size);
++ } else if (kvm_pte_valid(ctx->old)) {
+ kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, mmu,
+ ctx->addr, ctx->level);
++ }
+ }
+
+ if (stage2_pte_is_counted(ctx->old))
--- /dev/null
+From 0f0ff097bf77663b8d2692e33d56119947611bb0 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Wed, 27 Mar 2024 12:48:52 +0000
+Subject: KVM: arm64: Use TLBI_TTL_UNKNOWN in __kvm_tlb_flush_vmid_range()
+
+From: Will Deacon <will@kernel.org>
+
+commit 0f0ff097bf77663b8d2692e33d56119947611bb0 upstream.
+
+Commit c910f2b65518 ("arm64/mm: Update tlb invalidation routines for
+FEAT_LPA2") updated the __tlbi_level() macro to take the target level
+as an argument, with TLBI_TTL_UNKNOWN (rather than 0) indicating that
+the caller cannot provide level information. Unfortunately, the two
+implementations of __kvm_tlb_flush_vmid_range() were not updated and so
+now ask for an level 0 invalidation if FEAT_LPA2 is implemented.
+
+Fix the problem by passing TLBI_TTL_UNKNOWN instead of 0 as the level
+argument to __flush_s2_tlb_range_op() in __kvm_tlb_flush_vmid_range().
+
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Oliver Upton <oliver.upton@linux.dev>
+Cc: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
+Fixes: c910f2b65518 ("arm64/mm: Update tlb invalidation routines for FEAT_LPA2")
+Signed-off-by: Will Deacon <will@kernel.org>
+Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20240327124853.11206-4-will@kernel.org
+Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/hyp/nvhe/tlb.c | 3 ++-
+ arch/arm64/kvm/hyp/vhe/tlb.c | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/kvm/hyp/nvhe/tlb.c
++++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
+@@ -154,7 +154,8 @@ void __kvm_tlb_flush_vmid_range(struct k
+ /* Switch to requested VMID */
+ __tlb_switch_to_guest(mmu, &cxt, false);
+
+- __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride, 0);
++ __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride,
++ TLBI_TTL_UNKNOWN);
+
+ dsb(ish);
+ __tlbi(vmalle1is);
+--- a/arch/arm64/kvm/hyp/vhe/tlb.c
++++ b/arch/arm64/kvm/hyp/vhe/tlb.c
+@@ -171,7 +171,8 @@ void __kvm_tlb_flush_vmid_range(struct k
+ /* Switch to requested VMID */
+ __tlb_switch_to_guest(mmu, &cxt);
+
+- __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride, 0);
++ __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride,
++ TLBI_TTL_UNKNOWN);
+
+ dsb(ish);
+ __tlbi(vmalle1is);
--- /dev/null
+From 625aefac340f45a4fc60908da763f437599a0d6f Mon Sep 17 00:00:00 2001
+From: Michael Krummsdorf <michael.krummsdorf@tq-group.com>
+Date: Tue, 26 Mar 2024 13:36:54 +0100
+Subject: net: dsa: mv88e6xxx: fix usable ports on 88e6020
+
+From: Michael Krummsdorf <michael.krummsdorf@tq-group.com>
+
+commit 625aefac340f45a4fc60908da763f437599a0d6f upstream.
+
+The switch has 4 ports with 2 internal PHYs, but ports are numbered up
+to 6, with ports 0, 1, 5 and 6 being usable.
+
+Fixes: 71d94a432a15 ("net: dsa: mv88e6xxx: add support for MV88E6020 switch")
+Signed-off-by: Michael Krummsdorf <michael.krummsdorf@tq-group.com>
+Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/20240326123655.40666-1-matthias.schiffer@ew.tq-group.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/dsa/mv88e6xxx/chip.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/dsa/mv88e6xxx/chip.c
++++ b/drivers/net/dsa/mv88e6xxx/chip.c
+@@ -5500,8 +5500,12 @@ static const struct mv88e6xxx_info mv88e
+ .family = MV88E6XXX_FAMILY_6250,
+ .name = "Marvell 88E6020",
+ .num_databases = 64,
+- .num_ports = 4,
++ /* Ports 2-4 are not routed to pins
++ * => usable ports 0, 1, 5, 6
++ */
++ .num_ports = 7,
+ .num_internal_phys = 2,
++ .invalid_port_mask = BIT(2) | BIT(3) | BIT(4),
+ .max_vid = 4095,
+ .port_base_addr = 0x8,
+ .phy_base_addr = 0x0,
--- /dev/null
+From c120209bce34c49dcaba32f15679574327d09f63 Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Tue, 2 Apr 2024 20:33:56 +0200
+Subject: net: dsa: sja1105: Fix parameters order in sja1110_pcs_mdio_write_c45()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit c120209bce34c49dcaba32f15679574327d09f63 upstream.
+
+The definition and declaration of sja1110_pcs_mdio_write_c45() don't have
+parameters in the same order.
+
+Knowing that sja1110_pcs_mdio_write_c45() is used as a function pointer
+in 'sja1105_info' structure with .pcs_mdio_write_c45, and that we have:
+
+ int (*pcs_mdio_write_c45)(struct mii_bus *bus, int phy, int mmd,
+ int reg, u16 val);
+
+it is likely that the definition is the one to change.
+
+Found with cppcheck, funcArgOrderDifferent.
+
+Fixes: ae271547bba6 ("net: dsa: sja1105: C45 only transactions for PCS")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Reviewed-by: Michael Walle <mwalle@kernel.org>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://lore.kernel.org/r/ff2a5af67361988b3581831f7bd1eddebfb4c48f.1712082763.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/dsa/sja1105/sja1105_mdio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/dsa/sja1105/sja1105_mdio.c
++++ b/drivers/net/dsa/sja1105/sja1105_mdio.c
+@@ -94,7 +94,7 @@ int sja1110_pcs_mdio_read_c45(struct mii
+ return tmp & 0xffff;
+ }
+
+-int sja1110_pcs_mdio_write_c45(struct mii_bus *bus, int phy, int reg, int mmd,
++int sja1110_pcs_mdio_write_c45(struct mii_bus *bus, int phy, int mmd, int reg,
+ u16 val)
+ {
+ struct sja1105_mdio_private *mdio_priv = bus->priv;
--- /dev/null
+From cbc17e7802f5de37c7c262204baadfad3f7f99e5 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Thu, 28 Mar 2024 15:59:29 +0000
+Subject: net: fec: Set mac_managed_pm during probe
+
+From: Wei Fang <wei.fang@nxp.com>
+
+commit cbc17e7802f5de37c7c262204baadfad3f7f99e5 upstream.
+
+Setting mac_managed_pm during interface up is too late.
+
+In situations where the link is not brought up yet and the system suspends
+the regular PHY power management will run. Since the FEC ETHEREN control
+bit is cleared (automatically) on suspend the controller is off in resume.
+When the regular PHY power management resume path runs in this context it
+will write to the MII_DATA register but nothing will be transmitted on the
+MDIO bus.
+
+This can be observed by the following log:
+
+ fec 5b040000.ethernet eth0: MDIO read timeout
+ Microchip LAN87xx T1 5b040000.ethernet-1:04: PM: dpm_run_callback(): mdio_bus_phy_resume+0x0/0xc8 returns -110
+ Microchip LAN87xx T1 5b040000.ethernet-1:04: PM: failed to resume: error -110
+
+The data written will however remain in the MII_DATA register.
+
+When the link later is set to administrative up it will trigger a call to
+fec_restart() which will restore the MII_SPEED register. This triggers the
+quirk explained in f166f890c8f0 ("net: ethernet: fec: Replace interrupt
+driven MDIO with polled IO") causing an extra MII_EVENT.
+
+This extra event desynchronizes all the MDIO register reads, causing them
+to complete too early. Leading all reads to read as 0 because
+fec_enet_mdio_wait() returns too early.
+
+When a Microchip LAN8700R PHY is connected to the FEC, the 0 reads causes
+the PHY to be initialized incorrectly and the PHY will not transmit any
+ethernet signal in this state. It cannot be brought out of this state
+without a power cycle of the PHY.
+
+Fixes: 557d5dc83f68 ("net: fec: use mac-managed PHY PM")
+Closes: https://lore.kernel.org/netdev/1f45bdbe-eab1-4e59-8f24-add177590d27@actia.se/
+Signed-off-by: Wei Fang <wei.fang@nxp.com>
+[jernberg: commit message]
+Signed-off-by: John Ernberg <john.ernberg@actia.se>
+Link: https://lore.kernel.org/r/20240328155909.59613-2-john.ernberg@actia.se
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/freescale/fec_main.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/freescale/fec_main.c
++++ b/drivers/net/ethernet/freescale/fec_main.c
+@@ -2406,8 +2406,6 @@ static int fec_enet_mii_probe(struct net
+ fep->link = 0;
+ fep->full_duplex = 0;
+
+- phy_dev->mac_managed_pm = true;
+-
+ phy_attached_info(phy_dev);
+
+ return 0;
+@@ -2419,10 +2417,12 @@ static int fec_enet_mii_init(struct plat
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct fec_enet_private *fep = netdev_priv(ndev);
+ bool suppress_preamble = false;
++ struct phy_device *phydev;
+ struct device_node *node;
+ int err = -ENXIO;
+ u32 mii_speed, holdtime;
+ u32 bus_freq;
++ int addr;
+
+ /*
+ * The i.MX28 dual fec interfaces are not equal.
+@@ -2536,6 +2536,13 @@ static int fec_enet_mii_init(struct plat
+ goto err_out_free_mdiobus;
+ of_node_put(node);
+
++ /* find all the PHY devices on the bus and set mac_managed_pm to true */
++ for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
++ phydev = mdiobus_get_phy(fep->mii_bus, addr);
++ if (phydev)
++ phydev->mac_managed_pm = true;
++ }
++
+ mii_cnt++;
+
+ /* save fec0 mii_bus */
--- /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
+@@ -2528,7 +2528,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;
+@@ -2538,7 +2538,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_skb(struct kszphy_ptp_priv *ptp_priv,
+@@ -2550,7 +2554,8 @@ static bool lan8814_match_rx_skb(struct
+ 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);
+@@ -2830,7 +2835,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;
+@@ -2838,7 +2843,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_match_tx_skb(struct kszphy_ptp_priv *ptp_priv,
+@@ -2852,7 +2861,8 @@ static void lan8814_match_tx_skb(struct
+
+ 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;
+@@ -2906,7 +2916,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
+@@ -2416,6 +2416,7 @@ static int lan8814_hwtstamp(struct mii_t
+ struct lan8814_ptp_rx_ts *rx_ts, *tmp;
+ int txcfg = 0, rxcfg = 0;
+ int pkt_ts_enable;
++ int tx_mod;
+
+ ptp_priv->hwts_tx_type = config->tx_type;
+ ptp_priv->rx_filter = config->rx_filter;
+@@ -2462,9 +2463,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
+@@ -241,13 +241,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
+@@ -809,7 +809,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
+@@ -92,19 +92,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
+@@ -105,17 +105,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 c644920ce9220d83e070f575a4df711741c07f07 Mon Sep 17 00:00:00 2001
+From: Duanqiang Wen <duanqiangwen@net-swift.com>
+Date: Tue, 2 Apr 2024 10:18:43 +0800
+Subject: net: txgbe: fix i2c dev name cannot match clkdev
+
+From: Duanqiang Wen <duanqiangwen@net-swift.com>
+
+commit c644920ce9220d83e070f575a4df711741c07f07 upstream.
+
+txgbe clkdev shortened clk_name, so i2c_dev info_name
+also need to shorten. Otherwise, i2c_dev cannot initialize
+clock.
+
+Fixes: e30cef001da2 ("net: txgbe: fix clk_name exceed MAX_DEV_ID limits")
+Signed-off-by: Duanqiang Wen <duanqiangwen@net-swift.com>
+Link: https://lore.kernel.org/r/20240402021843.126192-1-duanqiangwen@net-swift.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
++++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
+@@ -20,6 +20,8 @@
+ #include "txgbe_phy.h"
+ #include "txgbe_hw.h"
+
++#define TXGBE_I2C_CLK_DEV_NAME "i2c_dw"
++
+ static int txgbe_swnodes_register(struct txgbe *txgbe)
+ {
+ struct txgbe_nodes *nodes = &txgbe->nodes;
+@@ -556,8 +558,8 @@ static int txgbe_clock_register(struct t
+ char clk_name[32];
+ struct clk *clk;
+
+- snprintf(clk_name, sizeof(clk_name), "i2c_dw.%d",
+- pci_dev_id(pdev));
++ snprintf(clk_name, sizeof(clk_name), "%s.%d",
++ TXGBE_I2C_CLK_DEV_NAME, pci_dev_id(pdev));
+
+ clk = clk_register_fixed_rate(NULL, clk_name, NULL, 0, 156250000);
+ if (IS_ERR(clk))
+@@ -619,7 +621,7 @@ static int txgbe_i2c_register(struct txg
+
+ info.parent = &pdev->dev;
+ info.fwnode = software_node_fwnode(txgbe->nodes.group[SWNODE_I2C]);
+- info.name = "i2c_designware";
++ info.name = TXGBE_I2C_CLK_DEV_NAME;
+ info.id = pci_dev_id(pdev);
+
+ info.res = &DEFINE_RES_IRQ(pdev->irq);
--- /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
+@@ -241,7 +241,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
+@@ -254,13 +254,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
+
vboxsf-avoid-an-spurious-warning-if-load_nls_xxx-fails.patch
bpf-sockmap-prevent-lock-inversion-deadlock-in-map-delete-elem.patch
mptcp-prevent-bpf-accessing-lowat-from-a-subflow-socket.patch
+x86-retpoline-do-the-necessary-fixup-to-the-zen3-4-srso-return-thunk-for-srso.patch
+kvm-arm64-use-tlbi_ttl_unknown-in-__kvm_tlb_flush_vmid_range.patch
+kvm-arm64-ensure-target-address-is-granule-aligned-for-range-tlbi.patch
+net-sched-act_skbmod-prevent-kernel-infoleak.patch
+net-dsa-sja1105-fix-parameters-order-in-sja1110_pcs_mdio_write_c45.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-txgbe-fix-i2c-dev-name-cannot-match-clkdev.patch
+net-fec-set-mac_managed_pm-during-probe.patch
+net-phy-micrel-fix-potential-null-pointer-dereference.patch
+net-dsa-mv88e6xxx-fix-usable-ports-on-88e6020.patch
+selftests-net-gro-fwd-update-vxlan-gro-test-expectations.patch
+gro-fix-ownership-transfer.patch
--- /dev/null
+From 0e110732473e14d6520e49d75d2c88ef7d46fe67 Mon Sep 17 00:00:00 2001
+From: "Borislav Petkov (AMD)" <bp@alien8.de>
+Date: Tue, 2 Apr 2024 16:05:49 +0200
+Subject: x86/retpoline: Do the necessary fixup to the Zen3/4 srso return thunk for !SRSO
+
+From: Borislav Petkov (AMD) <bp@alien8.de>
+
+commit 0e110732473e14d6520e49d75d2c88ef7d46fe67 upstream.
+
+The srso_alias_untrain_ret() dummy thunk in the !CONFIG_MITIGATION_SRSO
+case is there only for the altenative in CALL_UNTRAIN_RET to have
+a symbol to resolve.
+
+However, testing with kernels which don't have CONFIG_MITIGATION_SRSO
+enabled, leads to the warning in patch_return() to fire:
+
+ missing return thunk: srso_alias_untrain_ret+0x0/0x10-0x0: eb 0e 66 66 2e
+ WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:826 apply_returns (arch/x86/kernel/alternative.c:826
+
+Put in a plain "ret" there so that gcc doesn't put a return thunk in
+in its place which special and gets checked.
+
+In addition:
+
+ ERROR: modpost: "srso_alias_untrain_ret" [arch/x86/kvm/kvm-amd.ko] undefined!
+ make[2]: *** [scripts/Makefile.modpost:145: Module.symvers] Chyba 1
+ make[1]: *** [/usr/src/linux-6.8.3/Makefile:1873: modpost] Chyba 2
+ make: *** [Makefile:240: __sub-make] Chyba 2
+
+since !SRSO builds would use the dummy return thunk as reported by
+petr.pisar@atlas.cz, https://bugzilla.kernel.org/show_bug.cgi?id=218679.
+
+Reported-by: kernel test robot <oliver.sang@intel.com>
+Closes: https://lore.kernel.org/oe-lkp/202404020901.da75a60f-oliver.sang@intel.com
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Link: https://lore.kernel.org/all/202404020901.da75a60f-oliver.sang@intel.com/
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/lib/retpoline.S | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/lib/retpoline.S
++++ b/arch/x86/lib/retpoline.S
+@@ -229,8 +229,11 @@ SYM_CODE_END(srso_return_thunk)
+ #define JMP_SRSO_UNTRAIN_RET "ud2"
+ /* Dummy for the alternative in CALL_UNTRAIN_RET. */
+ SYM_CODE_START(srso_alias_untrain_ret)
+- RET
++ ANNOTATE_UNRET_SAFE
++ ret
++ int3
+ SYM_FUNC_END(srso_alias_untrain_ret)
++__EXPORT_THUNK(srso_alias_untrain_ret)
+ #endif /* CONFIG_CPU_SRSO */
+
+ #ifdef CONFIG_CPU_UNRET_ENTRY
projects / thirdparty / kernel / stable-queue.git / commitdiff
