6.1.130-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 130/176 ipvlan: ensure network headers are in skb linear part
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 27843ce6ba3d3122b65066550fe33fb8839f8aef ]
syzbot found that ipvlan_process_v6_outbound() was assuming the IPv6 network header isis present in skb->head [1]
Add the needed pskb_network_may_pull() calls for both IPv4 and IPv6 handlers.
[1]
BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline]
--- drivers/net/ipvlan/ipvlan_core.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
drivers/net/ipvlan/ipvlan_core.c +16 -5
@@ -416,20 +416,25 @@ struct ipvl_addr *ipvlan_addr_lookup(struct ipvl_port *port, void *lyr3h, static noinline_for_stack int ipvlan_process_v4_outbound(struct sk_buff *skb) { -const struct iphdr *ip4h =ip_hdr (skb);struct net_device *dev = skb->dev;struct net *net =dev_net (dev); -struct rtable *rt;int err, ret =NET_XMIT_DROP ; +const struct iphdr *ip4h; +struct rtable *rt;struct flowi4 fl4 = { .flowi4_oif = dev->ifindex, - .flowi4_tos =inet_dscp_to_dsfield (ip4h_dscp (ip4h)), .flowi4_flags =FLOWI_FLAG_ANYSRC , .flowi4_mark = skb->mark, - .daddr = ip4h->daddr, - .saddr = ip4h->saddr, }; +if (!pskb_network_may_pull (skb,sizeof (struct iphdr ))) + goto err; + + ip4h =ip_hdr (skb); + fl4.daddr = ip4h->daddr; + fl4.saddr = ip4h->saddr; + fl4.flowi4_tos =inet_dscp_to_dsfield (ip4h_dscp (ip4h)); + rt =ip_route_output_flow (net, &fl4,NULL );if (IS_ERR (rt)) goto err;
@@ -488,6 +493,12 @@ static int ipvlan_process_v6_outbound(struct sk_buff *skb)struct net_device *dev = skb->dev;int err, ret =NET_XMIT_DROP ; +if (!pskb_network_may_pull (skb,sizeof (struct ipv6hdr ))) { +DEV_STATS_INC (dev, tx_errors); +kfree_skb (skb); +return ret; + } + err =ipvlan_route_v6_outbound (dev, skb);if (unlikely (err)) {DEV_STATS_INC (dev, tx_errors);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 131/176 net: cadence: macb: Synchronize stats calculations
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Anderson <[email protected]>
[ Upstream commit fa52f15c745ce55261b92873676f64f7348cfe82 ]
Stats calculations involve a RMW to add the stat update to the existing value. This is currently not protected by any synchronization mechanism, so data races are possible. Add a spinlock to protect the update. The reader side could be protected using u64_stats, but we would still need a spinlock for the update side anyway. And we always do an update immediately before reading the stats anyway.
--- drivers/net/ethernet/cadence/macb.h | 2 ++ drivers/net/ethernet/cadence/macb_main.c | 12 ++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-)
drivers/net/ethernet/cadence/macb.h +2 -0
@@ -1271,6 +1271,8 @@ struct macb {struct clk *rx_clk;struct clk *tsu_clk;struct net_device *dev; +/* Protects hw_stats and ethtool_stats */ +spinlock_t stats_lock;union {struct macb_stats macb;struct gem_stats gem;
drivers/net/ethernet/cadence/macb_main.c +10 -2
@@ -1936,10 +1936,12 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)if (status &MACB_BIT (ISR_ROVR )) {/* We missed at least one packet */ +spin_lock (&bp->stats_lock);if (macb_is_gem (bp)) bp->hw_stats.gem.rx_overruns++;else bp->hw_stats.macb.rx_overruns++; +spin_unlock (&bp->stats_lock);if (bp->caps &MACB_CAPS_ISR_CLEAR_ON_WRITE )queue_writel (queue,ISR ,MACB_BIT (ISR_ROVR ));
@@ -2999,6 +3001,7 @@ static struct net_device_stats *gem_get_stats(struct macb *bp)if (!netif_running (bp->dev))return nstat; +spin_lock_irq (&bp->stats_lock);gem_update_stats (bp); nstat->rx_errors = (hwstat->rx_frame_check_sequence_errors +
@@ -3028,6 +3031,7 @@ static struct net_device_stats *gem_get_stats(struct macb *bp) nstat->tx_aborted_errors = hwstat->tx_excessive_collisions; nstat->tx_carrier_errors = hwstat->tx_carrier_sense_errors; nstat->tx_fifo_errors = hwstat->tx_underrun; +spin_unlock_irq (&bp->stats_lock);return nstat; }
@@ -3035,12 +3039,13 @@ static struct net_device_stats *gem_get_stats(struct macb *bp)static void gem_get_ethtool_stats (struct net_device *dev,struct ethtool_stats *stats,u64 *data) { -struct macb *bp; +struct macb *bp =netdev_priv (dev); - bp =netdev_priv (dev); +spin_lock_irq (&bp->stats_lock);gem_update_stats (bp);memcpy (data, &bp->ethtool_stats,sizeof (u64) * (GEM_STATS_LEN +QUEUE_STATS_LEN *MACB_MAX_QUEUES )); +spin_unlock_irq (&bp->stats_lock); }static int gem_get_sset_count (struct net_device *dev,int sset)
@@ -3090,6 +3095,7 @@ static struct net_device_stats *macb_get_stats(struct net_device *dev)return gem_get_stats (bp);/* read stats from hardware */ +spin_lock_irq (&bp->stats_lock);macb_update_stats (bp);/* Convert HW stats into netdevice stats */
@@ -3123,6 +3129,7 @@ static struct net_device_stats *macb_get_stats(struct net_device *dev) nstat->tx_carrier_errors = hwstat->tx_carrier_errors; nstat->tx_fifo_errors = hwstat->tx_underruns;/* Don't know about heartbeat or window errors... */ +spin_unlock_irq (&bp->stats_lock);return nstat; }
@@ -4949,6 +4956,7 @@ static int macb_probe(struct platform_device *pdev) bp->usrio = macb_config->usrio;spin_lock_init (&bp->lock); +spin_lock_init (&bp->stats_lock);/* setup capabilities */ macb_configure_caps (bp, macb_config);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 132/176 ASoC: es8328: fix route from DAC to output
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Frattaroli <[email protected]>
[ Upstream commit 5b0c02f9b8acf2a791e531bbc09acae2d51f4f9b ]
The ES8328 codec driver, which is also used for the ES8388 chip that appears to have an identical register map, claims that the output can either take the route from DAC->Mixer->Output or through DAC->Output directly. To the best of what I could find, this is not true, and creates problems.
Without DACCONTROL17 bit index 7 set for the left channel, as well as DACCONTROL20 bit index 7 set for the right channel, I cannot get any analog audio out on Left Out 2 and Right Out 2 respectively, despite the DAPM routes claiming that this should be possible. Furthermore, the same is the case for Left Out 1 and Right Out 1, showing that those two don't have a direct route from DAC to output bypassing the mixer either.
Those control bits toggle whether the DACs are fed (stale bread?) into their respective mixers. If one "unmutes" the mixer controls in alsamixer, then sure, the audio output works, but if it doesn't work without the mixer being fed the DAC input then evidently it's not a direct output from the DAC.
ES8328/ES8388 are seemingly not alone in this. ES8323, which uses a separate driver for what appears to be a very similar register map, simply flips those two bits on in its probe function, and then pretends there is no power management whatsoever for the individual controls. Fair enough.
My theory as to why nobody has noticed this up to this point is that everyone just assumes it's their fault when they had to unmute an additional control in ALSA.
Fix this in the es8328 driver by removing the erroneous direct route, then get rid of the playback switch controls and have those bits tied to the mixer's widget instead, which until now had no register to play with.
--- sound/soc/codecs/es8328.c | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-)
sound/soc/codecs/es8328.c +4 -11
@@ -234,7 +234,6 @@ static const struct snd_kcontrol_new es8328_right_line_controls =/* Left Mixer */ static const struct snd_kcontrol_new es8328_left_mixer_controls[] = { -SOC_DAPM_SINGLE ("Playback Switch" ,ES8328_DACCONTROL17 ,7 ,1 ,0 ),SOC_DAPM_SINGLE ("Left Bypass Switch" ,ES8328_DACCONTROL17 ,6 ,1 ,0 ),SOC_DAPM_SINGLE ("Right Playback Switch" ,ES8328_DACCONTROL18 ,7 ,1 ,0 ),SOC_DAPM_SINGLE ("Right Bypass Switch" ,ES8328_DACCONTROL18 ,6 ,1 ,0 ),
@@ -244,7 +243,6 @@ static const struct snd_kcontrol_new es8328_left_mixer_controls[] = {static const struct snd_kcontrol_new es8328_right_mixer_controls[] = {SOC_DAPM_SINGLE ("Left Playback Switch" ,ES8328_DACCONTROL19 ,7 ,1 ,0 ),SOC_DAPM_SINGLE ("Left Bypass Switch" ,ES8328_DACCONTROL19 ,6 ,1 ,0 ), -SOC_DAPM_SINGLE ("Playback Switch" ,ES8328_DACCONTROL20 ,7 ,1 ,0 ),SOC_DAPM_SINGLE ("Right Bypass Switch" ,ES8328_DACCONTROL20 ,6 ,1 ,0 ), };
@@ -337,10 +335,10 @@ static const struct snd_soc_dapm_widget es8328_dapm_widgets[] = {SND_SOC_DAPM_DAC ("Left DAC" ,"Left Playback" ,ES8328_DACPOWER ,ES8328_DACPOWER_LDAC_OFF ,1 ), -SND_SOC_DAPM_MIXER ("Left Mixer" ,SND_SOC_NOPM ,0 ,0 , +SND_SOC_DAPM_MIXER ("Left Mixer" ,ES8328_DACCONTROL17 ,7 ,0 , &es8328_left_mixer_controls[0 ],ARRAY_SIZE (es8328_left_mixer_controls)), -SND_SOC_DAPM_MIXER ("Right Mixer" ,SND_SOC_NOPM ,0 ,0 , +SND_SOC_DAPM_MIXER ("Right Mixer" ,ES8328_DACCONTROL20 ,7 ,0 , &es8328_right_mixer_controls[0 ], ARRAY_SIZE(es8328_right_mixer_controls)),
@@ -419,19 +417,14 @@ static const struct snd_soc_dapm_route es8328_dapm_routes[] = { { "Right Line Mux", "PGA", "Right PGA Mux" }, { "Right Line Mux", "Differential", "Differential Mux" }, - { "Left Out 1", NULL, "Left DAC" }, - { "Right Out 1", NULL, "Right DAC" }, - { "Left Out 2", NULL, "Left DAC" }, - { "Right Out 2", NULL, "Right DAC" }, - - { "Left Mixer", "Playback Switch", "Left DAC" }, + { "Left Mixer", NULL, "Left DAC" }, { "Left Mixer", "Left Bypass Switch", "Left Line Mux" }, { "Left Mixer", "Right Playback Switch", "Right DAC" }, { "Left Mixer", "Right Bypass Switch", "Right Line Mux" }, { "Right Mixer", "Left Playback Switch", "Left DAC" }, { "Right Mixer", "Left Bypass Switch", "Left Line Mux" }, - { "Right Mixer", "Playback Switch", "Right DAC" }, + { "Right Mixer", NULL, "Right DAC" }, { "Right Mixer", "Right Bypass Switch", "Right Line Mux" }, { "DAC DIG", NULL, "DAC STM" },
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 133/176 ipvs: Always clear ipvs_property flag in skb_scrub_packet()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Philo Lu <[email protected]>
[ Upstream commit de2c211868b9424f9aa9b3432c4430825bafb41b ]
We found an issue when using bpf_redirect with ipvs NAT mode after commit ff70202b2d1a ("dev_forward_skb: do not scrub skb mark within the same name space"). Particularly, we use bpf_redirect to return the skb directly back to the netif it comes from, i.e., xnet is false in skb_scrub_packet(), and then ipvs_property is preserved and SNAT is skipped in the rx path.
ipvs_property has been already cleared when netns is changed in commit 2b5ec1a5f973 ("netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed"). This patch just clears it in spite of netns.
--- net/core/skbuff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/skbuff.c +1 -1
@@ -5556,11 +5556,11 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet) skb->offload_fwd_mark =0 ; skb->offload_l3_fwd_mark =0 ;#endif +ipvs_reset (skb);if (!xnet)return ; -ipvs_reset (skb); skb->mark =0 ;skb_clear_tstamp (skb); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 134/176 tcp: Defer ts_recent changes until req is owned
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Hai <[email protected]>
[ Upstream commit 8d52da23b6c68a0f6bad83959ebb61a2cf623c4e ]
Recently a bug was discovered where the server had entered TCP_ESTABLISHED state, but the upper layers were not notified.
The same 5-tuple packet may be processed by different CPUSs, so two CPUs may receive different ack packets at the same time when the state is TCP_NEW_SYN_RECV.
In that case, req->ts_recent in tcp_check_req may be changed concurrently, which will probably cause the newsk's ts_recent to be incorrectly large. So that tcp_validate_incoming will fail. At this point, newsk will not be able to enter the TCP_ESTABLISHED.
cpu1 cpu2tcp_check_req
tcp_check_req
req->ts_recent = rcv_tsval = t1
req->ts_recent = rcv_tsval = t2
syn_recv_sock
tcp_sk(child)->rx_opt.ts_recent = req->ts_recent = t2 // t1 < t2tcp_child_process
tcp_rcv_state_process
tcp_validate_incoming
tcp_paws_check
if ((s32)(rx_opt->ts_recent - rx_opt->rcv_tsval) <= paws_win)
// t2 - t1 > paws_win, failed
tcp_v4_do_rcv
tcp_rcv_state_process
// TCP_ESTABLISHEDThe cpu2's skb or a newly received skb will call tcp_v4_do_rcv to get the newsk into the TCP_ESTABLISHED state, but at this point it is no longer possible to notify the upper layer application. A notification mechanism could be added here, but the fix is more complex, so the current fix is used.
In tcp_check_req, req->ts_recent is used to assign a value to tcp_sk(child)->rx_opt.ts_recent, so removing the change in req->ts_recent and changing tcp_sk(child)->rx_opt.ts_recent directly after owning the req fixes this bug.
--- net/ipv4/tcp_minisocks.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
net/ipv4/tcp_minisocks.c +4 -6
@@ -735,12 +735,6 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,/* In sequence, PAWS is OK. */ -/* TODO: We probably should defer ts_recent change once -* we take ownership of @req. -*/ -if (tmp_opt.saw_tstamp && !after (TCP_SKB_CB (skb)->seq,tcp_rsk (req)->rcv_nxt)) -WRITE_ONCE (req->ts_recent, tmp_opt.rcv_tsval); -if (TCP_SKB_CB (skb)->seq ==tcp_rsk (req)->rcv_isn) {/* Truncate SYN, it is out of window starting at tcp_rsk(req)->rcv_isn + 1. */
@@ -789,6 +783,10 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,if (!child) goto listen_overflow; +if (own_req && tmp_opt.saw_tstamp && + !after (TCP_SKB_CB (skb)->seq,tcp_rsk (req)->rcv_nxt)) +tcp_sk (child)->rx_opt.ts_recent = tmp_opt.rcv_tsval; +if (own_req &&rsk_drop_req (req)) {reqsk_queue_removed (&inet_csk (req->rsk_listener)->icsk_accept_queue, req);inet_csk_reqsk_queue_drop_and_put (req->rsk_listener, req);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 135/176 net: Clear old fragment checksum value in napi_reuse_skb
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohammad Heib <[email protected]>
[ Upstream commit 49806fe6e61b045b5be8610e08b5a3083c109aa0 ]
In certain cases, napi_get_frags() returns an skb that points to an old received fragment, This skb may have its skb->ip_summed, csum, and other fields set from previous fragment handling.
Some network drivers set skb->ip_summed to either CHECKSUM_COMPLETE or CHECKSUM_UNNECESSARY when getting skb from napi_get_frags(), while others only set skb->ip_summed when RX checksum offload is enabled on the device, and do not set any value for skb->ip_summed when hardware checksum offload is disabled, assuming that the skb->ip_summed initiated to zero by napi_reuse_skb, ionic driver for example will ignore/unset any value for the ip_summed filed if HW checksum offload is disabled, and if we have a situation where the user disables the checksum offload during a traffic that could lead to the following errors shown in the kernel logs:
<IRQ> dump_stack_lvl+0x34/0x48 __skb_gro_checksum_complete+0x7e/0x90 tcp6_gro_receive+0xc6/0x190 ipv6_gro_receive+0x1ec/0x430 dev_gro_receive+0x188/0x360 ? ionic_rx_clean+0x25a/0x460 [ionic] napi_gro_frags+0x13c/0x300 ? __pfx_ionic_rx_service+0x10/0x10 [ionic] ionic_rx_service+0x67/0x80 [ionic] ionic_cq_service+0x58/0x90 [ionic] ionic_txrx_napi+0x64/0x1b0 [ionic] __napi_poll+0x27/0x170 net_rx_action+0x29c/0x370 handle_softirqs+0xce/0x270 __irq_exit_rcu+0xa3/0xc0 common_interrupt+0x80/0xa0 </IRQ>
This inconsistency sometimes leads to checksum validation issues in the upper layers of the network stack.
To resolve this, this patch clears the skb->ip_summed value for each reused skb in by napi_reuse_skb(), ensuring that the caller is responsible for setting the correct checksum status. This eliminates potential checksum validation issues caused by improper handling of skb->ip_summed.
--- net/core/gro.c | 1 + 1 file changed, 1 insertion(+)
net/core/gro.c +1 -0
@@ -679,6 +679,7 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb) skb->pkt_type =PACKET_HOST ; skb->encapsulation =0 ; + skb->ip_summed =CHECKSUM_NONE ;skb_shinfo (skb)->gso_type =0 ;skb_shinfo (skb)->gso_size =0 ;if (unlikely (skb->slow_gro)) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 136/176 net: mvpp2: cls: Fixed Non IP flow, with vlan tag flow defination.
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harshal Chaudhari <[email protected]>
[ Upstream commit 2d253726ff7106b39a44483b6864398bba8a2f74 ]
Non IP flow, with vlan tag not working as expected while running below command for vlan-priority. fixed that.
ethtool -N eth1 flow-type ether vlan 0x8000 vlan-mask 0x1fff action 0 loc 0
--- drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c +1 -1
@@ -324,7 +324,7 @@ static const struct mvpp2_cls_flow cls_flows[MVPP2_N_PRS_FLOWS] = { MVPP2_PRS_RI_VLAN_MASK),/* Non IP flow, with vlan tag */ MVPP2_DEF_FLOW (MVPP22_FLOW_ETHERNET ,MVPP2_FL_NON_IP_TAG , -MVPP22_CLS_HEK_OPT_VLAN , +MVPP22_CLS_HEK_TAGGED , 0, 0), };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 137/176 net/mlx5: IRQ, Fix null string in debug print
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shay Drory <[email protected]>
[ Upstream commit 2f5a6014eb168a97b24153adccfa663d3b282767 ]
irq_pool_alloc() debug print can print a null string. Fix it by providing a default string to print.
--- drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c +1 -1
@@ -513,7 +513,7 @@ irq_pool_alloc(struct mlx5_core_dev *dev, int start, int size, char *name, pool->min_threshold = min_threshold *MLX5_EQ_REFS_PER_IRQ ; pool->max_threshold = max_threshold *MLX5_EQ_REFS_PER_IRQ ;mlx5_core_dbg (dev,"pool->name = %s, pool->size = %d, pool->start = %d" , - name, size, start); + name ? name :"mlx5_pcif_pool" , size, start);return pool; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 138/176 include: net: add static inline dst_dev_overhead() to dst.h
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Justin Iurman <[email protected]>
[ Upstream commit 0600cf40e9b36fe17f9c9f04d4f9cef249eaa5e7 ]
Add static inline dst_dev_overhead() function to include/net/dst.h. This helper function is used by ioam6_iptunnel, rpl_iptunnel and seg6_iptunnel to get the dev's overhead based on a cache entry (dst_entry). If the cache is empty, the default and generic value skb->mac_len is returned. Otherwise, LL_RESERVED_SPACE() over dst's dev is returned.
Stable-dep-of: c64a0727f9b1 ("net: ipv6: fix dst ref loop on input in seg6 lwt")
--- include/net/dst.h | 9 +++++++++ 1 file changed, 9 insertions(+)
include/net/dst.h +9 -0
@@ -434,6 +434,15 @@ static inline void dst_set_expires(struct dst_entry *dst, int timeout) dst->expires = expires; } +static inline unsigned int dst_dev_overhead (struct dst_entry *dst, +struct sk_buff *skb) +{ +if (likely (dst)) +return LL_RESERVED_SPACE (dst->dev); + +return skb->mac_len; +} + INDIRECT_CALLABLE_DECLARE(int ip6_output(struct net *, struct sock *,struct sk_buff *)); INDIRECT_CALLABLE_DECLARE(int ip_output(struct net *, struct sock *,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 139/176 net: ipv6: seg6_iptunnel: mitigate 2-realloc issue
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Justin Iurman <[email protected]>
[ Upstream commit 40475b63761abb6f8fdef960d03228a08662c9c4 ]
This patch mitigates the two-reallocations issue with seg6_iptunnel by providing the dst_entry (in the cache) to the first call to skb_cow_head(). As a result, the very first iteration would still trigger two reallocations (i.e., empty cache), while next iterations would only trigger a single reallocation.
Performance tests before/after applying this patch, which clearly shows the improvement:
- before: https://ibb.co/3Cg4sNH
- after: https://ibb.co/8rQ350r
Stable-dep-of: c64a0727f9b1 ("net: ipv6: fix dst ref loop on input in seg6 lwt")
--- net/ipv6/seg6_iptunnel.c | 85 ++++++++++++++++++++++++---------------- 1 file changed, 52 insertions(+), 33 deletions(-)
net/ipv6/seg6_iptunnel.c +52 -33
@@ -124,8 +124,8 @@ static __be32 seg6_make_flowlabel(struct net *net, struct sk_buff *skb,return flowlabel; } -/* encapsulate an IPv6 packet within an outer IPv6 header with a given SRH */ -int seg6_do_srh_encap (struct sk_buff *skb,struct ipv6_sr_hdr *osrh,int proto) +static int __seg6_do_srh_encap (struct sk_buff *skb,struct ipv6_sr_hdr *osrh, +int proto,struct dst_entry *cache_dst) {struct dst_entry *dst =skb_dst (skb);struct net *net =dev_net (dst->dev);
@@ -137,7 +137,7 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto) hdrlen = (osrh->hdrlen +1 ) <<3 ; tot_len = hdrlen +sizeof (*hdr); - err =skb_cow_head (skb, tot_len + skb->mac_len); + err =skb_cow_head (skb, tot_len +dst_dev_overhead (cache_dst, skb));if (unlikely (err))return err;
@@ -197,11 +197,18 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto)return 0 ; } + +/* encapsulate an IPv6 packet within an outer IPv6 header with a given SRH */ +int seg6_do_srh_encap (struct sk_buff *skb,struct ipv6_sr_hdr *osrh,int proto) +{ +return __seg6_do_srh_encap (skb, osrh, proto,NULL ); +}EXPORT_SYMBOL_GPL (seg6_do_srh_encap);/* encapsulate an IPv6 packet within an outer IPv6 header with reduced SRH */ static int seg6_do_srh_encap_red (struct sk_buff *skb, -struct ipv6_sr_hdr *osrh,int proto) +struct ipv6_sr_hdr *osrh,int proto, +struct dst_entry *cache_dst) {__u8 first_seg = osrh->first_segment;struct dst_entry *dst =skb_dst (skb);
@@ -230,7 +237,7 @@ static int seg6_do_srh_encap_red(struct sk_buff *skb, tot_len = red_hdrlen +sizeof (struct ipv6hdr ); - err =skb_cow_head (skb, tot_len + skb->mac_len); + err =skb_cow_head (skb, tot_len +dst_dev_overhead (cache_dst, skb));if (unlikely (err))return err;
@@ -317,8 +324,8 @@ static int seg6_do_srh_encap_red(struct sk_buff *skb,return 0 ; } -/* insert an SRH within an IPv6 packet, just after the IPv6 header */ -int seg6_do_srh_inline (struct sk_buff *skb,struct ipv6_sr_hdr *osrh) +static int __seg6_do_srh_inline (struct sk_buff *skb,struct ipv6_sr_hdr *osrh, +struct dst_entry *cache_dst) {struct ipv6hdr *hdr, *oldhdr;struct ipv6_sr_hdr *isrh;
@@ -326,7 +333,7 @@ int seg6_do_srh_inline(struct sk_buff *skb, struct ipv6_sr_hdr *osrh) hdrlen = (osrh->hdrlen +1 ) <<3 ; - err =skb_cow_head (skb, hdrlen + skb->mac_len); + err =skb_cow_head (skb, hdrlen +dst_dev_overhead (cache_dst, skb));if (unlikely (err))return err;
@@ -369,9 +376,8 @@ int seg6_do_srh_inline(struct sk_buff *skb, struct ipv6_sr_hdr *osrh)return 0 ; } -EXPORT_SYMBOL_GPL (seg6_do_srh_inline); -static int seg6_do_srh (struct sk_buff *skb) +static int seg6_do_srh (struct sk_buff *skb,struct dst_entry *cache_dst) {struct dst_entry *dst =skb_dst (skb);struct seg6_iptunnel_encap *tinfo;
@@ -384,7 +390,7 @@ static int seg6_do_srh(struct sk_buff *skb)if (skb->protocol !=htons (ETH_P_IPV6 ))return -EINVAL ; - err =seg6_do_srh_inline (skb, tinfo->srh); + err =__seg6_do_srh_inline (skb, tinfo->srh, cache_dst);if (err)return err;break ;
@@ -402,9 +408,11 @@ static int seg6_do_srh(struct sk_buff *skb)return -EINVAL ;if (tinfo->mode ==SEG6_IPTUN_MODE_ENCAP ) - err =seg6_do_srh_encap (skb, tinfo->srh, proto); + err =__seg6_do_srh_encap (skb, tinfo->srh, + proto, cache_dst);else - err =seg6_do_srh_encap_red (skb, tinfo->srh, proto); + err =seg6_do_srh_encap_red (skb, tinfo->srh, + proto, cache_dst);if (err)return err;
@@ -425,11 +433,13 @@ static int seg6_do_srh(struct sk_buff *skb)skb_push (skb, skb->mac_len);if (tinfo->mode ==SEG6_IPTUN_MODE_L2ENCAP ) - err =seg6_do_srh_encap (skb, tinfo->srh, -IPPROTO_ETHERNET ); + err =__seg6_do_srh_encap (skb, tinfo->srh, +IPPROTO_ETHERNET , + cache_dst);else err =seg6_do_srh_encap_red (skb, tinfo->srh, -IPPROTO_ETHERNET ); +IPPROTO_ETHERNET , + cache_dst);if (err)return err;
@@ -444,6 +454,13 @@ static int seg6_do_srh(struct sk_buff *skb)return 0 ; } +/* insert an SRH within an IPv6 packet, just after the IPv6 header */ +int seg6_do_srh_inline (struct sk_buff *skb,struct ipv6_sr_hdr *osrh) +{ +return __seg6_do_srh_inline (skb, osrh,NULL ); +} +EXPORT_SYMBOL_GPL (seg6_do_srh_inline); +static int seg6_input_finish (struct net *net,struct sock *sk,struct sk_buff *skb) {
@@ -458,14 +475,15 @@ static int seg6_input_core(struct net *net, struct sock *sk,struct seg6_lwt *slwt;int err; - err =seg6_do_srh (skb); -if (unlikely (err)) - goto drop; - slwt =seg6_lwt_lwtunnel (orig_dst->lwtstate);local_bh_disable (); dst =dst_cache_get (&slwt->cache); +local_bh_enable (); + + err =seg6_do_srh (skb, dst); +if (unlikely (err)) + goto drop;skb_dst_drop (skb);
@@ -473,17 +491,18 @@ static int seg6_input_core(struct net *net, struct sock *sk,ip6_route_input (skb); dst =skb_dst (skb);if (!dst->error) { +local_bh_disable ();dst_cache_set_ip6 (&slwt->cache, dst, &ipv6_hdr (skb)->saddr); +local_bh_enable (); } + + err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); +if (unlikely (err)) + goto drop; }else {skb_dst_set (skb, dst); } -local_bh_enable (); - - err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); -if (unlikely (err)) - goto drop;if (static_branch_unlikely (&nf_hooks_lwtunnel_enabled)) return NF_HOOK(NFPROTO_IPV6, NF_INET_LOCAL_OUT,
@@ -529,16 +548,16 @@ static int seg6_output_core(struct net *net, struct sock *sk,struct seg6_lwt *slwt;int err; - err =seg6_do_srh (skb); -if (unlikely (err)) - goto drop; - slwt =seg6_lwt_lwtunnel (orig_dst->lwtstate);local_bh_disable (); dst =dst_cache_get (&slwt->cache);local_bh_enable (); + err =seg6_do_srh (skb, dst); +if (unlikely (err)) + goto drop; +if (unlikely (!dst)) {struct ipv6hdr *hdr =ipv6_hdr (skb);struct flowi6 fl6;
@@ -560,15 +579,15 @@ static int seg6_output_core(struct net *net, struct sock *sk,local_bh_disable ();dst_cache_set_ip6 (&slwt->cache, dst, &fl6.saddr);local_bh_enable (); + + err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); +if (unlikely (err)) + goto drop; }skb_dst_drop (skb);skb_dst_set (skb, dst); - err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); -if (unlikely (err)) - goto drop; -if (static_branch_unlikely (&nf_hooks_lwtunnel_enabled))return NF_HOOK (NFPROTO_IPV6 ,NF_INET_LOCAL_OUT , net, sk, skb,NULL ,skb_dst (skb)->dev, dst_output);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 140/176 net: ipv6: fix dst ref loop on input in seg6 lwt
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Justin Iurman <[email protected]>
[ Upstream commit c64a0727f9b1cbc63a5538c8c0014e9a175ad864 ]
Prevent a dst ref loop on input in seg6_iptunnel.
--- net/ipv6/seg6_iptunnel.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
net/ipv6/seg6_iptunnel.c +12 -2
@@ -472,10 +472,18 @@ static int seg6_input_core(struct net *net, struct sock *sk, {struct dst_entry *orig_dst =skb_dst (skb);struct dst_entry *dst =NULL ; +struct lwtunnel_state *lwtst;struct seg6_lwt *slwt;int err; - slwt =seg6_lwt_lwtunnel (orig_dst->lwtstate); +/* We cannot dereference "orig_dst" once ip6_route_input() or +* skb_dst_drop() is called. However, in order to detect a dst loop, we +* need the address of its lwtstate. So, save the address of lwtstate +* now and use it later as a comparison. +*/ + lwtst = orig_dst->lwtstate; + + slwt =seg6_lwt_lwtunnel (lwtst);local_bh_disable (); dst =dst_cache_get (&slwt->cache);
@@ -490,7 +498,9 @@ static int seg6_input_core(struct net *net, struct sock *sk,if (!dst) {ip6_route_input (skb); dst =skb_dst (skb); -if (!dst->error) { + +/* cache only if we don't create a dst reference loop */ +if (!dst->error && lwtst != dst->lwtstate) {local_bh_disable ();dst_cache_set_ip6 (&slwt->cache, dst, &ipv6_hdr (skb)->saddr);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 141/176 net: ipv6: rpl_iptunnel: mitigate 2-realloc issue
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Justin Iurman <[email protected]>
[ Upstream commit 985ec6f5e6235242191370628acb73d7a9f0c0ea ]
This patch mitigates the two-reallocations issue with rpl_iptunnel by providing the dst_entry (in the cache) to the first call to skb_cow_head(). As a result, the very first iteration would still trigger two reallocations (i.e., empty cache), while next iterations would only trigger a single reallocation.
Performance tests before/after applying this patch, which clearly shows there is no impact (it even shows improvement):
- before: https://ibb.co/nQJhqwc
- after: https://ibb.co/4ZvW6wV
Stable-dep-of: 13e55fbaec17 ("net: ipv6: fix dst ref loop on input in rpl lwt")
--- net/ipv6/rpl_iptunnel.c | 46 ++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 21 deletions(-)
net/ipv6/rpl_iptunnel.c +25 -21
@@ -125,7 +125,8 @@ static void rpl_destroy_state(struct lwtunnel_state *lwt) }static int rpl_do_srh_inline (struct sk_buff *skb,const struct rpl_lwt *rlwt, -const struct ipv6_rpl_sr_hdr *srh) +const struct ipv6_rpl_sr_hdr *srh, +struct dst_entry *cache_dst) {struct ipv6_rpl_sr_hdr *isrh, *csrh;const struct ipv6hdr *oldhdr;
@@ -153,7 +154,7 @@ static int rpl_do_srh_inline(struct sk_buff *skb, const struct rpl_lwt *rlwt, hdrlen = ((csrh->hdrlen +1 ) <<3 ); - err =skb_cow_head (skb, hdrlen + skb->mac_len); + err =skb_cow_head (skb, hdrlen +dst_dev_overhead (cache_dst, skb));if (unlikely (err)) {kfree (buf);return err;
@@ -186,7 +187,8 @@ static int rpl_do_srh_inline(struct sk_buff *skb, const struct rpl_lwt *rlwt,return 0 ; } -static int rpl_do_srh (struct sk_buff *skb,const struct rpl_lwt *rlwt) +static int rpl_do_srh (struct sk_buff *skb,const struct rpl_lwt *rlwt, +struct dst_entry *cache_dst) {struct dst_entry *dst =skb_dst (skb);struct rpl_iptunnel_encap *tinfo;
@@ -196,7 +198,7 @@ static int rpl_do_srh(struct sk_buff *skb, const struct rpl_lwt *rlwt) tinfo =rpl_encap_lwtunnel (dst->lwtstate); -return rpl_do_srh_inline (skb, rlwt, tinfo->srh); +return rpl_do_srh_inline (skb, rlwt, tinfo->srh, cache_dst); }static int rpl_output (struct net *net,struct sock *sk,struct sk_buff *skb)
@@ -208,14 +210,14 @@ static int rpl_output(struct net *net, struct sock *sk, struct sk_buff *skb) rlwt =rpl_lwt_lwtunnel (orig_dst->lwtstate); - err =rpl_do_srh (skb, rlwt); -if (unlikely (err)) - goto drop; -local_bh_disable (); dst =dst_cache_get (&rlwt->cache);local_bh_enable (); + err =rpl_do_srh (skb, rlwt, dst); +if (unlikely (err)) + goto drop; +if (unlikely (!dst)) {struct ipv6hdr *hdr =ipv6_hdr (skb);struct flowi6 fl6;
@@ -237,15 +239,15 @@ static int rpl_output(struct net *net, struct sock *sk, struct sk_buff *skb)local_bh_disable ();dst_cache_set_ip6 (&rlwt->cache, dst, &fl6.saddr);local_bh_enable (); + + err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); +if (unlikely (err)) + goto drop; }skb_dst_drop (skb);skb_dst_set (skb, dst); - err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); -if (unlikely (err)) - goto drop; -return dst_output (net, sk, skb); drop:
@@ -262,12 +264,13 @@ static int rpl_input(struct sk_buff *skb) rlwt =rpl_lwt_lwtunnel (orig_dst->lwtstate); - err =rpl_do_srh (skb, rlwt); -if (unlikely (err)) - goto drop; -local_bh_disable (); dst =dst_cache_get (&rlwt->cache); +local_bh_enable (); + + err =rpl_do_srh (skb, rlwt, dst); +if (unlikely (err)) + goto drop;skb_dst_drop (skb);
@@ -275,17 +278,18 @@ static int rpl_input(struct sk_buff *skb)ip6_route_input (skb); dst =skb_dst (skb);if (!dst->error) { +local_bh_disable ();dst_cache_set_ip6 (&rlwt->cache, dst, &ipv6_hdr (skb)->saddr); +local_bh_enable (); } + + err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); +if (unlikely (err)) + goto drop; }else {skb_dst_set (skb, dst); } -local_bh_enable (); - - err =skb_cow_head (skb,LL_RESERVED_SPACE (dst->dev)); -if (unlikely (err)) - goto drop;return dst_input (skb);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 142/176 net: ipv6: fix dst ref loop on input in rpl lwt
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Justin Iurman <[email protected]>
[ Upstream commit 13e55fbaec176119cff68a7e1693b251c8883c5f ]
Prevent a dst ref loop on input in rpl_iptunnel.
--- net/ipv6/rpl_iptunnel.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
net/ipv6/rpl_iptunnel.c +12 -2
@@ -259,10 +259,18 @@ static int rpl_input(struct sk_buff *skb) {struct dst_entry *orig_dst =skb_dst (skb);struct dst_entry *dst =NULL ; +struct lwtunnel_state *lwtst;struct rpl_lwt *rlwt;int err; - rlwt =rpl_lwt_lwtunnel (orig_dst->lwtstate); +/* We cannot dereference "orig_dst" once ip6_route_input() or +* skb_dst_drop() is called. However, in order to detect a dst loop, we +* need the address of its lwtstate. So, save the address of lwtstate +* now and use it later as a comparison. +*/ + lwtst = orig_dst->lwtstate; + + rlwt =rpl_lwt_lwtunnel (lwtst);local_bh_disable (); dst =dst_cache_get (&rlwt->cache);
@@ -277,7 +285,9 @@ static int rpl_input(struct sk_buff *skb)if (!dst) {ip6_route_input (skb); dst =skb_dst (skb); -if (!dst->error) { + +/* cache only if we don't create a dst reference loop */ +if (!dst->error && lwtst != dst->lwtstate) {local_bh_disable ();dst_cache_set_ip6 (&rlwt->cache, dst, &ipv6_hdr (skb)->saddr);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 143/176 mm: Dont pin ZERO_PAGE in pin_user_pages()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit c8070b78751955e59b42457b974bea4a4fe00187 ]
Make pin_user_pages*() leave a ZERO_PAGE unpinned if it extracts a pointer to it from the page tables and make unpin_user_page*() correspondingly ignore a ZERO_PAGE when unpinning. We don't want to risk overrunning a zero page's refcount as we're only allowed ~2 million pins on it - something that userspace can conceivably trigger.
Add a pair of functions to test whether a page or a folio is a ZERO_PAGE.
Stable-dep-of: bddf10d26e6e ("uprobes: Reject the shared zeropage in uprobe_write_opcode()")
--- Documentation/core-api/pin_user_pages.rst | 6 +++++ include/linux/mm.h | 26 +++++++++++++++++-- mm/gup.c | 31 ++++++++++++++++++++++- 3 files changed, 60 insertions(+), 3 deletions(-)
Documentation/core-api/pin_user_pages.rst +6 -0
@@ -113,6 +113,12 @@ pages: This also leads to limitations: there are only 31-10==21 bits available for a counter that increments 10 bits at a time. +* Because of that limitation, special handling is applied to the zero pages + when using FOLL_PIN. We only pretend to pin a zero page - we don't alter its + refcount or pincount at all (it is permanent, so there's no need). The + unpinning functions also don't do anything to a zero page. This is + transparent to the caller. + * Callers must specifically request "dma-pinned tracking of pages". In other words, just calling get_user_pages() will not suffice; a new set of functions, pin_user_page() and related, must be used.
include/linux/mm.h +24 -2
@@ -1610,6 +1610,28 @@ static inline bool page_needs_cow_for_dma(struct vm_area_struct *vma,return page_maybe_dma_pinned (page); } +/** +* is_zero_page - Query if a page is a zero page +* @page: The page to query +* +* This returns true if @page is one of the permanent zero pages. +*/ +static inline bool is_zero_page (const struct page *page) +{ +return is_zero_pfn (page_to_pfn (page)); +} + +/** +* is_zero_folio - Query if a folio is a zero page +* @folio: The folio to query +* +* This returns true if @folio is one of the permanent zero pages. +*/ +static inline bool is_zero_folio (const struct folio *folio) +{ +return is_zero_page (&folio->page); +} +/* MIGRATE_CMA and ZONE_MOVABLE do not allow pin pages */ #ifdef CONFIG_MIGRATION static inline bool is_longterm_pinnable_page (struct page *page)
@@ -1620,8 +1642,8 @@ static inline bool is_longterm_pinnable_page(struct page *page)if (mt ==MIGRATE_CMA || mt ==MIGRATE_ISOLATE )return false;#endif -/* The zero page may always be pinned */ -if (is_zero_pfn (page_to_pfn (page))) +/* The zero page can be "pinned" but gets special handling. */ +if (is_zero_page (page))return true;/* Coherent device memory must always allow eviction. */
mm/gup.c +30 -1
@@ -51,7 +51,8 @@ static inline void sanity_check_pinned_pages(struct page **pages,struct page *page = *pages;struct folio *folio =page_folio (page); -if (!folio_test_anon (folio)) +if (is_zero_page (page) || + !folio_test_anon (folio))continue ;if (!folio_test_large (folio) ||folio_test_hugetlb (folio))VM_BUG_ON_PAGE (!PageAnonExclusive (&folio->page), page);
@@ -128,6 +129,13 @@ struct folio *try_grab_folio(struct page *page, int refs, unsigned int flags)else if (flags &FOLL_PIN ) {struct folio *folio; +/* +* Don't take a pin on the zero page - it's not going anywhere +* and it is used in a *lot* of places. +*/ +if (is_zero_page (page)) +return page_folio (page); +/* * Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a * right zone, so fail and let the caller fall back to the slow
@@ -177,6 +185,8 @@ struct folio *try_grab_folio(struct page *page, int refs, unsigned int flags)static void gup_put_folio (struct folio *folio,int refs,unsigned int flags) {if (flags &FOLL_PIN ) { +if (is_zero_folio (folio)) +return ;node_stat_mod_folio (folio,NR_FOLL_PIN_RELEASED , refs);if (folio_test_large (folio))atomic_sub (refs,folio_pincount_ptr (folio));
@@ -217,6 +227,13 @@ bool __must_check try_grab_page(struct page *page, unsigned int flags)if (flags &FOLL_GET )folio_ref_inc (folio);else if (flags &FOLL_PIN ) { +/* +* Don't take a pin on the zero page - it's not going anywhere +* and it is used in a *lot* of places. +*/ +if (is_zero_page (page)) +return 0 ; +/* * Similar to try_grab_folio(): be sure to *also* * increment the normal page refcount field at least once,
@@ -3149,6 +3166,9 @@ EXPORT_SYMBOL_GPL(get_user_pages_fast);* * FOLL_PIN means that the pages must be released via unpin_user_page(). Please * see Documentation/core-api/pin_user_pages.rst for further details. +* +* Note that if a zero_page is amongst the returned pages, it will not have +* pins in it and unpin_user_page() will not remove pins from it. */ int pin_user_pages_fast (unsigned long start,int nr_pages,unsigned int gup_flags,struct page **pages)
@@ -3225,6 +3245,9 @@ EXPORT_SYMBOL_GPL(pin_user_pages_fast_only);* * FOLL_PIN means that the pages must be released via unpin_user_page(). Please * see Documentation/core-api/pin_user_pages.rst for details. +* +* Note that if a zero_page is amongst the returned pages, it will not have +* pins in it and unpin_user_page*() will not remove pins from it. */ long pin_user_pages_remote(struct mm_struct *mm, unsigned long start, unsigned long nr_pages,
@@ -3260,6 +3283,9 @@ EXPORT_SYMBOL(pin_user_pages_remote);* * FOLL_PIN means that the pages must be released via unpin_user_page(). Please * see Documentation/core-api/pin_user_pages.rst for details. +* +* Note that if a zero_page is amongst the returned pages, it will not have +* pins in it and unpin_user_page*() will not remove pins from it. */ long pin_user_pages(unsigned long start, unsigned long nr_pages, unsigned int gup_flags, struct page **pages,
@@ -3282,6 +3308,9 @@ EXPORT_SYMBOL(pin_user_pages);* pin_user_pages_unlocked() is the FOLL_PIN variant of * get_user_pages_unlocked(). Behavior is the same, except that this one sets * FOLL_PIN and rejects FOLL_GET. +* +* Note that if a zero_page is amongst the returned pages, it will not have +* pins in it and unpin_user_page*() will not remove pins from it. */ long pin_user_pages_unlocked (unsigned long start,unsigned long nr_pages,struct page **pages,unsigned int gup_flags)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 144/176 uprobes: Reject the shared zeropage in uprobe_write_opcode()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tong Tiangen <[email protected]>
[ Upstream commit bddf10d26e6e5114e7415a0e442ec6f51a559468 ]
We triggered the following crash in syzkaller tests:
BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1
The following syzkaller test case can be used to reproduce:
r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8)
write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10)
r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0)
mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)
r5 = userfaultfd(0x80801)
ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20})
r6 = userfaultfd(0x80801)
ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140))
ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})
ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}})
r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)
The cause is that zero pfn is set to the PTE without increasing the RSS count in mfill_atomic_pte_zeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobe_write_opcode()->__replace_page() to unconditional decrease the RSS count and old_folio's refcount.
Therefore, two bugs are introduced:
1. The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count".
2. The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".
There is more, the following warning could also theoretically be triggered:
__replace_page()
-> ...
-> folio_remove_rmap_pte()
-> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after get_user_page_vma_remote().
[ mingo: Cleaned up the changelog ]
--- kernel/events/uprobes.c | 5 +++++ 1 file changed, 5 insertions(+)
kernel/events/uprobes.c +5 -0
@@ -484,6 +484,11 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm,if (ret <=0 ) goto put_old; +if (is_zero_page (old_page)) { + ret = -EINVAL ; + goto put_old; + } +if (WARN (!is_register &&PageCompound (old_page),"uprobe unregister should never work on compound page\n" )) { ret = -EINVAL ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 145/176 io_uring/net: save msg_control for compat
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
[ Upstream commit 6ebf05189dfc6d0d597c99a6448a4d1064439a18 ]
Match the compat part of io_sendmsg_copy_hdr() with its counterpart and save msg_control.
--- io_uring/net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
io_uring/net.c +3 -1
@@ -282,7 +282,9 @@ static int io_sendmsg_copy_hdr(struct io_kiocb *req,if (unlikely (ret))return ret; - return __get_compat_msghdr(&iomsg->msg, &cmsg, NULL); + ret =__get_compat_msghdr (&iomsg->msg, &cmsg,NULL ); + sr->msg_control = iomsg->msg.msg_control_user; + return ret; }#endif
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 146/176 x86/CPU: Fix warm boot hang regression on AMD SC1100 SoC systems
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell Senior <[email protected]>
[ Upstream commit bebe35bb738b573c32a5033499cd59f20293f2a3 ]
I still have some Soekris net4826 in a Community Wireless Network I volunteer with. These devices use an AMD SC1100 SoC. I am running OpenWrt on them, which uses a patched kernel, that naturally has evolved over time. I haven't updated the ones in the field in a number of years (circa 2017), but have one in a test bed, where I have intermittently tried out test builds.
A few years ago, I noticed some trouble, particularly when "warm booting", that is, doing a reboot without removing power, and noticed the device was hanging after the kernel message:
[ 0.081615] Working around Cyrix MediaGX virtual DMA bugs.
If I removed power and then restarted, it would boot fine, continuing through the message above, thusly:
[ 0.081615] Working around Cyrix MediaGX virtual DMA bugs. [ 0.090076] Enable Memory-Write-back mode on Cyrix/NSC processor. [ 0.100000] Enable Memory access reorder on Cyrix/NSC processor. [ 0.100070] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 [ 0.110058] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 [ 0.120037] CPU: NSC Geode(TM) Integrated Processor by National Semi (family: 0x5, model: 0x9, stepping: 0x1) [...]
In order to continue using modern tools, like ssh, to interact with the software on these old devices, I need modern builds of the OpenWrt firmware on the devices. I confirmed that the warm boot hang was still an issue in modern OpenWrt builds (currently using a patched linux v6.6.65).
Last night, I decided it was time to get to the bottom of the warm boot hang, and began bisecting. From preserved builds, I narrowed down the bisection window from late February to late May 2019. During this period, the OpenWrt builds were using 4.14.x. I was able to build using period-correct Ubuntu 18.04.6. After a number of bisection iterations, I identified a kernel bump from 4.14.112 to 4.14.113 as the commit that introduced the warm boot hang.
https://github.com/openwrt/openwrt/commit/07aaa7e3d62ad32767d7067107db64b6ade81537
Looking at the upstream changes in the stable kernel between 4.14.112 and 4.14.113 (tig v4.14.112..v4.14.113), I spotted a likely suspect:
So, I tried reverting just that kernel change on top of the breaking OpenWrt commit, and my warm boot hang went away.
Presumably, the warm boot hang is due to some register not getting cleared in the same way that a loss of power does. That is approximately as much as I understand about the problem.
More poking/prodding and coaching from Jonas Gorski, it looks like this test patch fixes the problem on my board: Tested against v6.6.67 and v4.14.113.
--- arch/x86/kernel/cpu/cyrix.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/cyrix.c +2 -2
@@ -153,8 +153,8 @@ static void geode_configure(void)u8 ccr3;local_irq_save (flags); -/* Suspend on halt power saving and enable #SUSP pin */ -setCx86 (CX86_CCR2 ,getCx86 (CX86_CCR2 ) |0x88 ); +/* Suspend on halt power saving */ +setCx86 (CX86_CCR2 ,getCx86 (CX86_CCR2 ) |0x08 ); ccr3 =getCx86 (CX86_CCR3 );setCx86 (CX86_CCR3 , (ccr3 &0x0f ) |0x10 );/* enable MAPEN */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 147/176 phy: rockchip: naneng-combphy: compatible reset with old DT
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chukun Pan <[email protected]>
[ Upstream commit 3126ea9be66b53e607f87f067641ba724be24181 ]
The device tree of RK3568 did not specify reset-names before. So add fallback to old behaviour to be compatible with old DT.
--- drivers/phy/rockchip/phy-rockchip-naneng-combphy.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/phy/rockchip/phy-rockchip-naneng-combphy.c +4 -1
@@ -299,7 +299,10 @@ static int rockchip_combphy_parse_dt(struct device *dev, struct rockchip_combphy priv->ext_refclk =device_property_present (dev,"rockchip,ext-refclk" ); - priv->phy_rst =devm_reset_control_get (dev,"phy" ); + priv->phy_rst =devm_reset_control_get_exclusive (dev,"phy" ); +/* fallback to old behaviour */ +if (PTR_ERR (priv->phy_rst) == -ENOENT ) + priv->phy_rst =devm_reset_control_array_get_exclusive (dev);if (IS_ERR (priv->phy_rst))return dev_err_probe (dev,PTR_ERR (priv->phy_rst),"failed to get phy reset\n" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 148/176 tracing: Fix bad hist from corrupting named_triggers list
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 6f86bdeab633a56d5c6dccf1a2c5989b6a5e323e upstream.
The following commands causes a crash:
~# cd /sys/kernel/tracing/events/rcu/rcu_callback
~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger
bash: echo: write error: Invalid argument
~# echo 'hist:name=bad:keys=common_pid' > trigger
Because the following occurs:
event_trigger_write() {
trigger_process_regex() {
event_hist_trigger_parse() {
data = event_trigger_alloc(..);
event_trigger_register(.., data) {
cmd_ops->reg(.., data, ..) [hist_register_trigger()] {
data->ops->init() [event_hist_trigger_init()] {
save_named_trigger(name, data) {
list_add(&data->named_list, &named_triggers);
}
}
}
}
ret = create_actions(); (return -EINVAL)
if (ret)
goto out_unreg;
[..]
ret = hist_trigger_enable(data, ...) {
list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)
[..]
out_unreg:
event_hist_unregister(.., data) {
cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] {
list_for_each_entry(iter, &file->triggers, list) {
if (!hist_trigger_match(data, iter, named_data, false)) <- never matches
continue;
[..]
test = iter;
}
if (test && test->ops->free) <<<-- test is NULL
test->ops->free(test) [event_hist_trigger_free()] {
[..]
if (data->name)
del_named_trigger(data) {
list_del(&data->named_list); <<<<-- NEVER gets removed!
}
}
}
}
[..]
kfree(data); <<<-- frees item but it is still on listThe next time a hist with name is registered, it causes an u-a-f bug and the kernel can crash.
Move the code around such that if event_trigger_register() succeeds, the next thing called is hist_trigger_enable() which adds it to the list.
A bunch of actions is called if get_named_trigger_data() returns false. But that doesn't need to be called after event_trigger_register(), so it can be moved up, allowing event_trigger_register() to be called just before hist_trigger_enable() keeping them together and allowing the file->triggers to be properly populated.
--- kernel/trace/trace_events_hist.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-)
kernel/trace/trace_events_hist.c +15 -15
@@ -6551,27 +6551,27 @@ static int event_hist_trigger_parse(struif (existing_hist_update_only (glob, trigger_data, file)) goto out_free; - ret =event_trigger_register (cmd_ops, file, glob, trigger_data); -if (ret <0 ) - goto out_free; +if (!get_named_trigger_data (trigger_data)) { -if (get_named_trigger_data (trigger_data)) - goto enable; + ret =create_actions (hist_data); +if (ret) + goto out_free; - ret =create_actions (hist_data); -if (ret) - goto out_unreg; +if (has_hist_vars (hist_data) || hist_data->n_var_refs) { + ret =save_hist_vars (hist_data); +if (ret) + goto out_free; + } -if (has_hist_vars (hist_data) || hist_data->n_var_refs) { - ret =save_hist_vars (hist_data); + ret =tracing_map_init (hist_data->map);if (ret) - goto out_unreg; + goto out_free; } - ret =tracing_map_init (hist_data->map); -if (ret) - goto out_unreg; -enable: + ret =event_trigger_register (cmd_ops, file, glob, trigger_data); +if (ret <0 ) + goto out_free; + ret =hist_trigger_enable (trigger_data, file);if (ret) goto out_unreg;
Greg Kroah-Hartman
maintainerPATCH 149/176 ftrace: Avoid potential division by zero in function_stat_show()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Kuratov <[email protected]>
commit a1a7eb89ca0b89dc1c326eeee2596f263291aca3 upstream.
Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} produce zero and skip stddev computation in that case.
For now don't care about rec->counter * rec->counter overflow because rec->time * rec->time overflow will likely happen earlier.
--- kernel/trace/ftrace.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-)
kernel/trace/ftrace.c +12 -15
@@ -507,6 +507,7 @@ static int function_stat_show(struct seqstatic struct trace_seq s;unsigned long long avg;unsigned long long stddev; +unsigned long long stddev_denom;#endif mutex_lock (&ftrace_profile_lock);
@@ -528,23 +529,19 @@ static int function_stat_show(struct seq#ifdef CONFIG_FUNCTION_GRAPH_TRACER seq_puts (m," " ); -/* Sample standard deviation (s^2) */ -if (rec->counter <=1 ) - stddev =0 ; -else { -/* -* Apply Welford's method: -* s^2 = 1 / (n * (n-1)) * (n * \Sum (x_i)^2 - (\Sum x_i)^2) -*/ +/* +* Variance formula: +* s^2 = 1 / (n * (n-1)) * (n * \Sum (x_i)^2 - (\Sum x_i)^2) +* Maybe Welford's method is better here? +* Divide only by 1000 for ns^2 -> us^2 conversion. +* trace_print_graph_duration will divide by 1000 again. +*/ + stddev =0 ; + stddev_denom = rec->counter * (rec->counter -1 ) *1000 ; +if (stddev_denom) { stddev = rec->counter * rec->time_squared - rec->time * rec->time; - -/* -* Divide only 1000 for ns^2 -> us^2 conversion. -* trace_print_graph_duration will divide 1000 again. -*/ - stddev =div64_ul (stddev, - rec->counter * (rec->counter -1 ) *1000 ); + stddev =div64_ul (stddev, stddev_denom); }trace_seq_init (&s);
Greg Kroah-Hartman
maintainerPATCH 150/176 ALSA: usb-audio: Re-add sample rate quirk for Pioneer DJM-900NXS2
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Panchenko <[email protected]>
commit 9af3b4f2d879da01192d6168e6c651e7fb5b652d upstream.
Re-add the sample-rate quirk for the Pioneer DJM-900NXS2. This device does not work without setting sample-rate.
--- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+)
sound/usb/quirks.c +1 -0
@@ -1773,6 +1773,7 @@ void snd_usb_set_format_quirk(struct sndcase USB_ID (0x534d ,0x2109 ):/* MacroSilicon MS2109 */ subs->stream_offset_adj =2 ;break ; +case USB_ID (0x2b73 ,0x000a ):/* Pioneer DJM-900NXS2 */ case USB_ID (0x2b73 ,0x0013 ):/* Pioneer DJM-450 */ pioneer_djm_set_format_quirk (subs,0x0082 );break ;
Greg Kroah-Hartman
maintainerPATCH 151/176 perf/x86: Fix low freqency setting issue
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 88ec7eedbbd21cad38707620ad6c48a4e9a87c18 upstream.
Perf doesn't work at low frequencies:
$ perf record -e cpu_core/instructions/ppp -F 120 Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cpu_core/instructions/ppp). "dmesg | grep -i perf" may provide additional information.
The limit_period() check avoids a low sampling period on a counter. It doesn't intend to limit the frequency.
The check in the x86_pmu_hw_config() should be limited to non-freq mode. The attr.sample_period and attr.sample_freq are union. The attr.sample_period should not be used to indicate the frequency mode.
--- arch/x86/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/events/core.c +1 -1
@@ -623,7 +623,7 @@ int x86_pmu_hw_config(struct perf_eventif (event->attr.type == event->pmu->type) event->hw.config |= event->attr.config &X86_RAW_EVENT_MASK ; -if (event->attr.sample_period && x86_pmu.limit_period) { +if (!event->attr.freq && x86_pmu.limit_period) {s64 left = event->attr.sample_period; x86_pmu.limit_period (event, &left);if (left > event->attr.sample_period)
Greg Kroah-Hartman
maintainerPATCH 152/176 perf/core: Fix low freq setting via IOC_PERIOD
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 0d39844150546fa1415127c5fbae26db64070dd3 upstream.
A low attr::freq value cannot be set via IOC_PERIOD on some platforms.
The perf_event_check_period() introduced in:
81ec3f3c4c4d ("perf/x86: Add check_period PMU callback")
was intended to check the period, rather than the frequency. A low frequency may be mistakenly rejected by limit_period().
Fix it.
--- kernel/events/core.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
kernel/events/core.c +9 -8
@@ -5679,14 +5679,15 @@ static int _perf_event_period(struct perif (!value)return -EINVAL ; -if (event->attr.freq && value > sysctl_perf_event_sample_rate) -return -EINVAL ; - -if (perf_event_check_period (event, value)) -return -EINVAL ; - -if (!event->attr.freq && (value & (1ULL <<63 ))) -return -EINVAL ; +if (event->attr.freq) { +if (value > sysctl_perf_event_sample_rate) +return -EINVAL ; + }else { +if (perf_event_check_period (event, value)) +return -EINVAL ; +if (value & (1ULL <<63 )) +return -EINVAL ; + }event_function_call (event, __perf_event_period, &value);
Greg Kroah-Hartman
maintainerPATCH 153/176 drm/amd/display: Disable PSR-SU on eDP panels
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Chung <[email protected]>
commit e8863f8b0316d8ee1e7e5291e8f2f72c91ac967d upstream.
[Why]
PSR-SU may cause some glitching randomly on several panels.
[How]
Temporarily disable the PSR-SU and fallback to PSR1 for all eDP panels.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c +2 -1
@@ -51,7 +51,8 @@ static bool link_supports_psrsu(struct d !link->dpcd_caps.psr_info.psr2_su_y_granularity_cap)return false; -return dc_dmub_check_min_version (dc->ctx->dmub_srv->dmub); +/* Temporarily disable PSR-SU to avoid glitches */ +return false; }/*
Greg Kroah-Hartman
maintainerPATCH 154/176 drm/amd/display: Fix HPD after gpu reset
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Li <[email protected]>
commit 4de141b8b1b7991b607f77e5f4580e1c67c24717 upstream.
[Why]
DC is not using amdgpu_irq_get/put to manage the HPD interrupt refcounts. So when amdgpu_irq_gpu_reset_resume_helper() reprograms all of the IRQs, HPD gets disabled.
[How]
Use amdgpu_irq_get/put() for HPD init/fini in DM in order to sync refcounts
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c +14 -0
@@ -885,6 +885,7 @@ void amdgpu_dm_hpd_init(struct amdgpu_destruct drm_device *dev =adev_to_drm (adev);struct drm_connector *connector;struct drm_connector_list_iter iter; +int i;drm_connector_list_iter_begin (dev, &iter);drm_for_each_connector_iter (connector, &iter) {
@@ -906,6 +907,12 @@ void amdgpu_dm_hpd_init(struct amdgpu_de } }drm_connector_list_iter_end (&iter); + +/* Update reference counts for HPDs */ +for (i =DC_IRQ_SOURCE_HPD1 ; i <= adev->mode_info.num_hpd; i++) { +if (amdgpu_irq_get (adev, &adev->hpd_irq, i -DC_IRQ_SOURCE_HPD1 )) +drm_err (dev,"DM_IRQ: Failed get HPD for source=%d)!\n" , i); + } }/**
@@ -921,6 +928,7 @@ void amdgpu_dm_hpd_fini(struct amdgpu_destruct drm_device *dev =adev_to_drm (adev);struct drm_connector *connector;struct drm_connector_list_iter iter; +int i;drm_connector_list_iter_begin (dev, &iter);drm_for_each_connector_iter (connector, &iter) {
@@ -941,4 +949,10 @@ void amdgpu_dm_hpd_fini(struct amdgpu_de } }drm_connector_list_iter_end (&iter); + +/* Update reference counts for HPDs */ +for (i =DC_IRQ_SOURCE_HPD1 ; i <= adev->mode_info.num_hpd; i++) { +if (amdgpu_irq_put (adev, &adev->hpd_irq, i -DC_IRQ_SOURCE_HPD1 )) +drm_err (dev,"DM_IRQ: Failed put HPD for source=%d!\n" , i); + } }
Greg Kroah-Hartman
maintainerPATCH 155/176 i2c: npcm: disable interrupt enable bit before devm_request_irq
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyrone Ting <[email protected]>
commit dd1998e243f5fa25d348a384ba0b6c84d980f2b2 upstream.
The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset.
Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the kernel booting process after the bmc machine is doing a warm rebooting.
The continuous triggering is stopped by the soft lockup watchdog timer.
Disable the interrupt enable bit in the i2c module before calling devm_request_irq to fix this issue since the i2c relative status bit is read-only.
Here is the soft lockup log.
[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] [ 28.183351] Modules linked in: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Rebooting in 20 seconds..
--- drivers/i2c/busses/i2c-npcm7xx.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/i2c/busses/i2c-npcm7xx.c +7 -0
@@ -2335,6 +2335,13 @@ static int npcm_i2c_probe_bus(struct plaif (irq <0 )return irq; +/* +* Disable the interrupt to avoid the interrupt handler being triggered +* incorrectly by the asynchronous interrupt status since the machine +* might do a warm reset during the last smbus/i2c transfer session. +*/ +npcm_i2c_int_enable (bus, false); + ret =devm_request_irq (bus->dev, irq, npcm_i2c_bus_irq,0 ,dev_name (bus->dev), bus);if (ret)
Greg Kroah-Hartman
maintainerPATCH 156/176 usbnet: gl620a: fix endpoint checking in genelink_bind()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikita Zhandarovich <[email protected]>
commit 1cf9631d836b289bd5490776551961c883ae8a4f upstream.
Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch.
Fix the issue by resorting to a usbnet utility function usbnet_get_endpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing.
[1] Syzbot report:
usb 5-1: Manufacturer: syz
usb 5-1: SerialNumber: syz
usb 5-1: config 0 descriptor??
gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...
------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
--- drivers/net/usb/gl620a.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/net/usb/gl620a.c +1 -3
@@ -179,9 +179,7 @@ static int genelink_bind(struct usbnet * { dev->hard_mtu =GL_RCV_BUF_SIZE ; dev->net->hard_header_len +=4 ; - dev->in =usb_rcvbulkpipe (dev->udev, dev->driver_info->in); - dev->out =usb_sndbulkpipe (dev->udev, dev->driver_info->out); -return 0 ; +return usbnet_get_endpoints (dev, intf); }static const struct driver_info genelink_info = {
Greg Kroah-Hartman
maintainerPATCH 157/176 net: enetc: fix the off-by-one issue in enetc_map_tx_buffs()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
commit 39ab773e4c120f7f98d759415ccc2aca706bbc10 upstream.
When a DMA mapping error occurs while processing skb frags, it will free one more tx_swbd than expected, so fix this off-by-one issue.
--- drivers/net/ethernet/freescale/enetc/enetc.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc.c +19 -7
@@ -123,6 +123,24 @@ static int enetc_ptp_parse(struct sk_bufreturn 0 ; } +/** +* enetc_unwind_tx_frame() - Unwind the DMA mappings of a multi-buffer Tx frame +* @tx_ring: Pointer to the Tx ring on which the buffer descriptors are located +* @count: Number of Tx buffer descriptors which need to be unmapped +* @i: Index of the last successfully mapped Tx buffer descriptor +*/ +static void enetc_unwind_tx_frame (struct enetc_bdr *tx_ring,int count,int i) +{ +while (count--) { +struct enetc_tx_swbd *tx_swbd = &tx_ring->tx_swbd[i]; + +enetc_free_tx_frame (tx_ring, tx_swbd); +if (i ==0 ) + i = tx_ring->bd_count; + i--; + } +} +static int enetc_map_tx_buffs (struct enetc_bdr *tx_ring,struct sk_buff *skb) {bool do_vlan, do_onestep_tstamp = false, do_twostep_tstamp = false;
@@ -306,13 +324,7 @@ static int enetc_map_tx_buffs(struct ene dma_err:dev_err (tx_ring->dev,"DMA map error" ); -do { - tx_swbd = &tx_ring->tx_swbd[i]; -enetc_free_tx_frame (tx_ring, tx_swbd); -if (i ==0 ) - i = tx_ring->bd_count; - i--; - }while (count--); +enetc_unwind_tx_frame (tx_ring, count, i);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 158/176 net: enetc: keep track of correct Tx BD count in enetc_map_tx_tso_buffs()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
commit da291996b16ebd10626d4b20288327b743aff110 upstream.
When creating a TSO header, if the skb is VLAN tagged, the extended BD will be used and the 'count' should be increased by 2 instead of 1. Otherwise, when an error occurs, less tx_swbd will be freed than the actual number.
--- drivers/net/ethernet/freescale/enetc/enetc.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc.c +10 -6
@@ -329,14 +329,15 @@ dma_err:return 0 ; } -static void enetc_map_tx_tso_hdr (struct enetc_bdr *tx_ring,struct sk_buff *skb, -struct enetc_tx_swbd *tx_swbd, -union enetc_tx_bd *txbd,int *i,int hdr_len, -int data_len) +static int enetc_map_tx_tso_hdr (struct enetc_bdr *tx_ring,struct sk_buff *skb, +struct enetc_tx_swbd *tx_swbd, +union enetc_tx_bd *txbd,int *i,int hdr_len, +int data_len) {union enetc_tx_bd txbd_tmp;u8 flags =0 , e_flags =0 ;dma_addr_t addr; +int count =1 ;enetc_clear_tx_bd (&txbd_tmp); addr = tx_ring->tso_headers_dma + *i *TSO_HEADER_SIZE ;
@@ -379,7 +380,10 @@ static void enetc_map_tx_tso_hdr(struct/* Write the BD */ txbd_tmp.ext.e_flags = e_flags; *txbd = txbd_tmp; + count++; } + +return count; } static int enetc_map_tx_tso_data(struct enetc_bdr *tx_ring, struct sk_buff *skb,
@@ -511,9 +515,9 @@ static int enetc_map_tx_tso_buffs(struct/* compute the csum over the L4 header */ csum =enetc_tso_hdr_csum (&tso, skb, hdr, hdr_len, &pos); -enetc_map_tx_tso_hdr (tx_ring, skb, tx_swbd, txbd, &i, hdr_len, data_len); + count +=enetc_map_tx_tso_hdr (tx_ring, skb, tx_swbd, txbd, + &i, hdr_len, data_len); bd_data_num =0 ; - count++;while (data_len >0 ) {int size;
Greg Kroah-Hartman
maintainerPATCH 159/176 net: enetc: update UDP checksum when updating originTimestamp field
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
commit bbcbc906ab7b5834c1219cd17a38d78dba904aa0 upstream.
There is an issue with one-step timestamp based on UDP/IP. The peer will discard the sync packet because of the wrong UDP checksum. For ENETC v1, the software needs to update the UDP checksum when updating the originTimestamp field, so that the hardware can correctly update the UDP checksum when updating the correction field. Otherwise, the UDP checksum in the sync packet will be wrong.
--- drivers/net/ethernet/freescale/enetc/enetc.c | 41 ++++++++++++++++++++++----- 1 file changed, 34 insertions(+), 7 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc.c +34 -7
@@ -231,9 +231,11 @@ static int enetc_map_tx_buffs(struct ene }if (do_onestep_tstamp) { -u32 lo, hi, val; -u64 sec, nsec; +__be32 new_sec_l, new_nsec; +u32 lo, hi, nsec, val; +__be16 new_sec_h;u8 *data; +u64 sec; lo =enetc_rd_hot (hw,ENETC_SICTR0 ); hi =enetc_rd_hot (hw,ENETC_SICTR1 );
@@ -247,13 +249,38 @@ static int enetc_map_tx_buffs(struct ene/* Update originTimestamp field of Sync packet * - 48 bits seconds field * - 32 bits nanseconds field +* +* In addition, the UDP checksum needs to be updated +* by software after updating originTimestamp field, +* otherwise the hardware will calculate the wrong +* checksum when updating the correction field and +* update it to the packet. */ data =skb_mac_header (skb); - *(__be16 *)(data + offset2) = -htons ((sec >>32 ) &0xffff ); - *(__be32 *)(data + offset2 +2 ) = -htonl (sec &0xffffffff ); - *(__be32 *)(data + offset2 +6 ) =htonl (nsec); + new_sec_h =htons ((sec >>32 ) &0xffff ); + new_sec_l =htonl (sec &0xffffffff ); + new_nsec =htonl (nsec); +if (udp) { +struct udphdr *uh =udp_hdr (skb); +__be32 old_sec_l, old_nsec; +__be16 old_sec_h; + + old_sec_h = *(__be16 *)(data + offset2); +inet_proto_csum_replace2 (&uh->check, skb, old_sec_h, + new_sec_h, false); + + old_sec_l = *(__be32 *)(data + offset2 +2 ); +inet_proto_csum_replace4 (&uh->check, skb, old_sec_l, + new_sec_l, false); + + old_nsec = *(__be32 *)(data + offset2 +6 ); +inet_proto_csum_replace4 (&uh->check, skb, old_nsec, + new_nsec, false); + } + + *(__be16 *)(data + offset2) = new_sec_h; + *(__be32 *)(data + offset2 +2 ) = new_sec_l; + *(__be32 *)(data + offset2 +6 ) = new_nsec;/* Configure single-step register */ val =ENETC_PM0_SINGLE_STEP_EN ;
Greg Kroah-Hartman
maintainerPATCH 160/176 net: enetc: correct the xdp_tx statistics
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
commit 432a2cb3ee97a7c6ea578888fe81baad035b9307 upstream.
The 'xdp_tx' is used to count the number of XDP_TX frames sent, not the number of Tx BDs.
--- drivers/net/ethernet/freescale/enetc/enetc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/freescale/enetc/enetc.c +1 -1
@@ -1624,7 +1624,7 @@ static int enetc_clean_rx_ring_xdp(strucenetc_xdp_drop (rx_ring, orig_i, i); tx_ring->stats.xdp_tx_drops++; }else { - tx_ring->stats.xdp_tx += xdp_tx_bd_cnt; + tx_ring->stats.xdp_tx++; rx_ring->xdp.xdp_tx_in_flight += xdp_tx_bd_cnt; xdp_tx_frm_cnt++;/* The XDP_TX enqueue was successful, so we
Greg Kroah-Hartman
maintainerPATCH 161/176 net: enetc: fix the off-by-one issue in enetc_map_tx_tso_buffs()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
commit 249df695c3ffe8c8d36d46c2580ce72410976f96 upstream.
There is an off-by-one issue for the err_chained_bd path, it will free one more tx_swbd than expected. But there is no such issue for the err_map_data path. To fix this off-by-one issue and make the two error handling consistent, the increment of 'i' and 'count' remain in sync and enetc_unwind_tx_frame() is called for error handling.
--- drivers/net/ethernet/freescale/enetc/enetc.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc.c +7 -8
@@ -568,8 +568,13 @@ static int enetc_map_tx_tso_buffs(struct err =enetc_map_tx_tso_data (tx_ring, skb, tx_swbd, txbd, tso.data, size, size == data_len); -if (err) +if (err) { +if (i ==0 ) + i = tx_ring->bd_count; + i--; + goto err_map_data; + } data_len -= size; count++;
@@ -598,13 +603,7 @@ err_map_data:dev_err (tx_ring->dev,"DMA map error" ); err_chained_bd: -do { - tx_swbd = &tx_ring->tx_swbd[i]; -enetc_free_tx_frame (tx_ring, tx_swbd); -if (i ==0 ) - i = tx_ring->bd_count; - i--; - }while (count--); +enetc_unwind_tx_frame (tx_ring, count, i);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 162/176 phy: tegra: xusb: reset VBUS & ID OVERRIDE
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: BH Hsieh <[email protected]>
commit 55f1a5f7c97c3c92ba469e16991a09274410ceb7 upstream.
Observed VBUS_OVERRIDE & ID_OVERRIDE might be programmed with unexpected value prior to XUSB PADCTL driver, this could also occur in virtualization scenario.
For example, UEFI firmware programs ID_OVERRIDE=GROUNDED to set a type-c port to host mode and keeps the value to kernel. If the type-c port is connected a usb host, below errors can be observed right after usb host mode driver gets probed. The errors would keep until usb role class driver detects the type-c port as device mode and notifies usb device mode driver to set both ID_OVERRIDE and VBUS_OVERRIDE to correct value by XUSB PADCTL driver.
[ 173.765814] usb usb3-port2: Cannot enable. Maybe the USB cable is bad? [ 173.765837] usb usb3-port2: config error
Taking virtualization into account, asserting XUSB PADCTL reset would break XUSB functions used by other guest OS, hence only reset VBUS & ID OVERRIDE of the port in utmi_phy_init.
--- drivers/phy/tegra/xusb-tegra186.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/phy/tegra/xusb-tegra186.c +11 -0
@@ -900,6 +900,7 @@ static int tegra186_utmi_phy_exit(structunsigned int index = lane->index;struct device *dev = padctl->dev;int err; +u32 reg; port =tegra_xusb_find_usb2_port (padctl, index);if (!port) {
@@ -907,6 +908,16 @@ static int tegra186_utmi_phy_exit(structreturn -ENODEV ; } +if (port->mode ==USB_DR_MODE_OTG || + port->mode ==USB_DR_MODE_PERIPHERAL ) { +/* reset VBUS&ID OVERRIDE */ + reg =padctl_readl (padctl,USB2_VBUS_ID ); + reg &= ~VBUS_OVERRIDE ; + reg &= ~ID_OVERRIDE (~0 ); + reg |=ID_OVERRIDE_FLOATING ; +padctl_writel (padctl, reg,USB2_VBUS_ID ); + } +if (port->supply && port->mode ==USB_DR_MODE_HOST ) { err =regulator_disable (port->supply);if (err) {
Greg Kroah-Hartman
maintainerPATCH 163/176 phy: exynos5-usbdrd: fix MPLL_MULTIPLIER and SSC_REFCLKSEL masks in refclk
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kaustabh Chakraborty <[email protected]>
commit e2158c953c973adb49383ddea2504faf08d375b7 upstream.
In exynos5_usbdrd_{pipe3,utmi}_set_refclk(), the masks PHYCLKRST_MPLL_MULTIPLIER_MASK and PHYCLKRST_SSC_REFCLKSEL_MASK are not inverted when applied to the register values. Fix it.
--- drivers/phy/samsung/phy-exynos5-usbdrd.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/phy/samsung/phy-exynos5-usbdrd.c +6 -6
@@ -288,9 +288,9 @@ exynos5_usbdrd_pipe3_set_refclk(struct p reg |=PHYCLKRST_REFCLKSEL_EXT_REFCLK ;/* FSEL settings corresponding to reference clock */ - reg &= ~PHYCLKRST_FSEL_PIPE_MASK | -PHYCLKRST_MPLL_MULTIPLIER_MASK | -PHYCLKRST_SSC_REFCLKSEL_MASK ; + reg &= ~(PHYCLKRST_FSEL_PIPE_MASK | +PHYCLKRST_MPLL_MULTIPLIER_MASK | +PHYCLKRST_SSC_REFCLKSEL_MASK );switch (phy_drd->extrefclk) {case EXYNOS5_FSEL_50MHZ : reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
@@ -332,9 +332,9 @@ exynos5_usbdrd_utmi_set_refclk(struct ph reg &= ~PHYCLKRST_REFCLKSEL_MASK ; reg |=PHYCLKRST_REFCLKSEL_EXT_REFCLK ; - reg &= ~PHYCLKRST_FSEL_UTMI_MASK | -PHYCLKRST_MPLL_MULTIPLIER_MASK | -PHYCLKRST_SSC_REFCLKSEL_MASK ; + reg &= ~(PHYCLKRST_FSEL_UTMI_MASK | +PHYCLKRST_MPLL_MULTIPLIER_MASK | +PHYCLKRST_SSC_REFCLKSEL_MASK ); reg |=PHYCLKRST_FSEL (phy_drd->extrefclk);return reg;
Greg Kroah-Hartman
maintainerPATCH 164/176 mptcp: always handle address removal under msk socket lock
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit f865c24bc55158313d5779fc81116023a6940ca3 upstream.
Syzkaller reported a lockdep splat in the PM control path:
WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088
Indeed the PM can try to send a RM_ADDR over a msk without acquiring first the msk socket lock.
The bugged code-path comes from an early optimization: when there are no subflows, the PM should (usually) not send RM_ADDR notifications.
The above statement is incorrect, as without locks another process could concurrent create a new subflow and cause the RM_ADDR generation.
Additionally the supposed optimization is not very effective even performance-wise, as most mptcp sockets should have at least one
subflow: the MPC one.
Address the issue removing the buggy code path, the existing "slow-path" will handle correctly even the edge case.
--- net/mptcp/pm_netlink.c | 5 ----- 1 file changed, 5 deletions(-)
net/mptcp/pm_netlink.c +0 -5
@@ -1554,11 +1554,6 @@ static int mptcp_nl_remove_subflow_and_sif (mptcp_pm_is_userspace (msk)) goto next; -if (list_empty (&msk->conn_list)) { -mptcp_pm_remove_anno_addr (msk, addr, false); - goto next; - } -lock_sock (sk); remove_subflow =lookup_subflow_by_saddr (&msk->conn_list, addr); mptcp_pm_remove_anno_addr(msk, addr, remove_subflow &&
Greg Kroah-Hartman
maintainerPATCH 165/176 mptcp: reset when MPTCP opts are dropped after join
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 8668860b0ad32a13fcd6c94a0995b7aa7638c9ef upstream.
Before this patch, if the checksum was not used, the subflow was only reset if map_data_len was != 0. If there were no MPTCP options or an invalid mapping, map_data_len was not set to the data len, and then the subflow was not reset as it should have been, leaving the MPTCP connection in a wrong fallback mode.
This map_data_len condition has been introduced to handle the reception of the infinite mapping. Instead, a new dedicated mapping error could have been returned and treated as a special case. However, the commit 31bf11de146c ("mptcp: introduce MAPPING_BAD_CSUM") has been introduced by Paolo Abeni soon after, and backported later on to stable. It better handle the csum case, and it means the exception for valid_csum_seen in subflow_can_fallback(), plus this one for the infinite mapping in subflow_check_data_avail(), are no longer needed.
In other words, the code can be simplified there: a fallback should only be done if msk->allow_infinite_fallback is set. This boolean is set to false once MPTCP-specific operations acting on the whole MPTCP connection vs the initial path have been done, e.g. a second path has been created, or an MPTCP re-injection -- yes, possible even with a single subflow. The subflow_can_fallback() helper can then be dropped, and replaced by this single condition.
This also makes the code clearer: a fallback should only be done if it is possible to do so.
While at it, no need to set map_data_len to 0 in get_mapping_status() for the infinite mapping case: it will be set to skb->len just after, at the end of subflow_check_data_avail(), and not read in between.
--- net/mptcp/subflow.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-)
net/mptcp/subflow.c +1 -14
@@ -1020,7 +1020,6 @@ static enum mapping_status get_mapping_sif (data_len ==0 ) {pr_debug ("infinite mapping received\n" );MPTCP_INC_STATS (sock_net (ssk),MPTCP_MIB_INFINITEMAPRX ); - subflow->map_data_len =0 ;return MAPPING_INVALID ; }
@@ -1162,18 +1161,6 @@ static void subflow_sched_work_if_closedmptcp_schedule_work (sk); } -static bool subflow_can_fallback (struct mptcp_subflow_context *subflow) -{ -struct mptcp_sock *msk =mptcp_sk (subflow->conn); - -if (subflow->mp_join) -return false; -else if (READ_ONCE (msk->csum_enabled)) -return !subflow->valid_csum_seen; -else -return READ_ONCE (msk->allow_infinite_fallback); -} -static void mptcp_subflow_fail (struct mptcp_sock *msk,struct sock *ssk) {struct mptcp_subflow_context *subflow =mptcp_subflow_ctx (ssk);
@@ -1277,7 +1264,7 @@ fallback:return true; } -if (!subflow_can_fallback (subflow) && subflow->map_data_len) { +if (!READ_ONCE (msk->allow_infinite_fallback)) {/* fatal protocol error, close the socket. * subflow_error_report() will introduce the appropriate barriers */
Greg Kroah-Hartman
maintainerPATCH 166/176 vmlinux.lds: Ensure that const vars with relocations are mapped R/O
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <[email protected]>
commit 68f3ea7ee199ef77551e090dfef5a49046ea8443 upstream.
In the kernel, there are architectures (x86, arm64) that perform boot-time relocation (for KASLR) without relying on PIE codegen. In this case, all const global objects are emitted into .rodata, including const objects with fields that will be fixed up by the boot-time relocation code. This implies that .rodata (and .text in some cases) need to be writable at boot, but they will usually be mapped read-only as soon as the boot completes.
When using PIE codegen, the compiler will emit const global objects into .data.rel.ro rather than .rodata if the object contains fields that need such fixups at boot-time. This permits the linker to annotate such regions as requiring read-write access only at load time, but not at execution time (in user space), while keeping .rodata truly const (in user space, this is important for reducing the CoW footprint of dynamic executables).
This distinction does not matter for the kernel, but it does imply that const data will end up in writable memory if the .data.rel.ro sections are not treated in a special way, as they will end up in the writable .data segment by default.
So emit .data.rel.ro into the .rodata segment.
--- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/asm-generic/vmlinux.lds.h +1 -1
@@ -461,7 +461,7 @@ . = ALIGN((align)); \ .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ __start_rodata = .; \ - *(.rodata) *(.rodata.*) \ + *(.rodata) *(.rodata.*) *(.data.rel.ro*) \ SCHED_DATA \RO_AFTER_INIT_DATA /* Read only after init */ \ . = ALIGN(8); \
Greg Kroah-Hartman
maintainerPATCH 167/176 sched/core: Prevent rescheduling when interrupts are disabled
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 82c387ef7568c0d96a918a5a78d9cad6256cfa15 upstream.
David reported a warning observed while loop testing kexec jump:
Interrupts enabled after irqrouter_resume+0x0/0x50
WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180
The corresponding interrupt flag trace:
hardirqs last enabled at (15573): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [<ffffffffa8281b73>] __up_console_sem+0x63/0x90
That means __up_console_sem() was invoked with interrupts enabled. Further instrumentation revealed that in the interrupt disabled section of kexec jump one of the syscore_suspend() callbacks woke up a task, which set the NEED_RESCHED flag. A later callback in the resume path invoked cond_resched() which in turn led to the invocation of the scheduler:
__cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180
This is a long standing problem, which probably got more visible with the recent printk changes. Something does a task wakeup and the scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and invokes schedule() from a completely bogus context. The scheduler enables interrupts after context switching, which causes the above warning at the end.
Quite some of the code paths in syscore_suspend()/resume() can result in triggering a wakeup with the exactly same consequences. They might not have done so yet, but as they share a lot of code with normal operations it's just a question of time.
The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling models. Full preemption is not affected as cond_resched() is disabled and the preemption check preemptible() takes the interrupt disabled flag into account.
Cure the problem by adding a corresponding check into cond_resched().
--- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/core.c +1 -1
@@ -8369,7 +8369,7 @@ SYSCALL_DEFINE0(sched_yield)#if !defined(CONFIG_PREEMPTION ) || defined(CONFIG_PREEMPT_DYNAMIC ) int __sched __cond_resched(void) { -if (should_resched (0 )) { +if (should_resched (0 ) && !irqs_disabled ()) {preempt_schedule_common ();return 1 ; }
Greg Kroah-Hartman
maintainerPATCH 168/176 riscv/futex: sign extend compare value in atomic cmpxchg
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Schwab <[email protected]>
commit 599c44cd21f4967774e0acf58f734009be4aea9a upstream.
Make sure the compare value in the lr/sc loop is sign extended to match what lr.w does. Fortunately, due to the compiler keeping the register contents sign extended anyway the lack of the explicit extension didn't result in wrong code so far, but this cannot be relied upon.
--- arch/riscv/include/asm/futex.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/futex.h +1 -1
@@ -93,7 +93,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, _ASM_EXTABLE_UACCESS_ERR(1b, 3b, %[r]) \ _ASM_EXTABLE_UACCESS_ERR(2b, 3b, %[r]) \ : [r] "+r" (ret), [v] "=&r" (val), [u] "+m" (*uaddr), [t] "=&r" (tmp) - : [ov] "Jr" (oldval), [nv] "Jr" (newval) + : [ov] "Jr" ((long)(int)oldval), [nv] "Jr" (newval) : "memory"); __disable_user_access();
Greg Kroah-Hartman
maintainerPATCH 169/176 drm/amd/display: fixed integer types and null check locations
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sohaib Nadeem <[email protected]>
commit 0484e05d048b66d01d1f3c1d2306010bb57d8738 upstream.
[why]:
issues fixed:
- comparison with wider integer type in loop condition which can cause infinite loops
- pointer dereference before null check
[ delete changes made in drivers/gpu/drm/amd/display/dc/link/link_validation.c
for this file is not present in linux-6.1.y ]
--- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +10 -6
@@ -1862,19 +1862,21 @@ static enum bp_result get_firmware_info_/* Vega12 */ smu_info_v3_2 = GET_IMAGE(struct atom_smu_info_v3_2,DATA_TABLES (smu_info)); -DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , smu_info_v3_2->gpuclk_ss_percentage);if (!smu_info_v3_2)return BP_RESULT_BADBIOSTABLE ; +DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , smu_info_v3_2->gpuclk_ss_percentage); + info->default_engine_clk = smu_info_v3_2->bootup_dcefclk_10khz *10 ; }else if (revision.minor ==3 ) {/* Vega20 */ smu_info_v3_3 = GET_IMAGE(struct atom_smu_info_v3_3,DATA_TABLES (smu_info)); -DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , smu_info_v3_3->gpuclk_ss_percentage);if (!smu_info_v3_3)return BP_RESULT_BADBIOSTABLE ; +DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , smu_info_v3_3->gpuclk_ss_percentage); + info->default_engine_clk = smu_info_v3_3->bootup_dcefclk_10khz *10 ; }
@@ -2439,10 +2441,11 @@ static enum bp_result get_integrated_inf info_v11 = GET_IMAGE(struct atom_integrated_system_info_v1_11,DATA_TABLES (integratedsysteminfo)); -DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , info_v11->gpuclk_ss_percentage);if (info_v11 ==NULL )return BP_RESULT_BADBIOSTABLE ; +DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , info_v11->gpuclk_ss_percentage); + info->gpu_cap_info =le32_to_cpu (info_v11->gpucapinfo);/*
@@ -2654,11 +2657,12 @@ static enum bp_result get_integrated_inf info_v2_1 = GET_IMAGE(struct atom_integrated_system_info_v2_1,DATA_TABLES (integratedsysteminfo)); -DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , info_v2_1->gpuclk_ss_percentage);if (info_v2_1 ==NULL )return BP_RESULT_BADBIOSTABLE ; +DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , info_v2_1->gpuclk_ss_percentage); + info->gpu_cap_info =le32_to_cpu (info_v2_1->gpucapinfo);/*
@@ -2816,11 +2820,11 @@ static enum bp_result get_integrated_inf info_v2_2 = GET_IMAGE(struct atom_integrated_system_info_v2_2,DATA_TABLES (integratedsysteminfo)); -DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , info_v2_2->gpuclk_ss_percentage); -if (info_v2_2 ==NULL )return BP_RESULT_BADBIOSTABLE ; +DC_LOG_BIOS ("gpuclk_ss_percentage (unit of 0.001 percent): %d\n" , info_v2_2->gpuclk_ss_percentage); + info->gpu_cap_info =le32_to_cpu (info_v2_2->gpucapinfo);/*
Greg Kroah-Hartman
maintainerPATCH 170/176 amdgpu/pm/legacy: fix suspend/resume issues
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: chr[] <[email protected]>
commit 91dcc66b34beb72dde8412421bdc1b4cd40e4fb8 upstream.
resume and irq handler happily races in set_power_state()
* amdgpu_legacy_dpm_compute_clocks() needs lock
* protect irq work handler
* fix dpm_enabled usage
v2: fix clang build, integrate Lijo's comments (Alex)
--- drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c | 25 ++++++++++++++++++------ drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c | 8 +++++-- drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 26 +++++++++++++++++++------ 3 files changed, 45 insertions(+), 14 deletions(-)
drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c +19 -6
@@ -3056,6 +3056,7 @@ static int kv_dpm_hw_init(void *handle)if (!amdgpu_dpm)return 0 ; +mutex_lock (&adev->pm.mutex);kv_dpm_setup_asic (adev); ret =kv_dpm_enable (adev);if (ret)
@@ -3063,6 +3064,8 @@ static int kv_dpm_hw_init(void *handle)else adev->pm.dpm_enabled = true;amdgpu_legacy_dpm_compute_clocks (adev); +mutex_unlock (&adev->pm.mutex); +return ret; }
@@ -3080,32 +3083,42 @@ static int kv_dpm_suspend(void *handle) {struct amdgpu_device *adev = (struct amdgpu_device *)handle; +cancel_work_sync (&adev->pm.dpm.thermal.work); +if (adev->pm.dpm_enabled) { +mutex_lock (&adev->pm.mutex); + adev->pm.dpm_enabled = false;/* disable dpm */ kv_dpm_disable (adev);/* reset the power state */ adev->pm.dpm.current_ps = adev->pm.dpm.requested_ps = adev->pm.dpm.boot_ps; +mutex_unlock (&adev->pm.mutex); }return 0 ; }static int kv_dpm_resume (void *handle) { -int ret; +int ret =0 ;struct amdgpu_device *adev = (struct amdgpu_device *)handle; -if (adev->pm.dpm_enabled) { +if (!amdgpu_dpm) +return 0 ; + +if (!adev->pm.dpm_enabled) { +mutex_lock (&adev->pm.mutex);/* asic init will reset to the boot state */ kv_dpm_setup_asic (adev); ret =kv_dpm_enable (adev); -if (ret) +if (ret) { adev->pm.dpm_enabled = false; -else + }else { adev->pm.dpm_enabled = true; -if (adev->pm.dpm_enabled)amdgpu_legacy_dpm_compute_clocks (adev); + } +mutex_unlock (&adev->pm.mutex); } -return 0 ; +return ret; }static bool kv_dpm_is_idle (void *handle)
drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c +6 -2
@@ -1018,9 +1018,12 @@ void amdgpu_dpm_thermal_work_handler(strenum amd_pm_state_type dpm_state =POWER_STATE_TYPE_INTERNAL_THERMAL ;int temp, size =sizeof (temp); -if (!adev->pm.dpm_enabled) -return ; +mutex_lock (&adev->pm.mutex); +if (!adev->pm.dpm_enabled) { +mutex_unlock (&adev->pm.mutex); +return ; + } if (!pp_funcs->read_sensor(adev->powerplay.pp_handle, AMDGPU_PP_SENSOR_GPU_TEMP, (void *)&temp,
@@ -1042,4 +1045,5 @@ void amdgpu_dpm_thermal_work_handler(str adev->pm.dpm.state = dpm_state;amdgpu_legacy_dpm_compute_clocks (adev->powerplay.pp_handle); +mutex_unlock (&adev->pm.mutex); }
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c +20 -6
@@ -7796,6 +7796,7 @@ static int si_dpm_hw_init(void *handle)if (!amdgpu_dpm)return 0 ; +mutex_lock (&adev->pm.mutex);si_dpm_setup_asic (adev); ret =si_dpm_enable (adev);if (ret)
@@ -7803,6 +7804,7 @@ static int si_dpm_hw_init(void *handle)else adev->pm.dpm_enabled = true;amdgpu_legacy_dpm_compute_clocks (adev); +mutex_unlock (&adev->pm.mutex);return ret; }
@@ -7820,32 +7822,44 @@ static int si_dpm_suspend(void *handle) {struct amdgpu_device *adev = (struct amdgpu_device *)handle; +cancel_work_sync (&adev->pm.dpm.thermal.work); +if (adev->pm.dpm_enabled) { +mutex_lock (&adev->pm.mutex); + adev->pm.dpm_enabled = false;/* disable dpm */ si_dpm_disable (adev);/* reset the power state */ adev->pm.dpm.current_ps = adev->pm.dpm.requested_ps = adev->pm.dpm.boot_ps; +mutex_unlock (&adev->pm.mutex); } +return 0 ; }static int si_dpm_resume (void *handle) { -int ret; +int ret =0 ;struct amdgpu_device *adev = (struct amdgpu_device *)handle; -if (adev->pm.dpm_enabled) { +if (!amdgpu_dpm) +return 0 ; + +if (!adev->pm.dpm_enabled) {/* asic init will reset to the boot state */ +mutex_lock (&adev->pm.mutex);si_dpm_setup_asic (adev); ret =si_dpm_enable (adev); -if (ret) +if (ret) { adev->pm.dpm_enabled = false; -else + }else { adev->pm.dpm_enabled = true; -if (adev->pm.dpm_enabled)amdgpu_legacy_dpm_compute_clocks (adev); + } +mutex_unlock (&adev->pm.mutex); } -return 0 ; + +return ret; }static bool si_dpm_is_idle (void *handle)
Greg Kroah-Hartman
maintainerPATCH 171/176 intel_idle: Handle older CPUs, which stop the TSC in deeper C states, correctly
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit c157d351460bcf202970e97e611cb6b54a3dd4a4 upstream.
The Intel idle driver is preferred over the ACPI processor idle driver, but fails to implement the work around for Core2 generation CPUs, where the TSC stops in C2 and deeper C-states. This causes stalls and boot delays, when the clocksource watchdog does not catch the unstable TSC before the CPU goes deep idle for the first time.
The ACPI driver marks the TSC unstable when it detects that the CPU supports C2 or deeper and the CPU does not have a non-stop TSC.
Add the equivivalent work around to the Intel idle driver to cure that.
--- drivers/idle/intel_idle.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/idle/intel_idle.c +4 -0
@@ -56,6 +56,7 @@#include <asm/nospec-branch.h> #include <asm/mwait.h> #include <asm/msr.h> +#include <asm/tsc.h> #include <asm/fpu/api.h> #define INTEL_IDLE_VERSION "0.5.1"
@@ -1583,6 +1584,9 @@ static void __init intel_idle_init_cstatif (intel_idle_state_needs_timer_stop (state)) state->flags |=CPUIDLE_FLAG_TIMER_STOP ; +if (cx->type >ACPI_STATE_C1 && !boot_cpu_has (X86_FEATURE_NONSTOP_TSC )) +mark_tsc_unstable ("TSC halts in idle" ); + state->enter = intel_idle; state->enter_s2idle = intel_idle_s2idle; }
Greg Kroah-Hartman
maintainerPATCH 172/176 ptrace: Introduce exception_ip arch hook
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit 11ba1728be3edb6928791f4c622f154ebe228ae6 upstream.
On architectures with delay slot, architecture level instruction pointer (or program counter) in pt_regs may differ from where exception was triggered.
Introduce exception_ip hook to invoke architecture code and determine actual instruction pointer to the exception.
--- arch/mips/include/asm/ptrace.h | 2 ++ arch/mips/kernel/ptrace.c | 7 +++++++ include/linux/ptrace.h | 4 ++++ 3 files changed, 13 insertions(+)
arch/mips/include/asm/ptrace.h +2 -0
@@ -155,6 +155,8 @@ static inline long regs_return_value(str }#define instruction_pointer (regs) ((regs)->cp0_epc) +extern unsigned long exception_ip (struct pt_regs *regs); +#define exception_ip (regs) exception_ip(regs)#define profile_pc (regs) instruction_pointer(regs)extern asmlinkage long syscall_trace_enter (struct pt_regs *regs);
arch/mips/kernel/ptrace.c +7 -0
@@ -31,6 +31,7 @@#include <linux/seccomp.h> #include <linux/ftrace.h> +#include <asm/branch.h> #include <asm/byteorder.h> #include <asm/cpu.h> #include <asm/cpu-info.h>
@@ -48,6 +49,12 @@#define CREATE_TRACE_POINTS #include <trace/events/syscalls.h> +unsigned long exception_ip (struct pt_regs *regs) +{ +return exception_epc (regs); +} +EXPORT_SYMBOL (exception_ip); +/* * Called by kernel/ptrace.c when detaching.. *
include/linux/ptrace.h +4 -0
@@ -402,6 +402,10 @@ static inline void user_single_step_repo#define current_user_stack_pointer () user_stack_pointer(current_pt_regs())#endif +#ifndef exception_ip +#define exception_ip (x) instruction_pointer(x) +#endif +extern int task_current_syscall (struct task_struct *target,struct syscall_info *info);extern void sigaction_compat_abi (struct k_sigaction *act,struct k_sigaction *oact);
Greg Kroah-Hartman
maintainerPATCH 173/176 mm/memory: Use exception ip to search exception tables
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit 8fa5070833886268e4fb646daaca99f725b378e9 upstream.
On architectures with delay slot, instruction_pointer() may differ from where exception was triggered.
Use exception_ip we just introduced to search exception tables to get rid of the problem.
--- mm/memory.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
mm/memory.c +2 -2
@@ -5323,7 +5323,7 @@ static inline bool get_mmap_lock_careful }if (regs && !user_mode (regs)) { -unsigned long ip =instruction_pointer (regs); +unsigned long ip =exception_ip (regs);if (!search_exception_tables (ip))return false; }
@@ -5348,7 +5348,7 @@ static inline bool upgrade_mmap_lock_car {mmap_read_unlock (mm);if (regs && !user_mode (regs)) { -unsigned long ip =instruction_pointer (regs); +unsigned long ip =exception_ip (regs);if (!search_exception_tables (ip))return false; }
Greg Kroah-Hartman
maintainerPATCH 174/176 Squashfs: check the inode number is not the invalid value of zero
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phillip Lougher <[email protected]>
commit 9253c54e01b6505d348afbc02abaa4d9f8a01395 upstream.
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following sequence of events:
1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).
2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.
--- fs/squashfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/squashfs/inode.c +4 -1
@@ -48,6 +48,10 @@ static int squashfs_new_inode(struct supgid_t i_gid;int err; + inode->i_ino =le32_to_cpu (sqsh_ino->inode_number); +if (inode->i_ino ==0 ) +return -EINVAL ; + err =squashfs_get_id (sb,le16_to_cpu (sqsh_ino->uid), &i_uid);if (err)return err;
@@ -58,7 +62,6 @@ static int squashfs_new_inode(struct supi_uid_write (inode, i_uid);i_gid_write (inode, i_gid); - inode->i_ino =le32_to_cpu (sqsh_ino->inode_number); inode->i_mtime.tv_sec =le32_to_cpu (sqsh_ino->mtime); inode->i_atime.tv_sec = inode->i_mtime.tv_sec; inode->i_ctime.tv_sec = inode->i_mtime.tv_sec;
Re: [PATCH 6.1 174/176] Squashfs: check the inode number is not the invalid value of zero
Hi Gerg,
Could you please help to cherry-pick this commit from 6.1 to 5.15 and 5.10 branch? Thanks!
This should also impact on 5.15/10 branch, I tried to cherry-pick to 5.15/5.10 in my local setup, no conflict happens.
Here is 6.1 commit information:
Squashfs: check the inode number is not the invalid value of zero
author Phillip Lougher <[email protected]> 2024-04-08 23:02:06 +0100 committer Greg Kroah-Hartman <[email protected]> 2025-03-07 16:56:51 +0100 commit 5b99dea79650b50909c50aba24fbae00f203f013 (patch)
Br,
Xiangyu
Quoted 73 lines · Greg Kroah-Hartman
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phillip Lougher <[email protected]>
commit
9253c54e01b6505d348afbc02abaa4d9f8a01395upstream.Syskiller has produced an out of bounds access in
fill_meta_index().That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following sequence of events:
1.
Fill_meta_index()is called to allocate (viaempty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).2. When
fill_meta_index()is subsequently called again on another read operation,locate_meta_index()returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns
-EINVALif it is.[[email protected]: whitespace fix]Signed-off-by Phillip Lougher <[email protected]>Reported-by "Ubisectech Sirius" <[email protected]>Cc Christian Brauner <[email protected]>Cc <[email protected]>Signed-off-by Andrew Morton <[email protected]>Signed-off-by Xiangyu Chen <[email protected]>Signed-off-by He Zhe <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- fs/squashfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)fs/squashfs/inode.c +4
-1@@ -48,6 +48,10 @@ static int squashfs_new_inode(struct supgid_t i_gid;int err; + inode->i_ino =le32_to_cpu (sqsh_ino->inode_number); +if (inode->i_ino ==0 ) +return -EINVAL ; + err =squashfs_get_id (sb,le16_to_cpu (sqsh_ino->uid), &i_uid);if (err)return err;@@ -58,7 +62,6 @@ static int squashfs_new_inode(struct supi_uid_write (inode, i_uid);i_gid_write (inode, i_gid); - inode->i_ino =le32_to_cpu (sqsh_ino->inode_number); inode->i_mtime.tv_sec =le32_to_cpu (sqsh_ino->mtime); inode->i_atime.tv_sec = inode->i_mtime.tv_sec; inode->i_ctime.tv_sec = inode->i_mtime.tv_sec;
Greg Kroah-Hartman
maintainerPATCH 175/176 pfifo_tail_enqueue: Drop new packet when sch->limit == 0
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quang Le <[email protected]>
commit 647cef20e649c576dff271e018d5d15d998b629d upstream.
Expected behaviour:
In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return NET_XMIT_CN status code.
Weird behaviour:
In case we set sch->limit == 0 and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return NET_XMIT_CN status code.
The problem is:
Let's say we have two qdiscs: Qdisc_A and Qdisc_B.
- Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is hfsc. Enqueue packet to this qdisc will trigger hfsc_enqueue.
- Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger pfifo_tail_enqueue.
- Qdisc_B is configured to have sch->limit == 0.
- Qdisc_A is configured to route the enqueued's packet to Qdisc_B.
Enqueue packet through Qdisc_A will lead to:
- hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)
- Qdisc_B->q.qlen += 1
- pfifo_tail_enqueue() return NET_XMIT_CN
- hfsc_enqueue() check for NET_XMIT_SUCCESS and see NET_XMIT_CN => hfsc_enqueue() don't increase qlen of Qdisc_A.
The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.
Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.
--- net/sched/sch_fifo.c | 3 +++ 1 file changed, 3 insertions(+)
net/sched/sch_fifo.c +3 -0
@@ -39,6 +39,9 @@ static int pfifo_tail_enqueue(struct sk_ {unsigned int prev_backlog; +if (unlikely (READ_ONCE (sch->limit) ==0 )) +return qdisc_drop (skb, sch, to_free); +if (likely (sch->q.qlen < sch->limit))return qdisc_enqueue_tail (skb, sch);
Greg Kroah-Hartman
maintainerPATCH 176/176 media: mtk-vcodec: potential null pointer deference in SCP
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fullway Wang <[email protected]>
commit 53dbe08504442dc7ba4865c09b3bbf5fe849681b upstream.
The return value of devm_kzalloc() needs to be checked to avoid NULL pointer deference. This is similar to CVE-2022-3113.
--- drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/media/platform/mediatek/vcodec/mtk_vcodec_fw_scp.c +2 -0
@@ -65,6 +65,8 @@ struct mtk_vcodec_fw *mtk_vcodec_fw_scp_ } fw =devm_kzalloc (&dev->plat_dev->dev,sizeof (*fw),GFP_KERNEL ); +if (!fw) +return ERR_PTR (-ENOMEM ); fw->type =SCP ; fw->ops = &mtk_vcodec_rproc_msg; fw->scp = scp;
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.130 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.1.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Hello,
Quoted 7 lines · On Wed, 5 Mar 2025 18:46:09 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.1.130 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/damonitor/damon-tests/tree/next/corr
[2] 34da6dd4fda1 ("Linux 6.1.130-rc1")
Thanks,
SJ
[...]
---
ok 1 selftests: damon: debugfs_attrs.sh
ok 2 selftests: damon: debugfs_schemes.sh
ok 3 selftests: damon: debugfs_target_ids.sh
ok 4 selftests: damon: debugfs_empty_targets.sh
ok 5 selftests: damon: debugfs_huge_count_read_write.sh
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: sysfs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh # SKIP
ok 12 selftests: damon-tests: build_m68k.sh # SKIP
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
Am 05.03.2025 um 18:46 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.130 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.130 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.130-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.130 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.130 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.130-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.1.130-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 34da6dd4fda1d2daf1b0df768fe6224d0993e050
* git describe: v6.1.128-747-g34da6dd4fda1
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.128-747-g34da6dd4fda1
## Test Regressions (compared to v6.1.128-570-gfdd3f50c8e3e)
## Metric Regressions (compared to v6.1.128-570-gfdd3f50c8e3e)
## Test Fixes (compared to v6.1.128-570-gfdd3f50c8e3e)
## Metric Fixes (compared to v6.1.128-570-gfdd3f50c8e3e)
## Test result summary
total: 75778, pass: 58508, fail: 3115, skip: 13933, xfail: 222
## Build Summary
* arc: 6 total, 5 passed, 1 failed
* arm: 139 total, 139 passed, 0 failed
* arm64: 46 total, 42 passed, 4 failed
* i386: 31 total, 25 passed, 6 failed
* mips: 30 total, 25 passed, 5 failed
* parisc: 5 total, 5 passed, 0 failed
* powerpc: 36 total, 33 passed, 3 failed
* riscv: 14 total, 13 passed, 1 failed
* s390: 18 total, 15 passed, 3 failed
* sh: 12 total, 10 passed, 2 failed
* sparc: 9 total, 8 passed, 1 failed
* x86_64: 38 total, 38 passed, 0 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.130 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 07 Mar 2025 17:44:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.130-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah