6.11.4-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 135/214 netfilter: fib: check correct rtable in vrf setups
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
[ Upstream commit 05ef7055debc804e8083737402127975e7244fc4 ]
We need to init l3mdev unconditionally, else main routing table is searched and incorrect result is returned unless strict (iif keyword) matching is requested.
Next patch adds a selftest for this.
--- net/ipv4/netfilter/nft_fib_ipv4.c | 4 +--- net/ipv6/netfilter/nft_fib_ipv6.c | 5 +++-- 2 files changed, 4 insertions(+), 5 deletions(-)
net/ipv4/netfilter/nft_fib_ipv4.c +1 -3
@@ -66,6 +66,7 @@ void nft_fib4_eval(const struct nft_expr *expr, struct nft_regs *regs, .flowi4_scope = RT_SCOPE_UNIVERSE, .flowi4_iif = LOOPBACK_IFINDEX, .flowi4_uid = sock_net_uid(nft_net(pkt), NULL), + .flowi4_l3mdev = l3mdev_master_ifindex_rcu(nft_in(pkt)), };const struct net_device *oif;const struct net_device *found;
@@ -84,9 +85,6 @@ void nft_fib4_eval(const struct nft_expr *expr, struct nft_regs *regs,else oif =NULL ; -if (priv->flags &NFTA_FIB_F_IIF ) - fl4.flowi4_l3mdev =l3mdev_master_ifindex_rcu (oif); -if (nft_hook (pkt) ==NF_INET_PRE_ROUTING &&nft_fib_is_loopback (pkt->skb,nft_in (pkt))) {nft_fib_store_result (dest, priv,nft_in (pkt));
net/ipv6/netfilter/nft_fib_ipv6.c +3 -2
@@ -41,8 +41,6 @@ static int nft_fib6_flowi_init(struct flowi6 *fl6, const struct nft_fib *priv,if (ipv6_addr_type (&fl6->daddr) &IPV6_ADDR_LINKLOCAL ) { lookup_flags |=RT6_LOOKUP_F_IFACE ; fl6->flowi6_oif =get_ifindex (dev ? dev : pkt->skb->dev); - }else if (priv->flags &NFTA_FIB_F_IIF ) { - fl6->flowi6_l3mdev =l3mdev_master_ifindex_rcu (dev); }if (ipv6_addr_type (&fl6->saddr) &IPV6_ADDR_UNICAST )
@@ -75,6 +73,8 @@ static u32 __nft_fib6_eval_type(const struct nft_fib *priv,else if (priv->flags &NFTA_FIB_F_OIF ) dev =nft_out (pkt); + fl6.flowi6_l3mdev =l3mdev_master_ifindex_rcu (dev); +nft_fib6_flowi_init (&fl6, priv, pkt, dev, iph);if (dev &&nf_ipv6_chk_addr (nft_net (pkt), &fl6.daddr, dev, true))
@@ -165,6 +165,7 @@ void nft_fib6_eval(const struct nft_expr *expr, struct nft_regs *regs, .flowi6_iif = LOOPBACK_IFINDEX, .flowi6_proto = pkt->tprot, .flowi6_uid = sock_net_uid(nft_net(pkt), NULL), + .flowi6_l3mdev = l3mdev_master_ifindex_rcu(nft_in(pkt)), };struct rt6_info *rt;int lookup_flags;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 136/214 net: ibm: emac: mal: add dcr_unmap to _remove
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rosen Penev <[email protected]>
[ Upstream commit 080ddc22f3b0a58500f87e8e865aabbf96495eea ]
It's done in probe so it should be undone here.
--- drivers/net/ethernet/ibm/emac/mal.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/ibm/emac/mal.c +2 -0
@@ -742,6 +742,8 @@ static void mal_remove(struct platform_device *ofdev)free_netdev (mal->dummy_dev); +dcr_unmap (mal->dcr_host,0x100 ); + dma_free_coherent(&ofdev->dev, sizeof(struct mal_descriptor) * (NUM_TX_BUFF * mal->num_tx_chans +
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 137/214 net: dsa: refuse cross-chip mirroring operations
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit 8c924369cb56c3054dca504c2c9c3eb208272865 ]
In case of a tc mirred action from one switch to another, the behavior is not correct. We simply tell the source switch driver to program a mirroring entry towards mirror->to_local_port = to_dp->index, but it is not even guaranteed that the to_dp belongs to the same switch as dp.
For proper cross-chip support, we would need to go through the cross-chip notifier layer in switch.c, program the entry on cascade ports, and introduce new, explicit API for cross-chip mirroring, given that intermediary switches should have introspection into the DSA tags passed through the cascade port (and not just program a port mirror on the entire cascade port). None of that exists today.
Reject what is not implemented so that user space is not misled into thinking it works.
--- net/dsa/user.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
net/dsa/user.c +8 -3
@@ -1392,6 +1392,14 @@ dsa_user_add_cls_matchall_mirred(struct net_device *dev,if (!dsa_user_dev_check (act->dev))return -EOPNOTSUPP ; + to_dp =dsa_user_to_port (act->dev); + +if (dp->ds != to_dp->ds) { +NL_SET_ERR_MSG_MOD (extack, +"Cross-chip mirroring not implemented" ); +return -EOPNOTSUPP ; + } + mall_tc_entry =kzalloc (sizeof (*mall_tc_entry),GFP_KERNEL );if (!mall_tc_entry)return -ENOMEM ;
@@ -1399,9 +1407,6 @@ dsa_user_add_cls_matchall_mirred(struct net_device *dev, mall_tc_entry->cookie = cls->cookie; mall_tc_entry->type =DSA_PORT_MALL_MIRROR ; mirror = &mall_tc_entry->mirror; - - to_dp =dsa_user_to_port (act->dev); - mirror->to_local_port = to_dp->index; mirror->ingress = ingress;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 138/214 net: netconsole: fix wrong warning
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit d94785bb46b6167382b1de3290eccc91fa98df53 ]
A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration.
Current warning message:
------------[ cut here ]------------
WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0
? write_ext_msg+0x3b6/0x3d0
console_flush_all+0x1e9/0x330The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.
--- drivers/net/netconsole.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/net/netconsole.c +7 -1
@@ -1118,8 +1118,14 @@ static void send_ext_msg_udp(struct netconsole_target *nt, const char *msg, this_chunk =min (userdata_len - sent_userdata,MAX_PRINT_CHUNK - preceding_bytes); -if (WARN_ON_ONCE (this_chunk <=0 )) +if (WARN_ON_ONCE (this_chunk <0 )) +/* this_chunk could be zero if all the previous +* message used all the buffer. This is not a +* problem, userdata will be sent in the next +* iteration +*/ return ; +memcpy (buf + this_header + this_offset, userdata + sent_userdata, this_chunk);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 139/214 drm/fbdev-dma: Only cleanup deferred I/O if necessary
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Janne Grunau <[email protected]>
[ Upstream commit fcddc71ec7ecf15b4df3c41288c9cf0b8e886111 ]
Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs.
[ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---
--- drivers/gpu/drm/drm_fbdev_dma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/drm_fbdev_dma.c +2 -1
@@ -50,7 +50,8 @@ static void drm_fbdev_dma_fb_destroy(struct fb_info *info)if (!fb_helper->dev)return ; -fb_deferred_io_cleanup (info); +if (info->fbdefio) +fb_deferred_io_cleanup (info);drm_fb_helper_fini (fb_helper);drm_client_buffer_vunmap (fb_helper->buffer);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 140/214 net: do not delay dst_entries_add() in dst_release()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit ac888d58869bb99753e7652be19a151df9ecb35d ]
dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()
Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()
dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.
Decrementing the number of dsts must happen sooner.
Notes:
1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set.
IPSEC maintainers might take a look and see how to address this.
2) There is also discussion about removing this count of dst, which might happen in future kernels.
--- net/core/dst.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
net/core/dst.c +12 -5
@@ -109,9 +109,6 @@ static void dst_destroy(struct dst_entry *dst) child = xdst->child; }#endif -if (!(dst->flags &DST_NOCOUNT )) -dst_entries_add (dst->ops,-1 ); -if (dst->ops->destroy) dst->ops->destroy (dst);netdev_put (dst->dev, &dst->dev_tracker);
@@ -159,17 +156,27 @@ void dst_dev_put(struct dst_entry *dst) }EXPORT_SYMBOL (dst_dev_put); +static void dst_count_dec (struct dst_entry *dst) +{ +if (!(dst->flags &DST_NOCOUNT )) +dst_entries_add (dst->ops,-1 ); +} +void dst_release (struct dst_entry *dst) { -if (dst &&rcuref_put (&dst->__rcuref)) +if (dst &&rcuref_put (&dst->__rcuref)) { +dst_count_dec (dst);call_rcu_hurry (&dst->rcu_head, dst_destroy_rcu); + } }EXPORT_SYMBOL (dst_release);void dst_release_immediate (struct dst_entry *dst) { -if (dst &&rcuref_put (&dst->__rcuref)) +if (dst &&rcuref_put (&dst->__rcuref)) { +dst_count_dec (dst);dst_destroy (dst); + } }EXPORT_SYMBOL (dst_release_immediate);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 141/214 rtnetlink: Add bulk registration helpers for rtnetlink message handlers.
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 07cc7b0b942bf55ef1a471470ecda8d2a6a6541f ]
Before commit addf9b90de22 ("net: rtnetlink: use rcu to free rtnl message handlers"), once rtnl_msg_handlers[protocol] was allocated, the following rtnl_register_module() for the same protocol never failed.
However, after the commit, rtnl_msg_handler[protocol][msgtype] needs to be allocated in each rtnl_register_module(), so each call could fail.
Many callers of rtnl_register_module() do not handle the returned error, and we need to add many error handlings.
To handle that easily, let's add wrapper functions for bulk registration of rtnetlink message handlers.
Stable-dep-of: 78b7b991838a ("vxlan: Handle error of rtnl_register_module().")
--- include/net/rtnetlink.h | 17 +++++++++++++++++ net/core/rtnetlink.c | 29 +++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+)
include/net/rtnetlink.h +17 -0
@@ -29,6 +29,15 @@ static inline enum rtnl_kinds rtnl_msgtype_kind(int msgtype)return msgtype &RTNL_KIND_MASK ; } +struct rtnl_msg_handler { +struct module *owner; +int protocol; +int msgtype; +rtnl_doit_func doit; +rtnl_dumpit_func dumpit; +int flags; +}; +void rtnl_register (int protocol,int msgtype,rtnl_doit_func ,rtnl_dumpit_func ,unsigned int flags); int rtnl_register_module(struct module *owner, int protocol, int msgtype,
@@ -36,6 +45,14 @@ int rtnl_register_module(struct module *owner, int protocol, int msgtype,int rtnl_unregister (int protocol,int msgtype);void rtnl_unregister_all (int protocol); +int __rtnl_register_many (const struct rtnl_msg_handler *handlers,int n); +void __rtnl_unregister_many (const struct rtnl_msg_handler *handlers,int n); + +#define rtnl_register_many (handlers) \ + __rtnl_register_many(handlers, ARRAY_SIZE(handlers)) +#define rtnl_unregister_many (handlers) \ + __rtnl_unregister_many(handlers, ARRAY_SIZE(handlers)) +static inline int rtnl_msg_family (const struct nlmsghdr *nlh) {if (nlmsg_len (nlh) >=sizeof (struct rtgenmsg ))
net/core/rtnetlink.c +29 -0
@@ -384,6 +384,35 @@ void rtnl_unregister_all(int protocol) }EXPORT_SYMBOL_GPL (rtnl_unregister_all); +int __rtnl_register_many (const struct rtnl_msg_handler *handlers,int n) +{ +const struct rtnl_msg_handler *handler; +int i, err; + +for (i =0 , handler = handlers; i < n; i++, handler++) { + err =rtnl_register_internal (handler->owner, handler->protocol, + handler->msgtype, handler->doit, + handler->dumpit, handler->flags); +if (err) { +__rtnl_unregister_many (handlers, i); +break ; + } + } + +return err; +} +EXPORT_SYMBOL_GPL (__rtnl_register_many); + +void __rtnl_unregister_many (const struct rtnl_msg_handler *handlers,int n) +{ +const struct rtnl_msg_handler *handler; +int i; + +for (i = n -1 , handler = handlers + n -1 ; i >=0 ; i--, handler--) +rtnl_unregister (handler->protocol, handler->msgtype); +} +EXPORT_SYMBOL_GPL (__rtnl_unregister_many); +static LIST_HEAD (link_ops);static const struct rtnl_link_ops *rtnl_link_ops_get (const char *kind)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 142/214 vxlan: Handle error of rtnl_register_module().
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 78b7b991838a4a6baeaad934addc4db2c5917eb8 ]
Since introduced, vxlan_vnifilter_init() has been ignoring the returned value of rtnl_register_module(), which could fail silently.
Handling the error allows users to view a module as an all-or-nothing thing in terms of the rtnetlink functionality. This prevents syzkaller from reporting spurious errors from its tests, where OOM often occurs and module is automatically loaded.
Let's handle the errors by rtnl_register_many().
--- drivers/net/vxlan/vxlan_core.c | 6 +++++- drivers/net/vxlan/vxlan_private.h | 2 +- drivers/net/vxlan/vxlan_vnifilter.c | 19 +++++++++---------- 3 files changed, 15 insertions(+), 12 deletions(-)
drivers/net/vxlan/vxlan_core.c +5 -1
@@ -4913,9 +4913,13 @@ static int __init vxlan_init_module(void)if (rc) goto out4; -vxlan_vnifilter_init (); + rc =vxlan_vnifilter_init (); +if (rc) + goto out5;return 0 ; +out5: +rtnl_link_unregister (&vxlan_link_ops); out4:unregister_switchdev_notifier (&vxlan_switchdev_notifier_block); out3:
drivers/net/vxlan/vxlan_private.h +1 -1
@@ -202,7 +202,7 @@ int vxlan_vni_in_use(struct net *src_net, struct vxlan_dev *vxlan,int vxlan_vnigroup_init (struct vxlan_dev *vxlan);void vxlan_vnigroup_uninit (struct vxlan_dev *vxlan); -void vxlan_vnifilter_init (void ); +int vxlan_vnifilter_init (void );void vxlan_vnifilter_uninit (void ); void vxlan_vnifilter_count(struct vxlan_dev *vxlan, __be32 vni, struct vxlan_vni_node *vninode,
drivers/net/vxlan/vxlan_vnifilter.c +9 -10
@@ -992,19 +992,18 @@ static int vxlan_vnifilter_process(struct sk_buff *skb, struct nlmsghdr *nlh,return err; } -void vxlan_vnifilter_init (void ) +static const struct rtnl_msg_handler vxlan_vnifilter_rtnl_msg_handlers[] = { + {THIS_MODULE ,PF_BRIDGE ,RTM_GETTUNNEL ,NULL , vxlan_vnifilter_dump,0 }, + {THIS_MODULE ,PF_BRIDGE ,RTM_NEWTUNNEL , vxlan_vnifilter_process,NULL ,0 }, + {THIS_MODULE ,PF_BRIDGE ,RTM_DELTUNNEL , vxlan_vnifilter_process,NULL ,0 }, +}; + +int vxlan_vnifilter_init (void ) { -rtnl_register_module (THIS_MODULE ,PF_BRIDGE ,RTM_GETTUNNEL ,NULL , - vxlan_vnifilter_dump,0 ); -rtnl_register_module (THIS_MODULE ,PF_BRIDGE ,RTM_NEWTUNNEL , - vxlan_vnifilter_process,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_BRIDGE ,RTM_DELTUNNEL , - vxlan_vnifilter_process,NULL ,0 ); +return rtnl_register_many (vxlan_vnifilter_rtnl_msg_handlers); }void vxlan_vnifilter_uninit (void ) { -rtnl_unregister (PF_BRIDGE ,RTM_GETTUNNEL ); -rtnl_unregister (PF_BRIDGE ,RTM_NEWTUNNEL ); -rtnl_unregister (PF_BRIDGE ,RTM_DELTUNNEL ); +rtnl_unregister_many (vxlan_vnifilter_rtnl_msg_handlers); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 143/214 bridge: Handle error of rtnl_register_module().
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit cba5e43b0b757734b1e79f624d93a71435e31136 ]
Since introduced, br_vlan_rtnl_init() has been ignoring the returned value of rtnl_register_module(), which could fail silently.
Handling the error allows users to view a module as an all-or-nothing thing in terms of the rtnetlink functionality. This prevents syzkaller from reporting spurious errors from its tests, where OOM often occurs and module is automatically loaded.
Let's handle the errors by rtnl_register_many().
--- net/bridge/br_netlink.c | 6 +++++- net/bridge/br_private.h | 5 +++-- net/bridge/br_vlan.c | 19 +++++++++---------- 3 files changed, 17 insertions(+), 13 deletions(-)
net/bridge/br_netlink.c +5 -1
@@ -1920,7 +1920,10 @@ int __init br_netlink_init(void) {int err; -br_vlan_rtnl_init (); + err =br_vlan_rtnl_init (); +if (err) + goto out; +rtnl_af_register (&br_af_ops); err =rtnl_link_register (&br_link_ops);
@@ -1931,6 +1934,7 @@ int __init br_netlink_init(void) out_af:rtnl_af_unregister (&br_af_ops); +out:return err; }
net/bridge/br_private.h +3 -2
@@ -1571,7 +1571,7 @@ void br_vlan_get_stats(const struct net_bridge_vlan *v,void br_vlan_port_event (struct net_bridge_port *p,unsigned long event);int br_vlan_bridge_event (struct net_device *dev,unsigned long event,void *ptr); -void br_vlan_rtnl_init (void ); +int br_vlan_rtnl_init (void );void br_vlan_rtnl_uninit (void ); void br_vlan_notify(const struct net_bridge *br, const struct net_bridge_port *p,
@@ -1802,8 +1802,9 @@ static inline int br_vlan_bridge_event(struct net_device *dev,return 0 ; } -static inline void br_vlan_rtnl_init (void ) +static inline int br_vlan_rtnl_init (void ) { +return 0 ; }static inline void br_vlan_rtnl_uninit (void )
net/bridge/br_vlan.c +9 -10
@@ -2296,19 +2296,18 @@ static int br_vlan_rtm_process(struct sk_buff *skb, struct nlmsghdr *nlh,return err; } -void br_vlan_rtnl_init (void ) +static const struct rtnl_msg_handler br_vlan_rtnl_msg_handlers[] = { + {THIS_MODULE ,PF_BRIDGE ,RTM_NEWVLAN , br_vlan_rtm_process,NULL ,0 }, + {THIS_MODULE ,PF_BRIDGE ,RTM_DELVLAN , br_vlan_rtm_process,NULL ,0 }, + {THIS_MODULE ,PF_BRIDGE ,RTM_GETVLAN ,NULL , br_vlan_rtm_dump,0 }, +}; + +int br_vlan_rtnl_init (void ) { -rtnl_register_module (THIS_MODULE ,PF_BRIDGE ,RTM_GETVLAN ,NULL , - br_vlan_rtm_dump,0 ); -rtnl_register_module (THIS_MODULE ,PF_BRIDGE ,RTM_NEWVLAN , - br_vlan_rtm_process,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_BRIDGE ,RTM_DELVLAN , - br_vlan_rtm_process,NULL ,0 ); +return rtnl_register_many (br_vlan_rtnl_msg_handlers); }void br_vlan_rtnl_uninit (void ) { -rtnl_unregister (PF_BRIDGE ,RTM_GETVLAN ); -rtnl_unregister (PF_BRIDGE ,RTM_NEWVLAN ); -rtnl_unregister (PF_BRIDGE ,RTM_DELVLAN ); +rtnl_unregister_many (br_vlan_rtnl_msg_handlers); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 144/214 mctp: Handle error of rtnl_register_module().
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit d51705614f668254cc5def7490df76f9680b4659 ]
Since introduced, mctp has been ignoring the returned value of rtnl_register_module(), which could fail silently.
Handling the error allows users to view a module as an all-or-nothing thing in terms of the rtnetlink functionality. This prevents syzkaller from reporting spurious errors from its tests, where OOM often occurs and module is automatically loaded.
Let's handle the errors by rtnl_register_many().
--- include/net/mctp.h | 2 +- net/mctp/af_mctp.c | 6 +++++- net/mctp/device.c | 30 ++++++++++++++++++------------ net/mctp/neigh.c | 31 +++++++++++++++++++------------ net/mctp/route.c | 33 +++++++++++++++++++++++---------- 5 files changed, 66 insertions(+), 36 deletions(-)
include/net/mctp.h +1 -1
@@ -295,7 +295,7 @@ void mctp_neigh_remove_dev(struct mctp_dev *mdev);int mctp_routes_init (void );void mctp_routes_exit (void ); -void mctp_device_init (void ); +int mctp_device_init (void );void mctp_device_exit (void );#endif /* __NET_MCTP_H */
net/mctp/af_mctp.c +5 -1
@@ -753,10 +753,14 @@ static __init int mctp_init(void)if (rc) goto err_unreg_routes; -mctp_device_init (); + rc =mctp_device_init (); +if (rc) + goto err_unreg_neigh;return 0 ; +err_unreg_neigh: +mctp_neigh_exit (); err_unreg_routes:mctp_routes_exit (); err_unreg_proto:
net/mctp/device.c +18 -12
@@ -524,25 +524,31 @@ static struct notifier_block mctp_dev_nb = { .priority = ADDRCONF_NOTIFY_PRIORITY, }; -void __init mctp_device_init (void ) +static const struct rtnl_msg_handler mctp_device_rtnl_msg_handlers[] = { + {THIS_MODULE ,PF_MCTP ,RTM_NEWADDR , mctp_rtm_newaddr,NULL ,0 }, + {THIS_MODULE ,PF_MCTP ,RTM_DELADDR , mctp_rtm_deladdr,NULL ,0 }, + {THIS_MODULE ,PF_MCTP ,RTM_GETADDR ,NULL , mctp_dump_addrinfo,0 }, +}; + +int __init mctp_device_init (void ) { -register_netdevice_notifier (&mctp_dev_nb); +int err; -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_GETADDR , -NULL , mctp_dump_addrinfo,0 ); -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_NEWADDR , - mctp_rtm_newaddr,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_DELADDR , - mctp_rtm_deladdr,NULL ,0 ); +register_netdevice_notifier (&mctp_dev_nb);rtnl_af_register (&mctp_af_ops); + + err =rtnl_register_many (mctp_device_rtnl_msg_handlers); +if (err) { +rtnl_af_unregister (&mctp_af_ops); +unregister_netdevice_notifier (&mctp_dev_nb); + } + +return err; } void __exit mctp_device_exit(void) { +rtnl_unregister_many (mctp_device_rtnl_msg_handlers);rtnl_af_unregister (&mctp_af_ops); -rtnl_unregister (PF_MCTP ,RTM_DELADDR ); -rtnl_unregister (PF_MCTP ,RTM_NEWADDR ); -rtnl_unregister (PF_MCTP ,RTM_GETADDR ); -unregister_netdevice_notifier (&mctp_dev_nb); }
net/mctp/neigh.c +19 -12
@@ -322,22 +322,29 @@ static struct pernet_operations mctp_net_ops = { .exit = mctp_neigh_net_exit, }; +static const struct rtnl_msg_handler mctp_neigh_rtnl_msg_handlers[] = { + {THIS_MODULE ,PF_MCTP ,RTM_NEWNEIGH , mctp_rtm_newneigh,NULL ,0 }, + {THIS_MODULE ,PF_MCTP ,RTM_DELNEIGH , mctp_rtm_delneigh,NULL ,0 }, + {THIS_MODULE ,PF_MCTP ,RTM_GETNEIGH ,NULL , mctp_rtm_getneigh,0 }, +}; +int __init mctp_neigh_init (void ) { -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_NEWNEIGH , - mctp_rtm_newneigh,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_DELNEIGH , - mctp_rtm_delneigh,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_GETNEIGH , -NULL , mctp_rtm_getneigh,0 ); - -return register_pernet_subsys (&mctp_net_ops); +int err; + + err =register_pernet_subsys (&mctp_net_ops); +if (err) +return err; + + err =rtnl_register_many (mctp_neigh_rtnl_msg_handlers); +if (err) +unregister_pernet_subsys (&mctp_net_ops); + +return err; } -void __exit mctp_neigh_exit(void) +void mctp_neigh_exit (void ) { +rtnl_unregister_many (mctp_neigh_rtnl_msg_handlers);unregister_pernet_subsys (&mctp_net_ops); -rtnl_unregister (PF_MCTP ,RTM_GETNEIGH ); -rtnl_unregister (PF_MCTP ,RTM_DELNEIGH ); -rtnl_unregister (PF_MCTP ,RTM_NEWNEIGH ); }
net/mctp/route.c +23 -10
@@ -1474,26 +1474,39 @@ static struct pernet_operations mctp_net_ops = { .exit = mctp_routes_net_exit, }; +static const struct rtnl_msg_handler mctp_route_rtnl_msg_handlers[] = { + {THIS_MODULE ,PF_MCTP ,RTM_NEWROUTE , mctp_newroute,NULL ,0 }, + {THIS_MODULE ,PF_MCTP ,RTM_DELROUTE , mctp_delroute,NULL ,0 }, + {THIS_MODULE ,PF_MCTP ,RTM_GETROUTE ,NULL , mctp_dump_rtinfo,0 }, +}; +int __init mctp_routes_init (void ) { +int err; +dev_add_pack (&mctp_packet_type); -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_GETROUTE , -NULL , mctp_dump_rtinfo,0 ); -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_NEWROUTE , - mctp_newroute,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_MCTP ,RTM_DELROUTE , - mctp_delroute,NULL ,0 ); + err =register_pernet_subsys (&mctp_net_ops); +if (err) + goto err_pernet; + + err =rtnl_register_many (mctp_route_rtnl_msg_handlers); +if (err) + goto err_rtnl; -return register_pernet_subsys (&mctp_net_ops); +return 0 ; + +err_rtnl: +unregister_pernet_subsys (&mctp_net_ops); +err_pernet: +dev_remove_pack (&mctp_packet_type); +return err; }void mctp_routes_exit (void ) { +rtnl_unregister_many (mctp_route_rtnl_msg_handlers);unregister_pernet_subsys (&mctp_net_ops); -rtnl_unregister (PF_MCTP ,RTM_DELROUTE ); -rtnl_unregister (PF_MCTP ,RTM_NEWROUTE ); -rtnl_unregister (PF_MCTP ,RTM_GETROUTE );dev_remove_pack (&mctp_packet_type); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 145/214 mpls: Handle error of rtnl_register_module().
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 5be2062e3080e3ff6707816caa445ec0c6eaacf7 ]
Since introduced, mpls_init() has been ignoring the returned value of rtnl_register_module(), which could fail silently.
Handling the error allows users to view a module as an all-or-nothing thing in terms of the rtnetlink functionality. This prevents syzkaller from reporting spurious errors from its tests, where OOM often occurs and module is automatically loaded.
Let's handle the errors by rtnl_register_many().
--- net/mpls/af_mpls.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-)
net/mpls/af_mpls.c +21 -11
@@ -2730,6 +2730,15 @@ static struct rtnl_af_ops mpls_af_ops __read_mostly = { .get_stats_af_size = mpls_get_stats_af_size, }; +static const struct rtnl_msg_handler mpls_rtnl_msg_handlers[] __initdata_or_module = { + {THIS_MODULE ,PF_MPLS ,RTM_NEWROUTE , mpls_rtm_newroute,NULL ,0 }, + {THIS_MODULE ,PF_MPLS ,RTM_DELROUTE , mpls_rtm_delroute,NULL ,0 }, + {THIS_MODULE ,PF_MPLS ,RTM_GETROUTE , mpls_getroute, mpls_dump_routes,0 }, + {THIS_MODULE ,PF_MPLS ,RTM_GETNETCONF , + mpls_netconf_get_devconf, mpls_netconf_dump_devconf, +RTNL_FLAG_DUMP_UNLOCKED }, +}; +static int __init mpls_init (void ) {int err;
@@ -2748,24 +2757,25 @@ static int __init mpls_init(void)rtnl_af_register (&mpls_af_ops); -rtnl_register_module (THIS_MODULE ,PF_MPLS ,RTM_NEWROUTE , - mpls_rtm_newroute,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_MPLS ,RTM_DELROUTE , - mpls_rtm_delroute,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_MPLS ,RTM_GETROUTE , - mpls_getroute, mpls_dump_routes,0 ); -rtnl_register_module (THIS_MODULE ,PF_MPLS ,RTM_GETNETCONF , - mpls_netconf_get_devconf, - mpls_netconf_dump_devconf, -RTNL_FLAG_DUMP_UNLOCKED ); - err =ipgre_tunnel_encap_add_mpls_ops (); + err =rtnl_register_many (mpls_rtnl_msg_handlers);if (err) + goto out_unregister_rtnl_af; + + err =ipgre_tunnel_encap_add_mpls_ops (); +if (err) {pr_err ("Can't add mpls over gre tunnel ops\n" ); + goto out_unregister_rtnl; + } err =0 ; out:return err; +out_unregister_rtnl: +rtnl_unregister_many (mpls_rtnl_msg_handlers); +out_unregister_rtnl_af: +rtnl_af_unregister (&mpls_af_ops); +dev_remove_pack (&mpls_packet_type); out_unregister_pernet:unregister_pernet_subsys (&mpls_net_ops); goto out;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 146/214 phonet: Handle error of rtnl_register_module().
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit b5e837c86041bef60f36cf9f20a641a30764379a ]
Before commit addf9b90de22 ("net: rtnetlink: use rcu to free rtnl message handlers"), once the first rtnl_register_module() allocated rtnl_msg_handlers[PF_PHONET], the following calls never failed.
However, after the commit, rtnl_register_module() could fail silently to allocate rtnl_msg_handlers[PF_PHONET][msgtype] and requires error handling for each call.
Handling the error allows users to view a module as an all-or-nothing thing in terms of the rtnetlink functionality. This prevents syzkaller from reporting spurious errors from its tests, where OOM often occurs and module is automatically loaded.
Let's use rtnl_register_many() to handle the errors easily.
--- net/phonet/pn_netlink.c | 28 +++++++++++----------------- 1 file changed, 11 insertions(+), 17 deletions(-)
net/phonet/pn_netlink.c +11 -17
@@ -285,23 +285,17 @@ static int route_dumpit(struct sk_buff *skb, struct netlink_callback *cb)return err; } +static const struct rtnl_msg_handler phonet_rtnl_msg_handlers[] __initdata_or_module = { + {THIS_MODULE ,PF_PHONET ,RTM_NEWADDR , addr_doit,NULL ,0 }, + {THIS_MODULE ,PF_PHONET ,RTM_DELADDR , addr_doit,NULL ,0 }, + {THIS_MODULE ,PF_PHONET ,RTM_GETADDR ,NULL , getaddr_dumpit,0 }, + {THIS_MODULE ,PF_PHONET ,RTM_NEWROUTE , route_doit,NULL ,0 }, + {THIS_MODULE ,PF_PHONET ,RTM_DELROUTE , route_doit,NULL ,0 }, + {THIS_MODULE ,PF_PHONET ,RTM_GETROUTE ,NULL , route_dumpit, +RTNL_FLAG_DUMP_UNLOCKED }, +}; +int __init phonet_netlink_register (void ) { -int err =rtnl_register_module (THIS_MODULE ,PF_PHONET ,RTM_NEWADDR , - addr_doit,NULL ,0 ); -if (err) -return err; - -/* Further rtnl_register_module() cannot fail */ -rtnl_register_module (THIS_MODULE ,PF_PHONET ,RTM_DELADDR , - addr_doit,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_PHONET ,RTM_GETADDR , -NULL , getaddr_dumpit,0 ); -rtnl_register_module (THIS_MODULE ,PF_PHONET ,RTM_NEWROUTE , - route_doit,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_PHONET ,RTM_DELROUTE , - route_doit,NULL ,0 ); -rtnl_register_module (THIS_MODULE ,PF_PHONET ,RTM_GETROUTE , -NULL , route_dumpit,RTNL_FLAG_DUMP_UNLOCKED ); -return 0 ; +return rtnl_register_many (phonet_rtnl_msg_handlers); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 147/214 ppp: fix ppp_async_encode() illegal access
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 40dddd4b8bd08a69471efd96107a4e1c73fabefc ]
syzbot reported an issue in ppp_async_encode() [1]
In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.
BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
--- drivers/net/ppp/ppp_async.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ppp/ppp_async.c +1 -1
@@ -542,7 +542,7 @@ ppp_async_encode(struct asyncppp *ap)* and 7 (code-reject) must be sent as though no options * had been negotiated. */ - islcp = proto ==PPP_LCP &&1 <= data[2 ] && data[2 ] <=7 ; + islcp = proto ==PPP_LCP && count >=3 &&1 <= data[2 ] && data[2 ] <=7 ;if (i ==0 ) {if (islcp)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 148/214 net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: D. Wythe <[email protected]>
[ Upstream commit 6fd27ea183c208e478129a85e11d880fc70040f2 ]
Eric report a panic on IPPROTO_SMC, and give the facts
that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too.
Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x0000000086000005
EC = 0x21: IABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000
Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910
sp : ffff80009b887a90
x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000
x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00
x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000
x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee
x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001
x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003
x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000
Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]---
This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.
--- net/smc/smc_inet.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
net/smc/smc_inet.c +11 -0
@@ -108,12 +108,23 @@ static struct inet_protosw smc_inet6_protosw = { };#endif /* CONFIG_IPV6 */ +static unsigned int smc_sync_mss (struct sock *sk,u32 pmtu) +{ +/* No need pass it through to clcsock, mss can always be set by +* sock_create_kern or smc_setsockopt. +*/ +return 0 ; +} +static int smc_inet_init_sock (struct sock *sk) {struct net *net =sock_net (sk);/* init common smc sock */ smc_sk_init (net, sk,IPPROTO_SMC ); + +inet_csk (sk)->icsk_sync_mss = smc_sync_mss; +/* create clcsock */ return smc_create_clcsk (net, sk, sk->sk_family); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 149/214 slip: make slhc_remember() more robust against malicious packets
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 7d3fce8cbe3a70a1c7c06c9b53696be5d5d8dd5c ]
syzbot found that slhc_remember() was missing checks against malicious packets [1].
slhc_remember() only checked the size of the packet was at least 20, which is not good enough.
We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.
Add iph and th pointers to make the code more readable.
[1]
BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
--- drivers/net/slip/slhc.c | 57 ++++++++++++++++++++++++----------------- 1 file changed, 34 insertions(+), 23 deletions(-)
drivers/net/slip/slhc.c +34 -23
@@ -643,46 +643,57 @@ slhc_uncompress(struct slcompress *comp, unsigned char *icp, int isize)int slhc_remember (struct slcompress *comp,unsigned char *icp,int isize) { -struct cstate *cs; -unsigned ihl; - +const struct tcphdr *th;unsigned char index; +struct iphdr *iph; +struct cstate *cs; +unsigned int ihl; -if (isize <20 ) { -/* The packet is shorter than a legal IP header */ +/* The packet is shorter than a legal IP header. +* Also make sure isize is positive. +*/ +if (isize < (int )sizeof (struct iphdr )) { +runt: comp->sls_i_runt++; -return slhc_toss ( comp ); +return slhc_toss (comp); } + iph = (struct iphdr *)icp;/* Peek at the IP header's IHL field to find its length */ - ihl = icp[0 ] &0xf ; -if (ihl <20 /4 ){ -/* The IP header length field is too small */ - comp->sls_i_runt++; -return slhc_toss ( comp ); - } - index = icp[9 ]; - icp[9 ] =IPPROTO_TCP ; + ihl = iph->ihl; +/* The IP header length field is too small, +* or packet is shorter than the IP header followed +* by minimal tcp header. +*/ +if (ihl <5 || isize < ihl *4 +sizeof (struct tcphdr )) + goto runt; + + index = iph->protocol; + iph->protocol =IPPROTO_TCP ;if (ip_fast_csum (icp, ihl)) {/* Bad IP header checksum; discard */ comp->sls_i_badcheck++; -return slhc_toss ( comp ); +return slhc_toss (comp); } -if (index > comp->rslot_limit) { +if (index > comp->rslot_limit) { comp->sls_i_error++;return slhc_toss (comp); } - + th = (struct tcphdr *)(icp + ihl *4 ); +if (th->doff <sizeof (struct tcphdr ) /4 ) + goto runt; +if (isize < ihl *4 + th->doff *4 ) + goto runt;/* Update local state */ cs = &comp->rstate[comp->recv_current = index]; comp->flags &=~SLF_TOSS ; -memcpy (&cs->cs_ip,icp,20 ); -memcpy (&cs->cs_tcp,icp + ihl*4 ,20 ); +memcpy (&cs->cs_ip, iph,sizeof (*iph)); +memcpy (&cs->cs_tcp, th,sizeof (*th));if (ihl >5 ) -memcpy (cs->cs_ipopt, icp +sizeof (struct iphdr ), (ihl -5 ) *4 ); -if (cs->cs_tcp.doff >5 ) -memcpy (cs->cs_tcpopt, icp + ihl*4 +sizeof (struct tcphdr ), (cs->cs_tcp.doff -5 ) *4 ); - cs->cs_hsize = ihl*2 + cs->cs_tcp.doff*2 ; +memcpy (cs->cs_ipopt, &iph[1 ], (ihl -5 ) *4 ); +if (th->doff >5 ) +memcpy (cs->cs_tcpopt, &th[1 ], (th->doff -5 ) *4 ); + cs->cs_hsize = ihl*2 + th->doff*2 ; cs->initialized = true;/* Put headers back on packet * Neither header checksum is recalculated
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 150/214 rcu/nocb: Fix rcuog wake-up from offline softirq
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frederic Weisbecker <[email protected]>
[ Upstream commit f7345ccc62a4b880cf76458db5f320725f28e400 ]
After a CPU has set itself offline and before it eventually calls rcutree_report_cpu_dead(), there are still opportunities for callbacks to be enqueued, for example from a softirq. When that happens on NOCB, the rcuog wake-up is deferred through an IPI to an online CPU in order not to call into the scheduler and risk arming the RT-bandwidth after hrtimers have been migrated out and disabled.
But performing a synchronized IPI from a softirq is buggy as reported in the following scenario:
WARNING: CPU: 1 PID: 26 at kernel/smp.c:633 smp_call_function_single
Modules linked in: rcutorture torture
CPU: 1 UID: 0 PID: 26 Comm: migration/1 Not tainted 6.11.0-rc1-00012-g9139f93209d1 #1
Stopper: multi_cpu_stop+0x0/0x320 <- __stop_cpus+0xd0/0x120
RIP: 0010:smp_call_function_single
<IRQ>
swake_up_one_online
__call_rcu_nocb_wake
__call_rcu_common
? rcu_torture_one_read
call_timer_fn
__run_timers
run_timer_softirq
handle_softirqs
irq_exit_rcu
? tick_handle_periodic
sysvec_apic_timer_interrupt
</IRQ>Fix this with forcing deferred rcuog wake up through the NOCB timer when the CPU is offline. The actual wake up will happen from rcutree_report_cpu_dead().
--- kernel/rcu/tree_nocb.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
kernel/rcu/tree_nocb.h +7 -1
@@ -569,13 +569,19 @@ static void __call_rcu_nocb_wake(struct rcu_data *rdp, bool was_alldone,rcu_nocb_unlock (rdp);wake_nocb_gp_defer (rdp,RCU_NOCB_WAKE_LAZY ,TPS ("WakeLazy" )); - }else if (!irqs_disabled_flags (flags)) { + }else if (!irqs_disabled_flags (flags) &&cpu_online (rdp->cpu)) {/* ... if queue was empty ... */ rcu_nocb_unlock (rdp);wake_nocb_gp (rdp, false);trace_rcu_nocb_wake (rcu_state.name, rdp->cpu,TPS ("WakeEmpty" )); }else { +/* +* Don't do the wake-up upfront on fragile paths. +* Also offline CPUs can't call swake_up_one_online() from +* (soft-)IRQs. Rely on the final deferred wake-up from +* rcutree_report_cpu_dead() +*/ rcu_nocb_unlock (rdp);wake_nocb_gp_defer (rdp,RCU_NOCB_WAKE ,TPS ("WakeEmptyIsDeferred" ));
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 151/214 x86/amd_nb: Add new PCI IDs for AMD family 1Ah model 60h
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shyam Sundar S K <[email protected]>
[ Upstream commit 59c34008d3bdeef4c8ebc0ed2426109b474334d4 ]
Add new PCI device IDs into the root IDs and miscellaneous IDs lists to provide support for the latest generation of AMD 1Ah family 60h processor models.
--- arch/x86/kernel/amd_nb.c | 3 +++ drivers/hwmon/k10temp.c | 1 + include/linux/pci_ids.h | 1 + 3 files changed, 5 insertions(+)
arch/x86/kernel/amd_nb.c +3 -0
@@ -26,6 +26,7 @@#define PCI_DEVICE_ID_AMD_19H_M70H_ROOT 0x14e8#define PCI_DEVICE_ID_AMD_1AH_M00H_ROOT 0x153a#define PCI_DEVICE_ID_AMD_1AH_M20H_ROOT 0x1507 +#define PCI_DEVICE_ID_AMD_1AH_M60H_ROOT 0x1122#define PCI_DEVICE_ID_AMD_MI200_ROOT 0x14bb#define PCI_DEVICE_ID_AMD_MI300_ROOT 0x14f8
@@ -63,6 +64,7 @@ static const struct pci_device_id amd_root_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M70H_ROOT) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M00H_ROOT) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M20H_ROOT) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M60H_ROOT) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_MI200_ROOT) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_MI300_ROOT) }, {}
@@ -95,6 +97,7 @@ static const struct pci_device_id amd_nb_misc_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M78H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M00H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M20H_DF_F3) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M60H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M70H_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_MI200_DF_F3) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_MI300_DF_F3) },
drivers/hwmon/k10temp.c +1 -0
@@ -548,6 +548,7 @@ static const struct pci_device_id k10temp_id_table[] = { { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_19H_M78H_DF_F3) }, { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M00H_DF_F3) }, { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M20H_DF_F3) }, + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_1AH_M60H_DF_F3) }, { PCI_VDEVICE(HYGON, PCI_DEVICE_ID_AMD_17H_DF_F3) }, {} };
include/linux/pci_ids.h +1 -0
@@ -580,6 +580,7 @@#define PCI_DEVICE_ID_AMD_19H_M78H_DF_F3 0x12fb#define PCI_DEVICE_ID_AMD_1AH_M00H_DF_F3 0x12c3#define PCI_DEVICE_ID_AMD_1AH_M20H_DF_F3 0x16fb +#define PCI_DEVICE_ID_AMD_1AH_M60H_DF_F3 0x124b#define PCI_DEVICE_ID_AMD_1AH_M70H_DF_F3 0x12bb#define PCI_DEVICE_ID_AMD_MI200_DF_F3 0x14d3#define PCI_DEVICE_ID_AMD_MI300_DF_F3 0x152b
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 152/214 HID: multitouch: Add support for lenovo Y9000P Touchpad
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: He Lugang <[email protected]>
[ Upstream commit 251efae73bd46b097deec4f9986d926813aed744 ]
The 2024 Lenovo Y9000P which use GT7868Q chip also needs a fixup. The information of the chip is as follows:
I2C HID v1.00 Mouse [GXTP5100:00 27C6:01E0]
--- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-multitouch.c | 8 ++++++-- 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/hid/hid-ids.h +1 -0
@@ -505,6 +505,7 @@#define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100#define I2C_VENDOR_ID_GOODIX 0x27c6 +#define I2C_DEVICE_ID_GOODIX_01E0 0x01e0#define I2C_DEVICE_ID_GOODIX_01E8 0x01e8#define I2C_DEVICE_ID_GOODIX_01E9 0x01e9#define I2C_DEVICE_ID_GOODIX_01F0 0x01f0
drivers/hid/hid-multitouch.c +6 -2
@@ -1446,7 +1446,8 @@ static __u8 *mt_report_fixup(struct hid_device *hdev, __u8 *rdesc, {if (hdev->vendor ==I2C_VENDOR_ID_GOODIX && (hdev->product ==I2C_DEVICE_ID_GOODIX_01E8 || - hdev->product ==I2C_DEVICE_ID_GOODIX_01E9 )) { + hdev->product ==I2C_DEVICE_ID_GOODIX_01E9 || + hdev->product ==I2C_DEVICE_ID_GOODIX_01E0 )) {if (rdesc[607 ] ==0x15 ) { rdesc[607 ] =0x25 ; dev_info(
@@ -2065,7 +2066,10 @@ static const struct hid_device_id mt_devices[] = { I2C_DEVICE_ID_GOODIX_01E8) }, { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU,HID_DEVICE (BUS_I2C ,HID_GROUP_ANY ,I2C_VENDOR_ID_GOODIX , - I2C_DEVICE_ID_GOODIX_01E8) }, + I2C_DEVICE_ID_GOODIX_01E9) }, + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU, +HID_DEVICE (BUS_I2C ,HID_GROUP_ANY ,I2C_VENDOR_ID_GOODIX , + I2C_DEVICE_ID_GOODIX_01E0) }, /* GoodTouch panels */ { .driver_data = MT_CLS_NSMU,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 153/214 hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Colberg <[email protected]>
[ Upstream commit a017616fafc6b2a6b3043bf46f6381ef2611c188 ]
Consistently use CVL instead of Columbiaville, since CVL is already being used in all other sensor labels for the Intel N6000 card.
Message-ID: <[email protected]>
--- drivers/hwmon/intel-m10-bmc-hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/intel-m10-bmc-hwmon.c +1 -1
@@ -358,7 +358,7 @@ static const struct m10bmc_sdata n6000bmc_temp_tbl[] = { { 0x4f0, 0x4f4, 0x4f8, 0x52c, 0x0, 500, "Board Top Near FPGA Temperature" }, { 0x4fc, 0x500, 0x504, 0x52c, 0x0, 500, "Board Bottom Near CVL Temperature" }, { 0x508, 0x50c, 0x510, 0x52c, 0x0, 500, "Board Top East Near VRs Temperature" }, - { 0x514, 0x518, 0x51c, 0x52c, 0x0, 500, "Columbiaville Die Temperature" }, + { 0x514, 0x518, 0x51c, 0x52c, 0x0, 500, "CVL Die Temperature" }, { 0x520, 0x524, 0x528, 0x52c, 0x0, 500, "Board Rear Side Temperature" }, { 0x530, 0x534, 0x538, 0x52c, 0x0, 500, "Board Front Side Temperature" }, { 0x53c, 0x540, 0x544, 0x0, 0x0, 500, "QSFP1 Case Temperature" },
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 154/214 hwmon: (tmp513) Add missing dependency on REGMAP_I2C
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit 193bc02c664999581a1f38c152f379fce91afc0c ]
0-day reports:
drivers/hwmon/tmp513.c:162:21: error:
variable 'tmp51x_regmap_config' has initializer but incomplete type
162 | static const struct regmap_config tmp51x_regmap_config = {
| ^
struct regmap_config is only available if REGMAP is enabled. Add the missing Kconfig dependency to fix the problem.
--- drivers/hwmon/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/Kconfig +1 -0
@@ -2288,6 +2288,7 @@ config SENSORS_TMP464 config SENSORS_TMP513 tristate "Texas Instruments TMP513 and compatibles" depends on I2C + select REGMAP_I2C help If you say yes here you get support for Texas Instruments TMP512, and TMP513 temperature and power supply sensor chips.
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 155/214 hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <[email protected]>
[ Upstream commit 56c77c0f4a7c9043e7d1d94e0aace264361e6717 ]
This driver requires REGMAP_I2C to be selected in order to get access to regmap_config and devm_regmap_init_i2c. Add the missing dependency.
Message-ID: <[email protected]>
--- drivers/hwmon/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/Kconfig +1 -0
@@ -1275,6 +1275,7 @@ config SENSORS_MAX31790 config SENSORS_MC34VR500 tristate "NXP MC34VR500 hardware monitoring driver" depends on I2C + select REGMAP_I2C help If you say yes here you get support for the temperature and input voltage sensors of the NXP MC34VR500.
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 156/214 hwmon: (adm9240) Add missing dependency on REGMAP_I2C
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <[email protected]>
[ Upstream commit 14849a2ec175bb8a2280ce20efe002bb19f1e274 ]
This driver requires REGMAP_I2C to be selected in order to get access to regmap_config and devm_regmap_init_i2c. Add the missing dependency.
Message-ID: <[email protected]>
--- drivers/hwmon/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/Kconfig +1 -0
@@ -162,6 +162,7 @@ config SENSORS_ADM9240 tristate "Analog Devices ADM9240 and compatibles" depends on I2C select HWMON_VID + select REGMAP_I2C help If you say yes here you get support for Analog Devices ADM9240, Dallas DS1780, National Semiconductor LM81 sensor chips.
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 157/214 hwmon: (adt7470) Add missing dependency on REGMAP_I2C
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <[email protected]>
[ Upstream commit b6abcc19566509ab4812bd5ae5df46515d0c1d70 ]
This driver requires REGMAP_I2C to be selected in order to get access to regmap_config and devm_regmap_init_i2c. Add the missing dependency.
Message-ID: <[email protected]>
--- drivers/hwmon/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/Kconfig +1 -0
@@ -224,6 +224,7 @@ config SENSORS_ADT7462 config SENSORS_ADT7470 tristate "Analog Devices ADT7470" depends on I2C + select REGMAP_I2C help If you say yes here you get support for the Analog Devices ADT7470 temperature monitoring chips.
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 158/214 hwmon: (ltc2991) Add missing dependency on REGMAP_I2C
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <[email protected]>
[ Upstream commit 7d4cc7fdc6c889608fff051530e6f0c617f71995 ]
This driver requires REGMAP_I2C to be selected in order to get access to regmap_config and devm_regmap_init_i2c. Add the missing dependency.
Message-ID: <[email protected]>
--- drivers/hwmon/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/Kconfig +1 -0
@@ -1001,6 +1001,7 @@ config SENSORS_LTC2990 config SENSORS_LTC2991 tristate "Analog Devices LTC2991" depends on I2C + select REGMAP_I2C help If you say yes here you get support for Analog Devices LTC2991 Octal I2C Voltage, Current, and Temperature Monitor. The LTC2991
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 159/214 HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Basavaraj Natikar <[email protected]>
commit c56f9ecb7fb6a3a90079c19eb4c8daf3bbf514b3 upstream.
Using the device-managed version allows to simplify clean-up in probe() error path.
Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.
--- drivers/hid/amd-sfh-hid/amd_sfh_client.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-)
drivers/hid/amd-sfh-hid/amd_sfh_client.c +3 -11
@@ -236,9 +236,9 @@ int amd_sfh_hid_client_init(struct amd_m cl_data->in_data = in_data;for (i =0 ; i < cl_data->num_hid_devices; i++) { - in_data->sensor_virt_addr[i] =dma_alloc_coherent (dev,sizeof (int ) *8 , - &cl_data->sensor_dma_addr[i], -GFP_KERNEL ); + in_data->sensor_virt_addr[i] =dmam_alloc_coherent (dev,sizeof (int ) *8 , + &cl_data->sensor_dma_addr[i], +GFP_KERNEL );if (!in_data->sensor_virt_addr[i]) { rc = -ENOMEM ; goto cleanup;
@@ -331,7 +331,6 @@ cleanup:int amd_sfh_hid_client_deinit (struct amd_mp2_dev *privdata) {struct amdtp_cl_data *cl_data = privdata->cl_data; -struct amd_input_data *in_data = cl_data->in_data;int i, status;for (i =0 ; i < cl_data->num_hid_devices; i++) {
@@ -351,12 +350,5 @@ int amd_sfh_hid_client_deinit(struct amdcancel_delayed_work_sync (&cl_data->work_buffer);amdtp_hid_remove (cl_data); -for (i =0 ; i < cl_data->num_hid_devices; i++) { -if (in_data->sensor_virt_addr[i]) { -dma_free_coherent (&privdata->pdev->dev,8 *sizeof (int ), - in_data->sensor_virt_addr[i], - cl_data->sensor_dma_addr[i]); - } - }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 160/214 HID: plantronics: Workaround for an unexcepted opposite volume key
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wade Wang <[email protected]>
commit 87b696209007b7c4ef7bdfe39ea0253404a43770 upstream.
Some Plantronics headset as the below send an unexcept opposite volume key's HID report for each volume key press after 200ms, like unecepted Volume Up Key following Volume Down key pressed by user. This patch adds a quirk to hid-plantronics for these devices, which will ignore the second unexcepted opposite volume key if it happens within 220ms from the last one that was handled.
Plantronics EncorePro 500 Series (047f:431e)
Plantronics Blackwire_3325 Series (047f:430c)The patch was tested on the mentioned model, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected per test result.
--- drivers/hid/hid-ids.h | 2 ++ drivers/hid/hid-plantronics.c | 23 +++++++++++++++++++++++ 2 files changed, 25 insertions(+)
drivers/hid/hid-ids.h +2 -0
@@ -1036,6 +1036,8 @@#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3220_SERIES 0xc056#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3215_SERIES 0xc057#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3225_SERIES 0xc058 +#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3325_SERIES 0x430c +#define USB_DEVICE_ID_PLANTRONICS_ENCOREPRO_500_SERIES 0x431e#define USB_VENDOR_ID_PANASONIC 0x04da#define USB_DEVICE_ID_PANABOARD_UBT780 0x1044
drivers/hid/hid-plantronics.c +23 -0
@@ -38,8 +38,10 @@ (usage->hid & HID_USAGE_PAGE) == HID_UP_CONSUMER)#define PLT_QUIRK_DOUBLE_VOLUME_KEYS BIT(0) +#define PLT_QUIRK_FOLLOWED_OPPOSITE_VOLUME_KEYS BIT(1)#define PLT_DOUBLE_KEY_TIMEOUT 5/* ms */ +#define PLT_FOLLOWED_OPPOSITE_KEY_TIMEOUT 220/* ms */ struct plt_drv_data {unsigned long device_type;
@@ -137,6 +139,21 @@ static int plantronics_event(struct hid_ drv_data->last_volume_key_ts = cur_ts; } +if (drv_data->quirks &PLT_QUIRK_FOLLOWED_OPPOSITE_VOLUME_KEYS ) { +unsigned long prev_ts, cur_ts; + +/* Usages are filtered in plantronics_usages. */ + +if (!value)/* Handle key presses only. */ +return 0 ; + + prev_ts = drv_data->last_volume_key_ts; + cur_ts = jiffies; +if (jiffies_to_msecs (cur_ts - prev_ts) <=PLT_FOLLOWED_OPPOSITE_KEY_TIMEOUT ) +return 1 ;/* Ignore the followed opposite volume key. */ + + drv_data->last_volume_key_ts = cur_ts; + }return 0 ; }
@@ -210,6 +227,12 @@ static const struct hid_device_id plantr {HID_USB_DEVICE (USB_VENDOR_ID_PLANTRONICS , USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3225_SERIES), .driver_data = PLT_QUIRK_DOUBLE_VOLUME_KEYS }, + { HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS, + USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3325_SERIES), + .driver_data = PLT_QUIRK_FOLLOWED_OPPOSITE_VOLUME_KEYS }, + { HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS, + USB_DEVICE_ID_PLANTRONICS_ENCOREPRO_500_SERIES), + .driver_data = PLT_QUIRK_FOLLOWED_OPPOSITE_VOLUME_KEYS }, { HID_USB_DEVICE(USB_VENDOR_ID_PLANTRONICS, HID_ANY_ID) }, { } };
Greg Kroah-Hartman
maintainerPATCH 161/214 HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gerecke <[email protected]>
commit 2934b12281abf4eb5f915086fd5699de5c497ccd upstream.
Unlike EMR tools which encode type information in their tool ID, tools for AES sensors are all "generic pens". It is inappropriate to make use of the wacom_intuos_get_tool_type function when dealing with these kinds of devices. Instead, we should only ever report BTN_TOOL_PEN or BTN_TOOL_RUBBER, as depending on the state of the Eraser and Invert bits.
--- drivers/hid/wacom_wac.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/hid/wacom_wac.c +2 -0
@@ -2501,6 +2501,8 @@ static void wacom_wac_pen_report(struct/* Going into range select tool */ if (wacom_wac->hid_data.invert_state) wacom_wac->tool[0 ] =BTN_TOOL_RUBBER ; +else if (wacom_wac->features.quirks &WACOM_QUIRK_AESPEN ) + wacom_wac->tool[0 ] =BTN_TOOL_PEN ;else if (wacom_wac->id[0 ]) wacom_wac->tool[0 ] =wacom_intuos_get_tool_type (wacom_wac->id[0 ]);else
Greg Kroah-Hartman
maintainerPATCH 162/214 Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant"
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 71c717cd8a2e180126932cc6851ff21c1d04d69a upstream.
This reverts commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035.
This patch leads to passing 0 to simple_read_from_buffer() as a fifth argument, turning the read method into a nop. The change is fundamentally flawed, as it breaks the driver.
--- drivers/usb/misc/yurex.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
drivers/usb/misc/yurex.c +8 -11
@@ -34,8 +34,6 @@#define YUREX_BUF_SIZE 8#define YUREX_WRITE_TIMEOUT (HZ*2) -#define MAX_S64_STRLEN 20/* {-}922337203685477580{7,8} */ -/* table of devices that work with this driver */ static struct usb_device_id yurex_table[] = { {USB_DEVICE (YUREX_VENDOR_ID ,YUREX_PRODUCT_ID ) },
@@ -403,7 +401,8 @@ static ssize_t yurex_read(struct file *f {struct usb_yurex *dev;int len =0 ; -char in_buffer[MAX_S64_STRLEN ]; +char in_buffer[20 ]; +unsigned long flags; dev = file->private_data;
@@ -413,16 +412,14 @@ static ssize_t yurex_read(struct file *freturn -ENODEV ; } -if (WARN_ON_ONCE (dev->bbu >S64_MAX || dev->bbu <S64_MIN )) { -mutex_unlock (&dev->io_mutex); -return -EIO ; - } - -spin_lock_irq (&dev->lock); -scnprintf (in_buffer,MAX_S64_STRLEN ,"%lld\n" , dev->bbu); -spin_unlock_irq (&dev->lock); +spin_lock_irqsave (&dev->lock, flags); + len =snprintf (in_buffer,20 ,"%lld\n" , dev->bbu); +spin_unlock_irqrestore (&dev->lock, flags);mutex_unlock (&dev->io_mutex); +if (WARN_ON_ONCE (len >=sizeof (in_buffer))) +return -EIO ; +return simple_read_from_buffer (buffer, count, ppos, in_buffer, len); }
RE: [PATCH 6.11 162/214] Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant"
From: Greg Kroah-Hartman
Quoted 8 lines
Sent: 14 October 2024 15:20
6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
Quoted 7 lines
commit
71c717cd8a2e180126932cc6851ff21c1d04d69aupstream.This reverts commit
86b20af11e84c26ae3fde4dcc4f490948e3f8035.This patch leads to passing 0 to
simple_read_from_buffer()as a fifth argument, turning the read method into a nop. The change is fundamentally flawed, as it breaks the driver.
This failed my mail filter rules (don't ask...) so I read it. The patch clearly broke the code, but it is pretty horrid.
A quick scan shows a CMD_LED of length 1 send uninitialised stack. dev->bbu is usually 40 bits max, except when it is initialised to -1 or when a very large integer is supplied (c2 isn't masked).
Never mind the strange locking across slow operations.
There is pretty much no point holding a mutex across a copy_from_user() into an on-stack structure.
...
drivers/usb/misc/yurex.c static ssize_t yurex_read(struct file *f · line 418
Quoted 3 lines
drivers/usb/misc/yurex.c +0
-3-if (WARN_ON_ONCE (dev->bbu >S64_MAX || dev->bbu <S64_MIN )) { -mutex_unlock (&dev->io_mutex); -return -EIO ;
dev->bbu is s64 - that can never happen.
Apart from the initialisation to -1 (never checked for) it is also always +ve.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Greg Kroah-Hartman
maintainerPATCH 163/214 usb: dwc3: core: Stop processing of pending events if controller is halted
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Selvarasu Ganesan <[email protected]>
commit 0d410e8913f5cffebcca79ffdd596009d4a13a28 upstream.
This commit addresses an issue where events were being processed when the controller was in a halted state. To fix this issue by stop processing the events as the event count was considered stale or invalid when the controller was halted.
--- drivers/usb/dwc3/core.c | 22 +++++++++++++++++++--- drivers/usb/dwc3/core.h | 4 ---- drivers/usb/dwc3/gadget.c | 11 ----------- 3 files changed, 19 insertions(+), 18 deletions(-)
drivers/usb/dwc3/core.c +19 -3
@@ -544,6 +544,7 @@ static int dwc3_alloc_event_buffers(struint dwc3_event_buffers_setup (struct dwc3 *dwc) {struct dwc3_event_buffer *evt; +u32 reg;if (!dwc->ev_buf)return 0 ;
@@ -556,8 +557,10 @@ int dwc3_event_buffers_setup(struct dwc3 upper_32_bits(evt->dma));dwc3_writel (dwc->regs,DWC3_GEVNTSIZ (0 ),DWC3_GEVNTSIZ_SIZE (evt->length)); -dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ),0 ); +/* Clear any stale event */ + reg =dwc3_readl (dwc->regs,DWC3_GEVNTCOUNT (0 )); +dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ), reg);return 0 ; }
@@ -584,7 +587,10 @@ void dwc3_event_buffers_cleanup(struct ddwc3_writel (dwc->regs,DWC3_GEVNTADRHI (0 ),0 );dwc3_writel (dwc->regs,DWC3_GEVNTSIZ (0 ),DWC3_GEVNTSIZ_INTMASK |DWC3_GEVNTSIZ_SIZE (0 )); -dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ),0 ); + +/* Clear any stale event */ + reg =dwc3_readl (dwc->regs,DWC3_GEVNTCOUNT (0 )); +dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ), reg); }static void dwc3_core_num_eps (struct dwc3 *dwc)
@@ -2499,7 +2505,11 @@ static int dwc3_runtime_resume(struct deswitch (dwc->current_dr_role) {case DWC3_GCTL_PRTCAP_DEVICE : -dwc3_gadget_process_pending_events (dwc); +if (dwc->pending_events) { +pm_runtime_put (dwc->dev); + dwc->pending_events = false; +enable_irq (dwc->irq_gadget); + }break ;case DWC3_GCTL_PRTCAP_HOST :default :
@@ -2589,6 +2599,12 @@ static void dwc3_complete(struct devicestatic const struct dev_pm_ops dwc3_dev_pm_ops = {SET_SYSTEM_SLEEP_PM_OPS (dwc3_suspend, dwc3_resume) .complete = dwc3_complete, + +/* +* Runtime suspend halts the controller on disconnection. It relies on +* platforms with custom connection notification to start the controller +* again. +*/ SET_RUNTIME_PM_OPS (dwc3_runtime_suspend, dwc3_runtime_resume, dwc3_runtime_idle) };
drivers/usb/dwc3/core.h +0 -4
@@ -1675,7 +1675,6 @@ static inline void dwc3_otg_host_init(st#if !IS_ENABLED (CONFIG_USB_DWC3_HOST )int dwc3_gadget_suspend (struct dwc3 *dwc);int dwc3_gadget_resume (struct dwc3 *dwc); -void dwc3_gadget_process_pending_events (struct dwc3 *dwc);#else static inline int dwc3_gadget_suspend (struct dwc3 *dwc) {
@@ -1687,9 +1686,6 @@ static inline int dwc3_gadget_resume(str return 0; } -static inline void dwc3_gadget_process_pending_events (struct dwc3 *dwc) -{ -}#endif /* !IS_ENABLED(CONFIG_USB_DWC3_HOST) */ #if IS_ENABLED (CONFIG_USB_DWC3_ULPI )
drivers/usb/dwc3/gadget.c +0 -11
@@ -4728,14 +4728,3 @@ int dwc3_gadget_resume(struct dwc3 *dwc)return dwc3_gadget_soft_connect (dwc); } - -void dwc3_gadget_process_pending_events (struct dwc3 *dwc) -{ -if (dwc->pending_events) { -dwc3_interrupt (dwc->irq_gadget, dwc->ev_buf); -dwc3_thread_interrupt (dwc->irq_gadget, dwc->ev_buf); -pm_runtime_put (dwc->dev); - dwc->pending_events = false; -enable_irq (dwc->irq_gadget); - } -}
Greg Kroah-Hartman
maintainerPATCH 164/214 usb: xhci: Fix problem with xhci resume from suspend
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jose Alberto Reguero <[email protected]>
commit d44238d8254a36249d576c96473269dbe500f5e4 upstream.
I have a ASUS PN51 S mini pc that has two xhci devices. One from AMD, and other from ASMEDIA. The one from ASMEDIA have problems when resume from suspend, and keep broken until unplug the power cord. I use this kernel parameter: xhci-hcd.quirks=128 and then it works ok. I make a path to reset only the ASMEDIA xhci.
--- drivers/usb/host/xhci-pci.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/usb/host/xhci-pci.c +5 -0
@@ -79,6 +79,7 @@#define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142#define PCI_DEVICE_ID_ASMEDIA_1142_XHCI 0x1242#define PCI_DEVICE_ID_ASMEDIA_2142_XHCI 0x2142 +#define PCI_DEVICE_ID_ASMEDIA_3042_XHCI 0x3042#define PCI_DEVICE_ID_ASMEDIA_3242_XHCI 0x3242#define PCI_DEVICE_ID_CADENCE 0x17CD
@@ -457,6 +458,10 @@ static void xhci_pci_quirks(struct devic pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI) xhci->quirks |= XHCI_ASMEDIA_MODIFY_FLOWCONTROL; +if (pdev->vendor ==PCI_VENDOR_ID_ASMEDIA && + pdev->device ==PCI_DEVICE_ID_ASMEDIA_3042_XHCI ) + xhci->quirks |=XHCI_RESET_ON_RESUME ; +if (pdev->vendor ==PCI_VENDOR_ID_TI && pdev->device ==0x8241 ) xhci->quirks |=XHCI_LIMIT_ENDPOINT_INTERVAL_7 ;
Greg Kroah-Hartman
maintainerPATCH 165/214 usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Icenowy Zheng <[email protected]>
commit a6555cb1cb69db479d0760e392c175ba32426842 upstream.
JieLi tends to use SCSI via USB Mass Storage to implement their own proprietary commands instead of implementing another USB interface. Enumerating it as a generic mass storage device will lead to a Hardware Error sense key get reported.
Ignore this bogus device to prevent appearing a unusable sdX device file.
--- drivers/usb/storage/unusual_devs.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/usb/storage/unusual_devs.h +11 -0
@@ -2423,6 +2423,17 @@ UNUSUAL_DEV( 0xc251, 0x4003, 0x0100, 0x USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NOT_LOCKABLE), +/* +* Reported by Icenowy Zheng <[email protected]> +* This is an interface for vendor-specific cryptic commands instead +* of real USB storage device. +*/ +UNUSUAL_DEV (0xe5b7 ,0x0811 ,0x0100 ,0x0100 , +"ZhuHai JieLi Technology" , +"JieLi BR21" , +USB_SC_DEVICE ,USB_PR_DEVICE ,NULL , +US_FL_IGNORE_DEVICE ), +/* Reported by Andrew Simmons <[email protected]> */ UNUSUAL_DEV( 0xed06, 0x4500, 0x0001, 0x0001, "DataStor",
Greg Kroah-Hartman
maintainerPATCH 166/214 usb: dwc3: re-enable runtime PM after failed resume
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roy Luo <[email protected]>
commit 897e13a8f9a23576eeacb95075fdded97b197cc3 upstream.
When dwc3_resume_common() returns an error, runtime pm is left in suspended and disabled state in dwc3_resume(). Since the device is suspended, its parent devices (like the power domain or glue driver) could also be suspended and may have released resources that dwc requires. Consequently, calling dwc3_suspend_common() in this situation could result in attempts to access unclocked or unpowered registers.
To prevent these problems, runtime PM should always be re-enabled, even after failed resume attempts. This ensures that dwc3_suspend_common() is skipped in such cases.
--- drivers/usb/dwc3/core.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/usb/dwc3/core.c +3 -5
@@ -2562,7 +2562,7 @@ static int dwc3_suspend(struct device *dstatic int dwc3_resume (struct device *dev) {struct dwc3 *dwc =dev_get_drvdata (dev); -int ret; +int ret =0 ;pinctrl_pm_select_default_state (dev);
@@ -2570,14 +2570,12 @@ static int dwc3_resume(struct device *depm_runtime_set_active (dev); ret =dwc3_resume_common (dwc,PMSG_RESUME ); -if (ret) { +if (ret)pm_runtime_set_suspended (dev); -return ret; - }pm_runtime_enable (dev); -return 0 ; +return ret; }static void dwc3_complete (struct device *dev)
Greg Kroah-Hartman
maintainerPATCH 167/214 usb: gadget: core: force synchronous registration
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Keeping <[email protected]>
commit df9158826b00e53f42c67d62c887a84490d80a0a upstream.
Registering a gadget driver is expected to complete synchronously and immediately after calling driver_register() this function checks that the driver has bound so as to return an error.
Set PROBE_FORCE_SYNCHRONOUS to ensure this is the case even when asynchronous probing is set as the default.
--- drivers/usb/gadget/udc/core.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/udc/core.c +1 -0
@@ -1696,6 +1696,7 @@ int usb_gadget_register_driver_owner(str driver->driver.bus = &gadget_bus_type; driver->driver.owner = owner; driver->driver.mod_name = mod_name; + driver->driver.probe_type =PROBE_FORCE_SYNCHRONOUS ; ret =driver_register (&driver->driver);if (ret) { pr_warn("%s: driver registration failed: %d\n",
Greg Kroah-Hartman
maintainerPATCH 168/214 hid: intel-ish-hid: Fix uninitialized variable rv in ish_fw_xfer_direct_dma
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: SurajSonawane2415 <[email protected]>
commit d41bff05a61fb539f21e9bf0d39fac77f457434e upstream.
Fix the uninitialized symbol 'rv' in the function ish_fw_xfer_direct_dma to resolve the following warning from the smatch tool:drivers/hid/intel-ish-hid/ishtp-fw-loader.c:714 ish_fw_xfer_direct_dma()
error: uninitialized symbol 'rv'.
Initialize 'rv' to 0 to prevent undefined behavior from uninitialized access.
--- drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/intel-ish-hid/ishtp-fw-loader.c +1 -1
@@ -635,7 +635,7 @@ static int ish_fw_xfer_direct_dma(structconst struct firmware *fw, const struct shim_fw_info fw_info) { - int rv; + int rv = 0;void *dma_buf;dma_addr_t dma_buf_phy;u32 fragment_offset, fragment_size, payload_max_size;
Greg Kroah-Hartman
maintainerPATCH 169/214 ACPI: resource: Make Asus ExpertBook B2402 matches cover more models
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit 564a278573783cd8859829767851744087e676d8 upstream.
The Asus ExpertBook B2402CBA / B2402FBA are the non flip / flip versions of the 14" Asus ExpertBook B2 with 12th gen Intel processors.
It has been reported that the B2402FVA which is the 14" Asus ExpertBook B2 flip with 13th gen Intel processors needs to skip the IRQ override too.
And looking at Asus website there also is a B2402CVA which is the non flip model with 13th gen Intel processors.
Summarizing the following 4 models of the Asus ExpertBook B2 are known:
B2402CBA: 12th gen Intel CPU, non flip
B2402FBA: 12th gen Intel CPU, flip
B2402CVA: 13th gen Intel CPU, non flip
B2402FVA: 13th gen Intel CPU, flip
Fold the 2 existing quirks for the B2402CBA and B2402FBA into a single quirk covering B2402* to also cover the 2 other models while at the same time reducing the number of quirks.
--- drivers/acpi/resource.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-)
drivers/acpi/resource.c +2 -9
@@ -483,17 +483,10 @@ static const struct dmi_system_id irq1_l }, }, { -/* Asus ExpertBook B2402CBA */ +/* Asus ExpertBook B2402 (B2402CBA / B2402FBA / B2402CVA / B2402FVA) */ .matches = {DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), - DMI_MATCH(DMI_BOARD_NAME, "B2402CBA"), - }, - }, - { -/* Asus ExpertBook B2402FBA */ - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), - DMI_MATCH(DMI_BOARD_NAME, "B2402FBA"), + DMI_MATCH(DMI_BOARD_NAME, "B2402"), }, }, {
Greg Kroah-Hartman
maintainerPATCH 170/214 ACPI: resource: Make Asus ExpertBook B2502 matches cover more models
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
commit 435f2d87579e2408ab6502248f2270fc3c9e636e upstream.
Like the various 14" Asus ExpertBook B2 B2402* models there are also 4 variants of the 15" Asus ExpertBook B2 B2502* models:
B2502CBA: 12th gen Intel CPU, non flip
B2502FBA: 12th gen Intel CPU, flip
B2502CVA: 13th gen Intel CPU, non flip
B2502FVA: 13th gen Intel CPU, flip
Currently there already are DMI quirks for the B2502CBA, B2502FBA and B2502CVA models. Asus website shows that there also is a B2502FVA.
Rather then adding a 4th quirk fold the 3 existing quirks into a single quirk covering B2502* to also cover the last model while at the same time reducing the number of quirks.
--- drivers/acpi/resource.c | 18 ++---------------- 1 file changed, 2 insertions(+), 16 deletions(-)
drivers/acpi/resource.c +2 -16
@@ -490,24 +490,10 @@ static const struct dmi_system_id irq1_l }, }, { -/* Asus ExpertBook B2502 */ +/* Asus ExpertBook B2502 (B2502CBA / B2502FBA / B2502CVA / B2502FVA) */ .matches = {DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), - DMI_MATCH(DMI_BOARD_NAME, "B2502CBA"), - }, - }, - { -/* Asus ExpertBook B2502FBA */ - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), - DMI_MATCH(DMI_BOARD_NAME, "B2502FBA"), - }, - }, - { -/* Asus ExpertBook B2502CVA */ - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), - DMI_MATCH(DMI_BOARD_NAME, "B2502CVA"), + DMI_MATCH(DMI_BOARD_NAME, "B2502"), }, }, {
Greg Kroah-Hartman
maintainerPATCH 171/214 drm/amdgpu: partially revert powerplay `__counted_by` changes
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit d6b9f492e229be1d1bd360c3ac5bee4635bacf99 upstream.
Partially revert
commit 0ca9f757a0e2 ("drm/amd/pm: powerplay: Add __counted_by attribute for flexible arrays")
The count attribute for these arrays does not get set until after the arrays are allocated and populated leading to false UBSAN warnings.
--- drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 26 ++++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-)
drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h +13 -13
@@ -60,7 +60,7 @@ struct vi_dpm_level {struct vi_dpm_table {uint32_t count; - struct vi_dpm_level dpm_level[] __counted_by(count); +struct vi_dpm_level dpm_level[]; };#define PCIE_PERF_REQ_REMOVE_REGISTRY 0
@@ -91,7 +91,7 @@ struct phm_set_power_state_input {struct phm_clock_array {uint32_t count; - uint32_t values[] __counted_by(count); +uint32_t values[]; };struct phm_clock_voltage_dependency_record {
@@ -123,7 +123,7 @@ struct phm_acpclock_voltage_dependency_record {struct phm_clock_voltage_dependency_table {uint32_t count; - struct phm_clock_voltage_dependency_record entries[] __counted_by(count); +struct phm_clock_voltage_dependency_record entries[]; };struct phm_phase_shedding_limits_record {
@@ -140,7 +140,7 @@ struct phm_uvd_clock_voltage_dependency_record {struct phm_uvd_clock_voltage_dependency_table {uint8_t count; - struct phm_uvd_clock_voltage_dependency_record entries[] __counted_by(count); +struct phm_uvd_clock_voltage_dependency_record entries[]; };struct phm_acp_clock_voltage_dependency_record {
@@ -150,7 +150,7 @@ struct phm_acp_clock_voltage_dependency_record {struct phm_acp_clock_voltage_dependency_table {uint32_t count; - struct phm_acp_clock_voltage_dependency_record entries[] __counted_by(count); +struct phm_acp_clock_voltage_dependency_record entries[]; };struct phm_vce_clock_voltage_dependency_record {
@@ -161,32 +161,32 @@ struct phm_vce_clock_voltage_dependency_record {struct phm_phase_shedding_limits_table {uint32_t count; - struct phm_phase_shedding_limits_record entries[] __counted_by(count); +struct phm_phase_shedding_limits_record entries[]; };struct phm_vceclock_voltage_dependency_table {uint8_t count; - struct phm_vceclock_voltage_dependency_record entries[] __counted_by(count); +struct phm_vceclock_voltage_dependency_record entries[]; };struct phm_uvdclock_voltage_dependency_table {uint8_t count; - struct phm_uvdclock_voltage_dependency_record entries[] __counted_by(count); +struct phm_uvdclock_voltage_dependency_record entries[]; };struct phm_samuclock_voltage_dependency_table {uint8_t count; - struct phm_samuclock_voltage_dependency_record entries[] __counted_by(count); +struct phm_samuclock_voltage_dependency_record entries[]; };struct phm_acpclock_voltage_dependency_table {uint32_t count; - struct phm_acpclock_voltage_dependency_record entries[] __counted_by(count); +struct phm_acpclock_voltage_dependency_record entries[]; };struct phm_vce_clock_voltage_dependency_table {uint8_t count; - struct phm_vce_clock_voltage_dependency_record entries[] __counted_by(count); +struct phm_vce_clock_voltage_dependency_record entries[]; };
@@ -393,7 +393,7 @@ union phm_cac_leakage_record {struct phm_cac_leakage_table {uint32_t count; - union phm_cac_leakage_record entries[] __counted_by(count); +union phm_cac_leakage_record entries[]; };struct phm_samu_clock_voltage_dependency_record {
@@ -404,7 +404,7 @@ struct phm_samu_clock_voltage_dependency_record {struct phm_samu_clock_voltage_dependency_table {uint8_t count; - struct phm_samu_clock_voltage_dependency_record entries[] __counted_by(count); +struct phm_samu_clock_voltage_dependency_record entries[]; };struct phm_cac_tdp_table {
Signature · 1 line
2.47.0
Greg Kroah-Hartman
maintainerPATCH 172/214 drm/amd/display: Clear update flags after update has been applied
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josip Pavic <[email protected]>
commit 0a9906cc45d21e21ca8bb2b98b79fd7c05420fda upstream.
[Why]
Since the surface/stream update flags aren't cleared after applying updates, those same updates may be applied again in a future call to update surfaces/streams for surfaces/streams that aren't actually part of that update (i.e. applying an update for one surface/stream can trigger unintended programming on a different surface/stream).
For example, when an update results in a call to program_front_end_for_ctx, that function may call program_pipe on all pipes. If there are surface update flags that were never cleared on the surface some pipe is attached to, then the same update will be programmed again.
[How]
Clear the surface and stream update flags after applying the updates.
--- drivers/gpu/drm/amd/display/dc/core/dc.c | 45 +++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 11 deletions(-)
drivers/gpu/drm/amd/display/dc/core/dc.c +34 -11
@@ -5120,11 +5120,26 @@ static bool update_planes_and_stream_v3(return true; } +static void clear_update_flags (struct dc_surface_update *srf_updates, +int surface_count,struct dc_stream_state *stream) +{ +int i; + +if (stream) + stream->update_flags.raw =0 ; + +for (i =0 ; i < surface_count; i++) +if (srf_updates[i].surface) + srf_updates[i].surface->update_flags.raw =0 ; +} +bool dc_update_planes_and_stream (struct dc *dc,struct dc_surface_update *srf_updates,int surface_count,struct dc_stream_state *stream,struct dc_stream_update *stream_update) { +bool ret = false; +dc_exit_ips_for_hw_access (dc);/* * update planes and stream version 3 separates FULL and FAST updates
@@ -5141,10 +5156,16 @@ bool dc_update_planes_and_stream(struct* features as they are now transparent to the new sequence. */ if (dc->ctx->dce_version >=DCN_VERSION_4_01 ) -return update_planes_and_stream_v3 (dc, srf_updates, + ret =update_planes_and_stream_v3 (dc, srf_updates, surface_count, stream, stream_update); -return update_planes_and_stream_v2 (dc, srf_updates, +else + ret =update_planes_and_stream_v2 (dc, srf_updates, surface_count, stream, stream_update); + +if (ret) +clear_update_flags (srf_updates, surface_count, stream); + +return ret; } void dc_commit_updates_for_stream(struct dc *dc,
@@ -5154,6 +5175,8 @@ void dc_commit_updates_for_stream(structstruct dc_stream_update *stream_update, struct dc_state *state) { + bool ret = false; +dc_exit_ips_for_hw_access (dc);/* TODO: Since change commit sequence can have a huge impact, * we decided to only enable it for DCN3x. However, as soon as
@@ -5161,17 +5184,17 @@ void dc_commit_updates_for_stream(struct* the new sequence for all ASICs. */ if (dc->ctx->dce_version >=DCN_VERSION_4_01 ) { -update_planes_and_stream_v3 (dc, srf_updates, surface_count, + ret =update_planes_and_stream_v3 (dc, srf_updates, surface_count, stream, stream_update); -return ; - } -if (dc->ctx->dce_version >=DCN_VERSION_3_2 ) { -update_planes_and_stream_v2 (dc, srf_updates, surface_count, + }else if (dc->ctx->dce_version >=DCN_VERSION_3_2 ) { + ret =update_planes_and_stream_v2 (dc, srf_updates, surface_count, stream, stream_update); -return ; - } -update_planes_and_stream_v1 (dc, srf_updates, surface_count, stream, - stream_update, state); + }else + ret =update_planes_and_stream_v1 (dc, srf_updates, surface_count, stream, + stream_update, state); + +if (ret) +clear_update_flags (srf_updates, surface_count, stream); }uint8_t dc_get_current_stream_count (struct dc *dc)
Greg Kroah-Hartman
maintainerPATCH 173/214 drm/v3d: Stop the active perfmon before being destroyed
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maíra Canal <[email protected]>
commit 7d1fd3638ee3a9f9bca4785fffb638ca19120718 upstream.
When running kmscube with one or more performance monitors enabled via GALLIUM_HUD, the following kernel panic can occur:
[ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1
This issue arises because, upon closing the file descriptor (which happens when we interrupt kmscube), the active performance monitor is not stopped. Although all perfmons are destroyed in v3d_perfmon_close_file(), the active performance monitor's pointer (v3d->active_perfmon) is still retained.
If kmscube is run again, the driver will attempt to stop the active performance monitor using the stale pointer in v3d->active_perfmon. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed.
To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.
--- drivers/gpu/drm/v3d/v3d_perfmon.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/gpu/drm/v3d/v3d_perfmon.c +8 -1
@@ -289,6 +289,11 @@ void v3d_perfmon_open_file(struct v3d_fistatic int v3d_perfmon_idr_del (int id,void *elem,void *data) {struct v3d_perfmon *perfmon = elem; +struct v3d_dev *v3d = (struct v3d_dev *)data; + +/* If the active perfmon is being destroyed, stop it first */ +if (perfmon == v3d->active_perfmon) +v3d_perfmon_stop (v3d, perfmon, false);v3d_perfmon_put (perfmon);
@@ -297,8 +302,10 @@ static int v3d_perfmon_idr_del(int id, vvoid v3d_perfmon_close_file (struct v3d_file_priv *v3d_priv) { +struct v3d_dev *v3d = v3d_priv->v3d; +mutex_lock (&v3d_priv->perfmon.lock); -idr_for_each (&v3d_priv->perfmon.idr, v3d_perfmon_idr_del,NULL ); +idr_for_each (&v3d_priv->perfmon.idr, v3d_perfmon_idr_del, v3d);idr_destroy (&v3d_priv->perfmon.idr);mutex_unlock (&v3d_priv->perfmon.lock);mutex_destroy (&v3d_priv->perfmon.lock);
Greg Kroah-Hartman
maintainerPATCH 174/214 drm/vc4: Stop the active perfmon before being destroyed
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maíra Canal <[email protected]>
commit 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 upstream.
Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in vc4_perfmon_close_file(), the active performance monitor's pointer (vc4->active_perfmon) is still retained.
If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in vc4->active_perfmon. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed.
To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.
--- drivers/gpu/drm/vc4/vc4_perfmon.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/gpu/drm/vc4/vc4_perfmon.c +6 -1
@@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_fistatic int vc4_perfmon_idr_del (int id,void *elem,void *data) {struct vc4_perfmon *perfmon = elem; +struct vc4_dev *vc4 = (struct vc4_dev *)data; + +/* If the active perfmon is being destroyed, stop it first */ +if (perfmon == vc4->active_perfmon) +vc4_perfmon_stop (vc4, perfmon, false);vc4_perfmon_put (perfmon);
@@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_freturn ;mutex_lock (&vc4file->perfmon.lock); -idr_for_each (&vc4file->perfmon.idr, vc4_perfmon_idr_del,NULL ); +idr_for_each (&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4);idr_destroy (&vc4file->perfmon.idr);mutex_unlock (&vc4file->perfmon.lock);mutex_destroy (&vc4file->perfmon.lock);
Greg Kroah-Hartman
maintainerPATCH 175/214 drm/amdkfd: Fix an eviction fence leak
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lang Yu <[email protected]>
commit d7d7b947a4fa6d0a82ff2bf0db413edc63738e3a upstream.
Only creating a new reference for each process instead of each VM.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 7 +++++-- 2 files changed, 7 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +2 -2
@@ -1438,8 +1438,8 @@ static int init_kfd_vm(struct amdgpu_vmlist_add_tail (&vm->vm_list_node, &(vm->process_info->vm_list_head)); vm->process_info->n_vms++; - - *ef =dma_fence_get (&vm->process_info->eviction_fence->base); +if (ef) + *ef =dma_fence_get (&vm->process_info->eviction_fence->base);mutex_unlock (&vm->process_info->lock);return 0 ;
drivers/gpu/drm/amd/amdkfd/kfd_process.c +5 -2
@@ -1676,12 +1676,15 @@ int kfd_process_device_init_vm(struct kf ret =amdgpu_amdkfd_gpuvm_acquire_process_vm (dev->adev, avm, &p->kgd_process_info, - &ef); + p->ef ?NULL : &ef);if (ret) {dev_err (dev->adev->dev,"Failed to create process VM object\n" );return ret; } -RCU_INIT_POINTER (p->ef, ef); + +if (!p->ef) +RCU_INIT_POINTER (p->ef, ef); + pdd->drm_priv = drm_file->private_data; ret =kfd_process_device_reserve_ib_mem (pdd);
Greg Kroah-Hartman
maintainerPATCH 176/214 drm/amd/display: fix hibernate entry for DCN35+
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hamza Mahfooz <[email protected]>
commit 79bc412ef787cf25773d0ece93f8739ce0e6ac1e upstream.
Since, two suspend-resume cycles are required to enter hibernate and, since we only need to enable idle optimizations in the first cycle (which is pretty much equivalent to s2idle). We can check in_s0ix, to prevent the system from entering idle optimizations before it actually enters hibernate (from display's perspective). Also, call dc_set_power_state() before dc_allow_idle_optimizations(), since it's safer to do so because dc_set_power_state() writes to DMUB.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +4 -3
@@ -2950,10 +2950,11 @@ static int dm_suspend(void *handle)hpd_rx_irq_work_suspend (dm); -if (adev->dm.dc->caps.ips_support) -dc_allow_idle_optimizations (adev->dm.dc, true); -dc_set_power_state (dm->dc,DC_ACPI_CM_POWER_STATE_D3 ); + +if (dm->dc->caps.ips_support && adev->in_s0ix) +dc_allow_idle_optimizations (dm->dc, true); +dc_dmub_srv_set_power_state (dm->dc->ctx->dmub_srv,DC_ACPI_CM_POWER_STATE_D3 );return 0 ;
Greg Kroah-Hartman
maintainerPATCH 177/214 drm/xe/guc_submit: fix xa_store() error checking
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit 42465603a31089a89b5fe25966ecedb841eeaa0f upstream.
Looks like we are meant to use xa_err() to extract the error encoded in the ptr.
--- drivers/gpu/drm/xe/xe_guc_submit.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/gpu/drm/xe/xe_guc_submit.c +3 -6
@@ -393,7 +393,6 @@ static void __release_guc_id(struct xe_gstatic int alloc_guc_id (struct xe_guc *guc,struct xe_exec_queue *q) {int ret; -void *ptr;int i;/*
@@ -413,12 +412,10 @@ static int alloc_guc_id(struct xe_guc *g q->guc->id = ret;for (i =0 ; i < q->width; ++i) { - ptr =xa_store (&guc->submission_state.exec_queue_lookup, - q->guc->id + i, q,GFP_NOWAIT ); -if (IS_ERR (ptr)) { - ret =PTR_ERR (ptr); + ret =xa_err (xa_store (&guc->submission_state.exec_queue_lookup, + q->guc->id + i, q,GFP_NOWAIT )); +if (ret) goto err_release; - } }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 178/214 drm/i915/hdcp: fix connector refcounting
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
commit 4cc2718f621a6a57a02581125bb6d914ce74d23b upstream.
We acquire a connector reference before scheduling an HDCP prop work, and expect the work function to release the reference.
However, if the work was already queued, it won't be queued multiple times, and the reference is not dropped.
Release the reference immediately if the work was already queued.
--- drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/display/intel_hdcp.c +7 -3
@@ -1089,7 +1089,8 @@ static void intel_hdcp_update_value(stru hdcp->value = value;if (update_property) {drm_connector_get (&connector->base); -queue_work (i915->unordered_wq, &hdcp->prop_work); +if (!queue_work (i915->unordered_wq, &hdcp->prop_work)) +drm_connector_put (&connector->base); } }
@@ -2517,7 +2518,8 @@ void intel_hdcp_update_pipe(struct intelmutex_lock (&hdcp->mutex); hdcp->value =DRM_MODE_CONTENT_PROTECTION_DESIRED ;drm_connector_get (&connector->base); -queue_work (i915->unordered_wq, &hdcp->prop_work); +if (!queue_work (i915->unordered_wq, &hdcp->prop_work)) +drm_connector_put (&connector->base);mutex_unlock (&hdcp->mutex); }
@@ -2534,7 +2536,9 @@ void intel_hdcp_update_pipe(struct intel*/ if (!desired_and_not_enabled && !content_protection_type_changed) {drm_connector_get (&connector->base); -queue_work (i915->unordered_wq, &hdcp->prop_work); +if (!queue_work (i915->unordered_wq, &hdcp->prop_work)) +drm_connector_put (&connector->base); + } }
Greg Kroah-Hartman
maintainerPATCH 179/214 drm/xe/ct: prevent UAF in send_recv()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit db7f92af626178ba59dbbcdd5dee9ec24a987a88 upstream.
Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side.
v2 (Badal):
- Also print done after acquiring the lock and seeing timeout.
--- drivers/gpu/drm/xe/xe_guc_ct.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
drivers/gpu/drm/xe/xe_guc_ct.c +18 -3
@@ -894,16 +894,26 @@ retry_same_fence: } ret =wait_event_timeout (ct->g2h_fence_wq, g2h_fence.done,HZ ); + +/* +* Ensure we serialize with completion side to prevent UAF with fence going out of scope on +* the stack, since we have no clue if it will fire after the timeout before we can erase +* from the xa. Also we have some dependent loads and stores below for which we need the +* correct ordering, and we lack the needed barriers. +*/ +mutex_lock (&ct->lock);if (!ret) { -xe_gt_err (gt,"Timed out wait for G2H, fence %u, action %04x" , - g2h_fence.seqno, action[0 ]); +xe_gt_err (gt,"Timed out wait for G2H, fence %u, action %04x, done %s" , + g2h_fence.seqno, action[0 ],str_yes_no (g2h_fence.done));xa_erase_irq (&ct->fence_lookup, g2h_fence.seqno); +mutex_unlock (&ct->lock);return -ETIME ; }if (g2h_fence.retry) {xe_gt_dbg (gt,"H2G action %#x retrying: reason %#x\n" , action[0 ], g2h_fence.reason); +mutex_unlock (&ct->lock); goto retry; }if (g2h_fence.fail) {
@@ -912,7 +922,12 @@ retry_same_fence: ret = -EIO ; } -return ret >0 ? response_buffer ? g2h_fence.response_len : g2h_fence.response_data : ret; +if (ret >0 ) + ret = response_buffer ? g2h_fence.response_len : g2h_fence.response_data; + +mutex_unlock (&ct->lock); + +return ret; }/**
Greg Kroah-Hartman
maintainerPATCH 180/214 drm/xe/ct: fix xa_store() error checking
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit e863781abe4fe430406dd075ca0cab99165b4e63 upstream.
Looks like we are meant to use xa_err() to extract the error encoded in the ptr.
--- drivers/gpu/drm/xe/xe_guc_ct.c | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-)
drivers/gpu/drm/xe/xe_guc_ct.c +8 -15
@@ -658,16 +658,12 @@ static int __guc_ct_send_locked(struct x num_g2h =1 ;if (g2h_fence_needs_alloc (g2h_fence)) { -void *ptr; - g2h_fence->seqno =next_ct_seqno (ct, true); - ptr =xa_store (&ct->fence_lookup, - g2h_fence->seqno, - g2h_fence,GFP_ATOMIC ); -if (IS_ERR (ptr)) { - ret =PTR_ERR (ptr); + ret =xa_err (xa_store (&ct->fence_lookup, + g2h_fence->seqno, g2h_fence, +GFP_ATOMIC )); +if (ret) goto out; - } } seqno = g2h_fence->seqno;
@@ -870,14 +866,11 @@ retry: retry_same_fence: ret =guc_ct_send (ct, action, len,0 ,0 , &g2h_fence);if (unlikely (ret == -ENOMEM )) { -void *ptr; -/* Retry allocation /w GFP_KERNEL */ - ptr =xa_store (&ct->fence_lookup, - g2h_fence.seqno, - &g2h_fence,GFP_KERNEL ); -if (IS_ERR (ptr)) -return PTR_ERR (ptr); + ret =xa_err (xa_store (&ct->fence_lookup, g2h_fence.seqno, + &g2h_fence,GFP_KERNEL )); +if (ret) +return ret; goto retry_same_fence; }else if (unlikely (ret)) {
Greg Kroah-Hartman
maintainerPATCH 181/214 Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
commit 18fd04ad856df07733f5bb07e7f7168e7443d393 upstream.
This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace:
BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30
--- net/bluetooth/hci_conn.c | 3 +++ 1 file changed, 3 insertions(+)
net/bluetooth/hci_conn.c +3 -0
@@ -289,6 +289,9 @@ static int hci_enhanced_setup_sync(struckfree (conn_handle); +if (!hci_conn_valid (hdev, conn)) +return -ECANCELED ; +bt_dev_dbg (hdev,"hcon %p" , conn);configure_datapath_sync (hdev, &conn->codec);
Greg Kroah-Hartman
maintainerPATCH 182/214 thermal: core: Reference count the zone in thermal_zone_get_by_id()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
commit a42a5839f400e929c489bb1b58f54596c4535167 upstream.
There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().
To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.
--- drivers/thermal/thermal_core.c | 1 + drivers/thermal/thermal_core.h | 3 +++ drivers/thermal/thermal_netlink.c | 9 +++------ 3 files changed, 7 insertions(+), 6 deletions(-)
drivers/thermal/thermal_core.c +1 -0
@@ -737,6 +737,7 @@ struct thermal_zone_device *thermal_zonemutex_lock (&thermal_list_lock);list_for_each_entry (tz, &thermal_tz_list, node) {if (tz->id == id) { +get_device (&tz->device); match = tz;break ; }
drivers/thermal/thermal_core.h +3 -0
@@ -194,6 +194,9 @@ int for_each_thermal_governor(int (*cb)(struct thermal_zone_device *thermal_zone_get_by_id (int id); +DEFINE_CLASS(thermal_zone_get_by_id, struct thermal_zone_device *, + if (_T) put_device(&_T->device), thermal_zone_get_by_id(id), int id) +static inline bool cdev_is_power_actor (struct thermal_cooling_device *cdev) { return cdev->ops->get_requested_power && cdev->ops->state2power &&
drivers/thermal/thermal_netlink.c +3 -6
@@ -443,7 +443,6 @@ static int thermal_genl_cmd_tz_get_trip( {struct sk_buff *msg = p->msg;const struct thermal_trip_desc *td; -struct thermal_zone_device *tz;struct nlattr *start_trip;int id;
@@ -452,7 +451,7 @@ static int thermal_genl_cmd_tz_get_trip( id =nla_get_u32 (p->attrs[THERMAL_GENL_ATTR_TZ_ID ]); - tz =thermal_zone_get_by_id (id); +CLASS (thermal_zone_get_by_id, tz)(id);if (!tz)return -EINVAL ;
@@ -488,7 +487,6 @@ out_cancel_nest:static int thermal_genl_cmd_tz_get_temp (struct param *p) {struct sk_buff *msg = p->msg; -struct thermal_zone_device *tz;int temp, ret, id;if (!p->attrs[THERMAL_GENL_ATTR_TZ_ID ])
@@ -496,7 +494,7 @@ static int thermal_genl_cmd_tz_get_temp( id =nla_get_u32 (p->attrs[THERMAL_GENL_ATTR_TZ_ID ]); - tz =thermal_zone_get_by_id (id); +CLASS (thermal_zone_get_by_id, tz)(id);if (!tz)return -EINVAL ;
@@ -514,7 +512,6 @@ static int thermal_genl_cmd_tz_get_temp(static int thermal_genl_cmd_tz_get_gov (struct param *p) {struct sk_buff *msg = p->msg; -struct thermal_zone_device *tz;int id, ret =0 ;if (!p->attrs[THERMAL_GENL_ATTR_TZ_ID ])
@@ -522,7 +519,7 @@ static int thermal_genl_cmd_tz_get_gov(s id =nla_get_u32 (p->attrs[THERMAL_GENL_ATTR_TZ_ID ]); - tz =thermal_zone_get_by_id (id); +CLASS (thermal_zone_get_by_id, tz)(id);if (!tz)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 183/214 thermal: core: Free tzp copy along with the thermal zone
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
commit 827a07525c099f54d3b15110408824541ec66b3c upstream.
The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.
--- drivers/thermal/thermal_core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/thermal/thermal_core.c +1 -3
@@ -1647,14 +1647,12 @@ void thermal_zone_device_unregister(struida_destroy (&tz->ida);device_del (&tz->device); - -kfree (tz->tzp); -put_device (&tz->device);thermal_notify_tz_delete (tz);wait_for_completion (&tz->removal); +kfree (tz->tzp);kfree (tz); }EXPORT_SYMBOL_GPL (thermal_zone_device_unregister);
Greg Kroah-Hartman
maintainerPATCH 184/214 scsi: wd33c93: Dont use stale scsi_pointer value
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Palmer <[email protected]>
commit 9023ed8d91eb1fcc93e64dc4962f7412b1c4cbec upstream.
A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93:
Move the SCSI pointer to private command data") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.
--- drivers/scsi/wd33c93.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/wd33c93.c +1 -1
@@ -831,7 +831,7 @@ wd33c93_intr(struct Scsi_Host *instance)/* construct an IDENTIFY message with correct disconnect bit */ hostdata->outgoing_msg[0 ] =IDENTIFY (0 , cmd->device->lun); -if (scsi_pointer->phase) +if (WD33C93_scsi_pointer (cmd)->phase) hostdata->outgoing_msg[0 ] |=0x40 ;if (hostdata->sync_stat[cmd->device->id] ==SS_FIRST ) {
Greg Kroah-Hartman
maintainerPATCH 185/214 scsi: fnic: Move flush_work initialization out of if block
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Wilck <[email protected]>
commit f30e5f77d2f205ac14d09dec40fd4bb76712f13d upstream.
After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed.
The following warning is observed while the fnic driver is loaded:
kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: <IRQ> kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: </IRQ>
It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure.
This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().
--- drivers/scsi/fnic/fnic_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/fnic/fnic_main.c +1 -1
@@ -830,7 +830,6 @@ static int fnic_probe(struct pci_dev *pdspin_lock_init (&fnic->vlans_lock);INIT_WORK (&fnic->fip_frame_work, fnic_handle_fip_frame);INIT_WORK (&fnic->event_work, fnic_handle_event); -INIT_WORK (&fnic->flush_work, fnic_flush_tx);skb_queue_head_init (&fnic->fip_frame_queue);INIT_LIST_HEAD (&fnic->evlist);INIT_LIST_HEAD (&fnic->vlans);
@@ -948,6 +947,7 @@ static int fnic_probe(struct pci_dev *pdINIT_WORK (&fnic->link_work, fnic_handle_link);INIT_WORK (&fnic->frame_work, fnic_handle_frame); +INIT_WORK (&fnic->flush_work, fnic_flush_tx);skb_queue_head_init (&fnic->frame_queue);skb_queue_head_init (&fnic->tx_queue);
Greg Kroah-Hartman
maintainerPATCH 186/214 scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avri Altman <[email protected]>
commit d5130c5a093257aa4542aaded8034ef116a7624a upstream.
Replace manual offset calculations for response_upiu and prd_table in ufshcd_init_lrb() with pre-calculated offsets already stored in the utp_transfer_req_desc structure. The pre-calculated offsets are set differently in ufshcd_host_memory_configure() based on the UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk, ensuring correct alignment and access.
--- drivers/ufs/core/ufshcd.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/ufs/core/ufshcd.c +2 -3
@@ -2920,9 +2920,8 @@ static void ufshcd_init_lrb(struct ufs_hstruct utp_transfer_req_desc *utrdlp = hba->utrdl_base_addr;dma_addr_t cmd_desc_element_addr = hba->ucdl_dma_addr + i *ufshcd_get_ucd_size (hba); -u16 response_offset = offsetof(struct utp_transfer_cmd_desc , - response_upiu); -u16 prdt_offset = offsetof(struct utp_transfer_cmd_desc , prd_table); +u16 response_offset =le16_to_cpu (utrdlp[i].response_upiu_offset); +u16 prdt_offset =le16_to_cpu (utrdlp[i].prd_table_offset); lrb->utr_descriptor_ptr = utrdlp + i; lrb->utrd_dma_addr = hba->utrdl_dma_addr +
Greg Kroah-Hartman
maintainerPATCH 187/214 Revert "mmc: mvsdio: Use sg_miter for PIO"
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <[email protected]>
commit 5b35746a0fdc73063a4c7fc6208b7abd644f9ef5 upstream.
This reverts commit 2761822c00e8c271f10a10affdbd4917d900d7ea.
When testing on real hardware the patch does not work. Revert, try to acquire real hardware, and retry. These systems typically don't have highmem anyway so the impact is likely zero.
--- drivers/mmc/host/mvsdio.c | 71 ++++++++++----------------------------- 1 file changed, 18 insertions(+), 53 deletions(-)
drivers/mmc/host/mvsdio.c +18 -53
@@ -38,9 +38,8 @@ struct mvsd_host {unsigned int xfer_mode;unsigned int intr_en;unsigned int ctrl; -bool use_pio; -struct sg_mapping_iter sg_miter;unsigned int pio_size; +void *pio_ptr;unsigned int sg_frags;unsigned int ns_per_clk;unsigned int clock;
@@ -115,18 +114,11 @@ static int mvsd_setup_data(struct mvsd_host *host, struct mmc_data *data)* data when the buffer is not aligned on a 64 byte * boundary. */ -unsigned int miter_flags =SG_MITER_ATOMIC ;/* Used from IRQ */ - -if (data->flags &MMC_DATA_READ ) - miter_flags |=SG_MITER_TO_SG ; -else - miter_flags |=SG_MITER_FROM_SG ; - host->pio_size = data->blocks * data->blksz; -sg_miter_start (&host->sg_miter, data->sg, data->sg_len, miter_flags); + host->pio_ptr =sg_virt (data->sg);if (!nodma) -dev_dbg (host->dev,"fallback to PIO for data\n" ); - host->use_pio = true; +dev_dbg (host->dev,"fallback to PIO for data at 0x%p size %d\n" , + host->pio_ptr, host->pio_size);return 1 ; }else {dma_addr_t phys_addr;
@@ -137,7 +129,6 @@ static int mvsd_setup_data(struct mvsd_host *host, struct mmc_data *data) phys_addr =sg_dma_address (data->sg);mvsd_write (MVSD_SYS_ADDR_LOW , (u32 )phys_addr &0xffff );mvsd_write (MVSD_SYS_ADDR_HI , (u32 )phys_addr >>16 ); - host->use_pio = false;return 0 ; } }
@@ -297,8 +288,8 @@ static u32 mvsd_finish_data(struct mvsd_host *host, struct mmc_data *data, {void __iomem *iobase = host->base; -if (host->use_pio) { -sg_miter_stop (&host->sg_miter); +if (host->pio_ptr) { + host->pio_ptr =NULL ; host->pio_size =0 ; }else { dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->sg_frags,
@@ -353,12 +344,9 @@ static u32 mvsd_finish_data(struct mvsd_host *host, struct mmc_data *data,static irqreturn_t mvsd_irq (int irq,void *dev) {struct mvsd_host *host = dev; -struct sg_mapping_iter *sgm = &host->sg_miter;void __iomem *iobase = host->base;u32 intr_status, intr_done_mask;int irq_handled =0 ; -u16 *p; -int s; intr_status =mvsd_read (MVSD_NOR_INTR_STATUS ); dev_dbg(host->dev, "intr 0x%04x intr_en 0x%04x hw_state 0x%04x\n",
@@ -382,36 +370,15 @@ static irqreturn_t mvsd_irq(int irq, void *dev)spin_lock (&host->lock);/* PIO handling, if needed. Messy business... */ -if (host->use_pio) { -/* -* As we set sgm->consumed this always gives a valid buffer -* position. -*/ -if (!sg_miter_next (sgm)) { -/* This should not happen */ -dev_err (host->dev,"ran out of scatter segments\n" ); -spin_unlock (&host->lock); - host->intr_en &= - ~(MVSD_NOR_RX_READY |MVSD_NOR_RX_FIFO_8W | -MVSD_NOR_TX_AVAIL |MVSD_NOR_TX_FIFO_8W ); -mvsd_write (MVSD_NOR_INTR_EN , host->intr_en); -return IRQ_HANDLED ; - } - p = sgm->addr; - s = sgm->length; -if (s > host->pio_size) - s = host->pio_size; - } - -if (host->use_pio && +if (host->pio_size && (intr_status & host->intr_en & (MVSD_NOR_RX_READY |MVSD_NOR_RX_FIFO_8W ))) { - +u16 *p = host->pio_ptr; +int s = host->pio_size;while (s >=32 && (intr_status &MVSD_NOR_RX_FIFO_8W )) {readsw (iobase +MVSD_FIFO , p,16 ); p +=16 ; s -=32 ; - sgm->consumed +=32 ; intr_status =mvsd_read (MVSD_NOR_INTR_STATUS ); }/*
@@ -424,7 +391,6 @@ static irqreturn_t mvsd_irq(int irq, void *dev)put_unaligned (mvsd_read (MVSD_FIFO ), p++);put_unaligned (mvsd_read (MVSD_FIFO ), p++); s -=4 ; - sgm->consumed +=4 ; intr_status =mvsd_read (MVSD_NOR_INTR_STATUS ); }if (s && s <4 && (intr_status &MVSD_NOR_RX_READY )) {
@@ -432,13 +398,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev) val[0 ] =mvsd_read (MVSD_FIFO ); val[1 ] =mvsd_read (MVSD_FIFO );memcpy (p, ((void *)&val) +4 - s, s); - sgm->consumed += s; s =0 ; intr_status =mvsd_read (MVSD_NOR_INTR_STATUS ); } -/* PIO transfer done */ - host->pio_size -= sgm->consumed; -if (host->pio_size ==0 ) { +if (s ==0 ) { host->intr_en &= ~(MVSD_NOR_RX_READY |MVSD_NOR_RX_FIFO_8W );mvsd_write (MVSD_NOR_INTR_EN , host->intr_en);
@@ -450,10 +413,14 @@ static irqreturn_t mvsd_irq(int irq, void *dev) }dev_dbg (host->dev,"pio %d intr 0x%04x hw_state 0x%04x\n" , s, intr_status,mvsd_read (MVSD_HW_STATE )); + host->pio_ptr = p; + host->pio_size = s; irq_handled =1 ; - }else if (host->use_pio && + }else if (host->pio_size && (intr_status & host->intr_en & (MVSD_NOR_TX_AVAIL |MVSD_NOR_TX_FIFO_8W ))) { +u16 *p = host->pio_ptr; +int s = host->pio_size;/* * The TX_FIFO_8W bit is unreliable. When set, bursting * 16 halfwords all at once in the FIFO drops data. Actually
@@ -464,7 +431,6 @@ static irqreturn_t mvsd_irq(int irq, void *dev)mvsd_write (MVSD_FIFO ,get_unaligned (p++));mvsd_write (MVSD_FIFO ,get_unaligned (p++)); s -=4 ; - sgm->consumed +=4 ; intr_status =mvsd_read (MVSD_NOR_INTR_STATUS ); }if (s <4 ) {
@@ -473,13 +439,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev)memcpy (((void *)&val) +4 - s, p, s);mvsd_write (MVSD_FIFO , val[0 ]);mvsd_write (MVSD_FIFO , val[1 ]); - sgm->consumed += s; s =0 ; intr_status =mvsd_read (MVSD_NOR_INTR_STATUS ); } -/* PIO transfer done */ - host->pio_size -= sgm->consumed; -if (host->pio_size ==0 ) { +if (s ==0 ) { host->intr_en &= ~(MVSD_NOR_TX_AVAIL |MVSD_NOR_TX_FIFO_8W );mvsd_write (MVSD_NOR_INTR_EN , host->intr_en);
@@ -487,6 +450,8 @@ static irqreturn_t mvsd_irq(int irq, void *dev) }dev_dbg (host->dev,"pio %d intr 0x%04x hw_state 0x%04x\n" , s, intr_status,mvsd_read (MVSD_HW_STATE )); + host->pio_ptr = p; + host->pio_size = s; irq_handled =1 ; }
Signature · 1 line
2.47.0
Greg Kroah-Hartman
maintainerPATCH 188/214 mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Wilczynski <[email protected]>
commit 27e8fe0da3b75520edfba9cee0030aeb5aef1505 upstream.
While working with the T-Head 1520 LicheePi4A SoC, certain conditions arose that allowed me to reproduce a race issue in the sdhci code.
To reproduce the bug, you need to enable the sdio1 controller in the device tree file arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi as follows:
&sdio1 {
bus-width = <4>;
max-frequency = <100000000>;
no-sd;
no-mmc;
broken-cd;
cap-sd-highspeed;
post-power-on-delay-ms = <50>;
status = "okay";
wakeup-source;
keep-power-in-suspend;
};When resetting the SoC using the reset button, the following messages appear in the dmesg log:
[ 8.164898] mmc2: Got command interrupt 0x00000001 even though no command operation was in progress. [ 8.174054] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 8.180503] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00000005 [ 8.186950] mmc2: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000 [ 8.193395] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 [ 8.199841] mmc2: sdhci: Present: 0x03da0000 | Host ctl: 0x00000000 [ 8.206287] mmc2: sdhci: Power: 0x0000000f | Blk gap: 0x00000000 [ 8.212733] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x0000decf [ 8.219178] mmc2: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000 [ 8.225622] mmc2: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 [ 8.232068] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 [ 8.238513] mmc2: sdhci: Caps: 0x3f69c881 | Caps_1: 0x08008177 [ 8.244959] mmc2: sdhci: Cmd: 0x00000502 | Max curr: 0x00191919 [ 8.254115] mmc2: sdhci: Resp[0]: 0x00001009 | Resp[1]: 0x00000000 [ 8.260561] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 8.267005] mmc2: sdhci: Host ctl2: 0x00001000 [ 8.271453] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000 [ 8.278594] mmc2: sdhci: ============================================
I also enabled some traces to better understand the problem:
kworker/3:1-62 [003] ..... 8.163538: mmc_request_start:
mmc2: start struct mmc_request[000000000d30cc0c]: cmd_opcode=5 cmd_arg=0x0 cmd_flags=0x2e1 cmd_retries=0 stop_opcode=0 stop_arg=0x0 stop_flags=0x0 stop_retries=0 sbc_opcode=0 sbc_arg=0x0 sbc_flags=0x0 sbc_retires=0 blocks=0 block_size=0 blk_addr=0 data_flags=0x0 tag=0 can_retune=0 doing_retune=0 retune_now=0 need_retune=0 hold_retune=1 retune_period=0
<idle>-0 [000] d.h2. 8.164816: sdhci_cmd_irq:
hw_name=ffe70a0000.mmc quirks=0x2008008 quirks2=0x8 intmask=0x10000
intmask_p=0x18000
irq/24-mmc2-96 [000] ..... 8.164840: sdhci_thread_irq:
msg=
irq/24-mmc2-96 [000] d.h2. 8.164896: sdhci_cmd_irq:
hw_name=ffe70a0000.mmc quirks=0x2008008 quirks2=0x8 intmask=0x1
intmask_p=0x1
irq/24-mmc2-96 [000] ..... 8.285142: mmc_request_done:mmc2: end struct mmc_request[000000000d30cc0c]: cmd_opcode=5 cmd_err=-110 cmd_resp=0x0 0x0 0x0 0x0 cmd_retries=0 stop_opcode=0 stop_err=0 stop_resp=0x0 0x0 0x0 0x0 stop_retries=0 sbc_opcode=0 sbc_err=0 sbc_resp=0x0 0x0 0x0 0x0 sbc_retries=0 bytes_xfered=0 data_err=0 tag=0 can_retune=0 doing_retune=0 retune_now=0 need_retune=0 hold_retune=1 retune_period=0
Here's what happens: the __mmc_start_request function is called with opcode 5. Since the power to the Wi-Fi card, which resides on this SDIO bus, is initially off after the reset, an interrupt SDHCI_INT_TIMEOUT is triggered. Immediately after that, a second interrupt SDHCI_INT_RESPONSE is triggered. Depending on the exact timing, these conditions can trigger the following race problem:
1) The sdhci_cmd_irq top half handles the command as an error. It sets host->cmd to NULL and host->pending_reset to true.
2) The sdhci_thread_irq bottom half is scheduled next and executes faster than the second interrupt handler for SDHCI_INT_RESPONSE. It clears host->pending_reset before the SDHCI_INT_RESPONSE handler runs.
3) The pending interrupt SDHCI_INT_RESPONSE handler gets called, triggering a code path that prints: "mmc2: Got command interrupt 0x00000001 even though no command operation was in progress."
To solve this issue, we need to clear pending interrupts when resetting host->pending_reset. This ensures that after sdhci_threaded_irq restores interrupts, there are no pending stale interrupts.
The behavior observed here is non-compliant with the SDHCI standard. Place the code in the sdhci-of-dwcmshc driver to account for a hardware-specific quirk instead of the core SDHCI code.
--- drivers/mmc/host/sdhci-of-dwcmshc.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/mmc/host/sdhci-of-dwcmshc.c +8 -0
@@ -746,6 +746,14 @@ static void th1520_sdhci_reset(struct sdsdhci_reset (host, mask); +/* The T-Head 1520 SoC does not comply with the SDHCI specification +* regarding the "Software Reset for CMD line should clear 'Command +* Complete' in the Normal Interrupt Status Register." Clear the bit +* here to compensate for this quirk. +*/ +if (mask &SDHCI_RESET_CMD ) +sdhci_writel (host,SDHCI_INT_RESPONSE ,SDHCI_INT_STATUS ); +if (priv->flags &FLAG_IO_FIXED_1V8 ) { ctrl_2 =sdhci_readw (host,SDHCI_HOST_CONTROL2 );if (!(ctrl_2 &SDHCI_CTRL_VDD_180 )) {
Greg Kroah-Hartman
maintainerPATCH 189/214 mptcp: fallback when MPTCP opts are dropped after 1st data
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 119d51e225febc8152476340a880f5415a01e99e upstream.
As reported by Christoph [1], before this patch, an MPTCP connection was wrongly reset when a host received a first data packet with MPTCP options after the 3wHS, but got the next ones without.
According to the MPTCP v1 specs [2], a fallback should happen in this case, because the host didn't receive a DATA_ACK from the other peer, nor receive data for more than the initial window which implies a DATA_ACK being received by the other peer.
The patch here re-uses the same logic as the one used in other places:
by looking at allow_infinite_fallback, which is disabled at the creation of an additional subflow. It's not looking at the first DATA_ACK (or implying one received from the other side) as suggested by the RFC, but it is in continuation with what was already done, which is safer, and it fixes the reported issue. The next step, looking at this first DATA_ACK, is tracked in [4].
This patch has been validated using the following Packetdrill script:
0 socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
// 3WHS is OK
+0.0 < S 0:0(0) win 65535 <mss 1460, sackOK, nop, nop, nop, wscale 6, mpcapable v1 flags[flag_h] nokey>
+0.0 > S. 0:0(0) ack 1 <mss 1460, nop, nop, sackOK, nop, wscale 8, mpcapable v1 flags[flag_h] key[skey]>
+0.1 < . 1:1(0) ack 1 win 2048 <mpcapable v1 flags[flag_h] key[ckey=2, skey]>
+0 accept(3, ..., ...) = 4
// Data from the client with valid MPTCP options (no DATA_ACK: normal)
+0.1 < P. 1:501(500) ack 1 win 2048 <mpcapable v1 flags[flag_h] key[skey, ckey] mpcdatalen 500, nop, nop> // From here, the MPTCP options will be dropped by a middlebox
+0.0 > . 1:1(0) ack 501 <dss dack8=501 dll=0 nocs>
+0.1 read(4, ..., 500) = 500
+0 write(4, ..., 100) = 100
// The server replies with data, still thinking MPTCP is being used
+0.0 > P. 1:101(100) ack 501 <dss dack8=501 dsn8=1 ssn=1 dll=100 nocs, nop, nop>
// But the client already did a fallback to TCP, because the two previous packets have been received without MPTCP options
+0.1 < . 501:501(0) ack 101 win 2048
+0.0 < P. 501:601(100) ack 101 win 2048
// The server should fallback to TCP, not reset: it didn't get a DATA_ACK, nor data for more than the initial window
+0.0 > . 101:101(0) ack 601
Note that this script requires Packetdrill with MPTCP support, see [3].
--- net/mptcp/subflow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mptcp/subflow.c +1 -1
@@ -1276,7 +1276,7 @@ static bool subflow_can_fallback(structelse if (READ_ONCE (msk->csum_enabled))return !subflow->valid_csum_seen;else -return !subflow->fully_established; +return READ_ONCE (msk->allow_infinite_fallback); }static void mptcp_subflow_fail (struct mptcp_sock *msk,struct sock *ssk)
Greg Kroah-Hartman
maintainerPATCH 190/214 ata: libata: avoid superfluous disk spin down + spin up during hibernation
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
commit a38719e3157118428e34fbd45b0d0707a5877784 upstream.
A user reported that commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") introduced a spin down + immediate spin up of the disk both when entering and when resuming from hibernation. This behavior was not there before, and causes an increased latency both when entering and when resuming from hibernation.
Hibernation is done by three consecutive PM events, in the following order:
1) PM_EVENT_FREEZE
2) PM_EVENT_THAW
3) PM_EVENT_HIBERNATE
Commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") modified ata_eh_handle_port_suspend() to call ata_dev_power_set_standby() (which spins down the disk), for both event PM_EVENT_FREEZE and event PM_EVENT_HIBERNATE.
Documentation/driver-api/pm/devices.rst, section "Entering Hibernation", explicitly mentions that PM_EVENT_FREEZE does not have to be put the device in a low-power state, and actually recommends not doing so. Thus, let's not spin down the disk on PM_EVENT_FREEZE. (The disk will instead be spun down during the subsequent PM_EVENT_HIBERNATE event.)
This way, PM_EVENT_FREEZE will behave as it did before commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop"), while PM_EVENT_HIBERNATE will continue to spin down the disk.
This will avoid the superfluous spin down + spin up when entering and resuming from hibernation, while still making sure that the disk is spun down before actually entering hibernation.
--- drivers/ata/libata-eh.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
drivers/ata/libata-eh.c +14 -4
@@ -4059,10 +4059,20 @@ static void ata_eh_handle_port_suspend(sWARN_ON (ap->pflags &ATA_PFLAG_SUSPENDED ); -/* Set all devices attached to the port in standby mode */ -ata_for_each_link (link, ap,HOST_FIRST ) { -ata_for_each_dev (dev, link,ENABLED ) -ata_dev_power_set_standby (dev); +/* +* We will reach this point for all of the PM events: +* PM_EVENT_SUSPEND (if runtime pm, PM_EVENT_AUTO will also be set) +* PM_EVENT_FREEZE, and PM_EVENT_HIBERNATE. +* +* We do not want to perform disk spin down for PM_EVENT_FREEZE. +* (Spin down will be performed by the subsequent PM_EVENT_HIBERNATE.) +*/ +if (!(ap->pm_mesg.event &PM_EVENT_FREEZE )) { +/* Set all devices attached to the port in standby mode */ +ata_for_each_link (link, ap,HOST_FIRST ) { +ata_for_each_dev (dev, link,ENABLED ) +ata_dev_power_set_standby (dev); + } }/*
Greg Kroah-Hartman
maintainerPATCH 191/214 OPP: fix error code in dev_pm_opp_set_config()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit eb8333673e1ebc2418980b664a84c91b4e98afc4 upstream.
This is an error path so set the error code. Smatch complains about the current code:
drivers/opp/core.c:2660 dev_pm_opp_set_config()
error: uninitialized symbol 'ret'.
--- drivers/opp/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/opp/core.c +3 -1
@@ -2630,8 +2630,10 @@ int dev_pm_opp_set_config(struct device *dev, struct dev_pm_opp_config *config)/* Attach genpds */ if (config->genpd_names) { -if (config->required_devs) +if (config->required_devs) { + ret = -EINVAL ; goto err; + } ret =_opp_attach_genpd (opp_table, dev, config->genpd_names, config->virt_devs);
Signature · 1 line
2.47.0
Greg Kroah-Hartman
maintainerPATCH 192/214 net: explicitly clear the sk pointer, when pf->create fails
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ignat Korchagin <[email protected]>
commit 631083143315d1b192bd7d915b967b37819e88ea upstream.
We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths.
For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object.
While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake.
So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.
--- net/socket.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
net/socket.c +6 -1
@@ -1569,8 +1569,13 @@ int __sock_create(struct net *net, int frcu_read_unlock (); err = pf->create (net, sock, protocol, kern); -if (err <0 ) +if (err <0 ) { +/* ->create should release the allocated sock->sk object on error +* but it may leave the dangling pointer +*/ + sock->sk =NULL ; goto out_module_put; + }/* * Now to bump the refcnt of the [loadable] module that owns this
Greg Kroah-Hartman
maintainerPATCH 193/214 net: Fix an unsafe loop on the list
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anastasia Kovaleva <[email protected]>
commit 1dae9f1187189bc09ff6d25ca97ead711f7e26f9 upstream.
The kernel may crash when deleting a genetlink family if there are still listeners for that family:
Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0
Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.
--- include/net/sock.h | 2 ++ net/netlink/af_netlink.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-)
include/net/sock.h +2 -0
@@ -892,6 +892,8 @@ static inline void sk_add_bind_node(stru hlist_for_each_entry_safe(__sk, tmp, list, sk_node)#define sk_for_each_bound (__sk, list) \ hlist_for_each_entry(__sk, list, sk_bind_node) +#define sk_for_each_bound_safe (__sk, tmp, list) \ + hlist_for_each_entry_safe(__sk, tmp, list, sk_bind_node)/** * sk_for_each_entry_offset_rcu - iterate over a list at a given struct offset
net/netlink/af_netlink.c +2 -1
@@ -2136,8 +2136,9 @@ void __netlink_clear_multicast_users(str {struct sock *sk;struct netlink_table *tbl = &nl_table[ksk->sk_protocol]; +struct hlist_node *tmp; -sk_for_each_bound (sk, &tbl->mc_list) +sk_for_each_bound_safe (sk, tmp, &tbl->mc_list)netlink_update_socket_mc (nlk_sk (sk), group,0 ); }
Greg Kroah-Hartman
maintainerPATCH 194/214 net: dsa: lan9303: ensure chip reset and wait for READY status
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anatolij Gustschin <[email protected]>
commit 5c14e51d2d7df49fe0d4e64a12c58d2542f452ff upstream.
Accessing device registers seems to be not reliable, the chip revision is sometimes detected wrongly (0 instead of expected 1).
Ensure that the chip reset is performed via reset GPIO and then wait for 'Device Ready' status in HW_CFG register before doing any register initializations.
--- drivers/net/dsa/lan9303-core.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
drivers/net/dsa/lan9303-core.c +29 -0
@@ -6,6 +6,7 @@#include <linux/module.h> #include <linux/gpio/consumer.h> #include <linux/regmap.h> +#include <linux/iopoll.h> #include <linux/mutex.h> #include <linux/mii.h> #include <linux/of.h>
@@ -839,6 +840,8 @@ static void lan9303_handle_reset(structif (!chip->reset_gpio)return ; +gpiod_set_value_cansleep (chip->reset_gpio,1 ); +if (chip->reset_duration !=0 )msleep (chip->reset_duration);
@@ -864,8 +867,34 @@ static int lan9303_disable_processing(ststatic int lan9303_check_device (struct lan9303 *chip) {int ret; +int err;u32 reg; +/* In I2C-managed configurations this polling loop will clash with +* switch's reading of EEPROM right after reset and this behaviour is +* not configurable. While lan9303_read() already has quite long retry +* timeout, seems not all cases are being detected as arbitration error. +* +* According to datasheet, EEPROM loader has 30ms timeout (in case of +* missing EEPROM). +* +* Loading of the largest supported EEPROM is expected to take at least +* 5.9s. +*/ + err =read_poll_timeout (lan9303_read, ret, + !ret && reg &LAN9303_HW_CFG_READY , +20000 ,6000000 , false, + chip->regmap,LAN9303_HW_CFG , ®); +if (ret) { +dev_err (chip->dev,"failed to read HW_CFG reg: %pe\n" , +ERR_PTR (ret)); +return ret; + } +if (err) { +dev_err (chip->dev,"HW_CFG not ready: 0x%08x\n" , reg); +return err; + } + ret =lan9303_read (chip->regmap,LAN9303_CHIP_REV , ®);if (ret) { dev_err(chip->dev, "failed to read chip revision register: %d\n",
Greg Kroah-Hartman
maintainerPATCH 195/214 net: phy: Remove LED entry from LEDs list on unregister
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Marangi <[email protected]>
commit f50b5d74c68e551667e265123659b187a30fe3a5 upstream.
Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list.
This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed.
On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again.
On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again.
This cause a kernel panic as the first 2 element should have been removed.
Fix this by correctly removing the element when LED is unregistered.
--- drivers/net/phy/phy_device.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/phy/phy_device.c +3 -2
@@ -3249,10 +3249,11 @@ static __maybe_unused int phy_led_hw_is_static void phy_leds_unregister (struct phy_device *phydev) { -struct phy_led *phyled; +struct phy_led *phyled, *tmp; -list_for_each_entry (phyled, &phydev->leds, list) { +list_for_each_entry_safe (phyled, tmp, &phydev->leds, list) {led_classdev_unregister (&phyled->led_cdev); +list_del (&phyled->list); } }
Greg Kroah-Hartman
maintainerPATCH 196/214 net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
commit a6ad589c1d118f9d5b1bc4c6888d42919f830340 upstream.
All MMD reads return 0 for the RTL8126A-integrated PHY. Therefore phylib assumes it doesn't support EEE, what results in higher power consumption, and a significantly higher chip temperature in my case.
To fix this split out the PHY driver for the RTL8126A-integrated PHY and set the read_mmd/write_mmd callbacks to read from vendor-specific registers.
--- drivers/net/phy/realtek.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
drivers/net/phy/realtek.c +23 -1
@@ -1081,6 +1081,16 @@ static int rtl8221b_vn_cg_c45_match_phy_device(struct phy_device *phydev)return rtlgen_is_c45_match (phydev,RTL_8221B_VN_CG , true); } +static int rtl8251b_c22_match_phy_device (struct phy_device *phydev) +{ +return rtlgen_is_c45_match (phydev,RTL_8251B , false); +} + +static int rtl8251b_c45_match_phy_device (struct phy_device *phydev) +{ +return rtlgen_is_c45_match (phydev,RTL_8251B , true); +} +static int rtlgen_resume (struct phy_device *phydev) {int ret =genphy_resume (phydev);
@@ -1418,7 +1428,7 @@ static struct phy_driver realtek_drvs[] = { .suspend = genphy_c45_pma_suspend, .resume = rtlgen_c45_resume, }, { - PHY_ID_MATCH_EXACT(0x001cc862), + .match_phy_device = rtl8251b_c45_match_phy_device, .name = "RTL8251B 5Gbps PHY", .get_features = rtl822x_get_features, .config_aneg = rtl822x_config_aneg,
@@ -1427,6 +1437,18 @@ static struct phy_driver realtek_drvs[] = { .resume = rtlgen_resume, .read_page = rtl821x_read_page, .write_page = rtl821x_write_page, + }, { + .match_phy_device = rtl8251b_c22_match_phy_device, + .name = "RTL8126A-internal 5Gbps PHY", + .get_features = rtl822x_get_features, + .config_aneg = rtl822x_config_aneg, + .read_status = rtl822x_read_status, + .suspend = genphy_suspend, + .resume = rtlgen_resume, + .read_page = rtl821x_read_page, + .write_page = rtl821x_write_page, + .read_mmd = rtl822x_read_mmd, + .write_mmd = rtl822x_write_mmd, }, {PHY_ID_MATCH_EXACT (0x001ccad0 ), .name = "RTL8224 2.5Gbps PHY",
Signature · 1 line
2.47.0
Greg Kroah-Hartman
maintainerPATCH 197/214 mptcp: handle consistently DSS corruption
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit e32d262c89e2b22cb0640223f953b548617ed8a6 upstream.
Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.
--- net/mptcp/mib.c | 2 ++ net/mptcp/mib.h | 2 ++ net/mptcp/protocol.c | 24 +++++++++++++++++++++--- net/mptcp/subflow.c | 4 +++- 4 files changed, 28 insertions(+), 4 deletions(-)
net/mptcp/mib.c +2 -0
@@ -26,6 +26,8 @@ static const struct snmp_mib mptcp_snmp_SNMP_MIB_ITEM ("MPJoinAckRx" ,MPTCP_MIB_JOINACKRX ),SNMP_MIB_ITEM ("MPJoinAckHMacFailure" ,MPTCP_MIB_JOINACKMAC ),SNMP_MIB_ITEM ("DSSNotMatching" ,MPTCP_MIB_DSSNOMATCH ), +SNMP_MIB_ITEM ("DSSCorruptionFallback" ,MPTCP_MIB_DSSCORRUPTIONFALLBACK ), +SNMP_MIB_ITEM ("DSSCorruptionReset" ,MPTCP_MIB_DSSCORRUPTIONRESET ),SNMP_MIB_ITEM ("InfiniteMapTx" ,MPTCP_MIB_INFINITEMAPTX ),SNMP_MIB_ITEM ("InfiniteMapRx" ,MPTCP_MIB_INFINITEMAPRX ), SNMP_MIB_ITEM("DSSNoMatchTCP", MPTCP_MIB_DSSTCPMISMATCH),
net/mptcp/mib.h +2 -0
@@ -21,6 +21,8 @@ enum linux_mptcp_mib_field {MPTCP_MIB_JOINACKRX ,/* Received an ACK + MP_JOIN */ MPTCP_MIB_JOINACKMAC ,/* HMAC was wrong on ACK + MP_JOIN */ MPTCP_MIB_DSSNOMATCH ,/* Received a new mapping that did not match the previous one */ +MPTCP_MIB_DSSCORRUPTIONFALLBACK ,/* DSS corruption detected, fallback */ +MPTCP_MIB_DSSCORRUPTIONRESET ,/* DSS corruption detected, MPJ subflow reset */ MPTCP_MIB_INFINITEMAPTX ,/* Sent an infinite mapping */ MPTCP_MIB_INFINITEMAPRX ,/* Received an infinite mapping */ MPTCP_MIB_DSSTCPMISMATCH, /* DSS-mapping did not map with TCP's sequence numbers */
net/mptcp/protocol.c +21 -3
@@ -620,6 +620,18 @@ static bool mptcp_check_data_fin(structreturn ret; } +static void mptcp_dss_corruption (struct mptcp_sock *msk,struct sock *ssk) +{ +if (READ_ONCE (msk->allow_infinite_fallback)) { +MPTCP_INC_STATS (sock_net (ssk), +MPTCP_MIB_DSSCORRUPTIONFALLBACK ); +mptcp_do_fallback (ssk); + }else { +MPTCP_INC_STATS (sock_net (ssk),MPTCP_MIB_DSSCORRUPTIONRESET ); +mptcp_subflow_reset (ssk); + } +} +static bool __mptcp_move_skbs_from_subflow (struct mptcp_sock *msk,struct sock *ssk,unsigned int *bytes)
@@ -692,10 +704,16 @@ static bool __mptcp_move_skbs_from_subfl moved += len; seq += len; -if (WARN_ON_ONCE (map_remaining < len)) -break ; +if (unlikely (map_remaining < len)) { +DEBUG_NET_WARN_ON_ONCE (1 ); +mptcp_dss_corruption (msk, ssk); + } }else { -WARN_ON_ONCE (!fin); +if (unlikely (!fin)) { +DEBUG_NET_WARN_ON_ONCE (1 ); +mptcp_dss_corruption (msk, ssk); + } +sk_eat_skb (ssk, skb); done = true; }
net/mptcp/subflow.c +3 -1
@@ -971,8 +971,10 @@ static bool skb_is_fully_mapped(struct sunsigned int skb_consumed; skb_consumed =tcp_sk (ssk)->copied_seq -TCP_SKB_CB (skb)->seq; -if (WARN_ON_ONCE (skb_consumed >= skb->len)) +if (unlikely (skb_consumed >= skb->len)) { +DEBUG_NET_WARN_ON_ONCE (1 );return true; + }return skb->len - skb_consumed <= subflow->map_data_len -mptcp_subflow_get_map_offset (subflow);
Greg Kroah-Hartman
maintainerPATCH 198/214 mptcp: pm: do not remove closing subflows
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit db0a37b7ac27d8ca27d3dc676a16d081c16ec7b9 upstream.
In a previous fix, the in-kernel path-manager has been modified not to retrigger the removal of a subflow if it was already closed, e.g. when the initial subflow is removed, but kept in the subflows list.
To be complete, this fix should also skip the subflows that are in any closing state: mptcp_close_ssk() will initiate the closure, but the switch to the TCP_CLOSE state depends on the other peer.
--- net/mptcp/pm_netlink.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/mptcp/pm_netlink.c +2 -1
@@ -856,7 +856,8 @@ static void mptcp_pm_nl_rm_addr_or_subflint how =RCV_SHUTDOWN |SEND_SHUTDOWN ;u8 id =subflow_get_local_id (subflow); -if (inet_sk_state_load (ssk) ==TCP_CLOSE ) +if ((1 <<inet_sk_state_load (ssk)) & + (TCPF_FIN_WAIT1 |TCPF_FIN_WAIT2 |TCPF_CLOSING |TCPF_CLOSE ))continue ;if (rm_type ==MPTCP_MIB_RMADDR && remote_id != rm_id)continue ;
Greg Kroah-Hartman
maintainerPATCH 199/214 device-dax: correct pgoff align in dax_set_mapping()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kun(llfl) <[email protected]>
commit 7fcbd9785d4c17ea533c42f20a9083a83f301fa6 upstream.
pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address.
It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end.
We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly:
[ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page:
Recovered
It took us several weeks to pinpoint this problem, but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue.
Joao added:
; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)
--- drivers/dax/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dax/device.c +1 -1
@@ -86,7 +86,7 @@ static void dax_set_mapping(struct vm_fa nr_pages =1 ; pgoff =linear_page_index (vmf->vma, -ALIGN (vmf->address, fault_size)); +ALIGN_DOWN (vmf->address, fault_size));for (i =0 ; i < nr_pages; i++) {struct page *page =pfn_to_page (pfn_t_to_pfn (pfn) + i);
Greg Kroah-Hartman
maintainerPATCH 200/214 ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gui-Dong Han <[email protected]>
commit ccca30a18e36a742e606d5bf0630e75be7711d0a upstream.
This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak.
To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path.
This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.
--- drivers/net/ethernet/intel/ice/ice_dpll.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ice/ice_dpll.c +2 -2
@@ -1628,6 +1628,8 @@ ice_dpll_init_rclk_pins(struct ice_pf *pstruct dpll_pin *parent;int ret, i; +if (WARN_ON ((!vsi || !vsi->netdev))) +return -EINVAL ; ret =ice_dpll_get_pins (pf, pin, start_idx,ICE_DPLL_RCLK_NUM_PER_PF , pf->dplls.clock_id);if (ret)
@@ -1643,8 +1645,6 @@ ice_dpll_init_rclk_pins(struct ice_pf *pif (ret) goto unregister_pins; } -if (WARN_ON ((!vsi || !vsi->netdev))) -return -EINVAL ;dpll_netdev_pin_set (vsi->netdev, pf->dplls.rclk.pin);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 201/214 ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gui-Dong Han <[email protected]>
commit d517cf89874c6039e6294b18d66f40988e62502a upstream.
This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function.
First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL.
Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0.
This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.
--- drivers/net/ethernet/intel/ice/ice_sriov.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ice/ice_sriov.c +6 -2
@@ -1096,8 +1096,10 @@ int ice_sriov_set_msix_vec_count(structreturn -ENOENT ; vsi =ice_get_vf_vsi (vf); -if (!vsi) +if (!vsi) { +ice_put_vf (vf);return -ENOENT ; + } prev_msix = vf->num_msix; prev_queues = vf->num_vf_qs;
@@ -1145,8 +1147,10 @@ unroll: vf->num_msix = prev_msix; vf->num_vf_qs = prev_queues; vf->first_vector_idx =ice_sriov_get_irqs (pf, vf->num_msix); -if (vf->first_vector_idx <0 ) +if (vf->first_vector_idx <0 ) { +ice_put_vf (vf);return -EINVAL ; + }if (needs_rebuild) { vsi->req_txq = prev_queues;
Greg Kroah-Hartman
maintainerPATCH 202/214 nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yonatan Maman <[email protected]>
commit 835745a377a4519decd1a36d6b926e369b3033e2 upstream.
The nouveau_dmem_copy_one function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully.
In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and nouveau_dmem_copy_one will likely report success, leading to the migrate_to_ram function returning a dirty HIGH_USER page to the user.
This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user.
To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.
--- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_dmem.c +1 -1
@@ -193,7 +193,7 @@ static vm_fault_t nouveau_dmem_migrate_tif (!spage || !(src &MIGRATE_PFN_MIGRATE )) goto done; - dpage =alloc_page_vma (GFP_HIGHUSER , vmf->vma, vmf->address); + dpage =alloc_page_vma (GFP_HIGHUSER | __GFP_ZERO, vmf->vma, vmf->address);if (!dpage) goto done;
Greg Kroah-Hartman
maintainerPATCH 203/214 powercap: intel_rapl_tpmi: Fix bogus register reading
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Rui <[email protected]>
commit 91e8f835a7eda4ba2c0c4002a3108a0e3b22d34e upstream.
The TPMI_RAPL_REG_DOMAIN_INFO value needs to be multiplied by 8 to get the register offset.
--- drivers/powercap/intel_rapl_tpmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/powercap/intel_rapl_tpmi.c +1 -1
@@ -192,7 +192,7 @@ static int parse_one_domain(struct tpmi_pr_warn (FW_BUG "System domain must support Domain Info register\n" );return -ENODEV ; } - tpmi_domain_info =readq (trp->base + offset +TPMI_RAPL_REG_DOMAIN_INFO ); + tpmi_domain_info =readq (trp->base + offset +TPMI_RAPL_REG_DOMAIN_INFO *8 );if (!(tpmi_domain_info &TPMI_RAPL_DOMAIN_ROOT ))return 0 ; domain_type =RAPL_DOMAIN_PLATFORM ;
Greg Kroah-Hartman
maintainerPATCH 204/214 selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Donet Tom <[email protected]>
commit 76503e1fa1a53ef041a120825d5ce81c7fe7bdd7 upstream.
The hmm2 double_map test was failing due to an incorrect buffer->mirror size. The buffer->mirror size was 6, while buffer->ptr size was 6 * PAGE_SIZE. The test failed because the kernel's copy_to_user function was attempting to copy a 6 * PAGE_SIZE buffer to buffer->mirror. Since the size of buffer->mirror was incorrect, copy_to_user failed.
This patch corrects the buffer->mirror size to 6 * PAGE_SIZE.
Test Result without this patch
==============================
# RUN hmm2.hmm2_device_private.double_map ...
# hmm-tests.c:1680:double_map:Expected ret (-14) == 0 (0) # double_map: Test terminated by assertion
# FAIL hmm2.hmm2_device_private.double_map
not ok 53 hmm2.hmm2_device_private.double_map
Test Result with this patch
===========================
# RUN hmm2.hmm2_device_private.double_map ...
# OK hmm2.hmm2_device_private.double_map
ok 53 hmm2.hmm2_device_private.double_map
--- tools/testing/selftests/mm/hmm-tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/mm/hmm-tests.c +1 -1
@@ -1657,7 +1657,7 @@ TEST_F(hmm2, double_map) buffer->fd =-1 ; buffer->size = size; - buffer->mirror =malloc (npages); + buffer->mirror =malloc (size);ASSERT_NE (buffer->mirror,NULL );/* Reserve a range of addresses. */
Greg Kroah-Hartman
maintainerPATCH 205/214 selftests/rseq: Fix mm_cid test failure
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathieu Desnoyers <[email protected]>
commit a0cc649353bb726d4aa0db60dce467432197b746 upstream.
Adapt the rseq.c/rseq.h code to follow GNU C library changes introduced by:
glibc commit 2e456ccf0c34 ("Linux: Make __rseq_size useful for feature detection (bug 31965)")
Without this fix, rseq selftests for mm_cid fail:
./run_param_test.sh
Default parameters
Running test spinlock
Running compare-twice test spinlock
Running mm_cid test spinlock
Error: cpu id getter unavailable
--- tools/testing/selftests/rseq/rseq.c | 110 ++++++++++++++++++++++++------------ tools/testing/selftests/rseq/rseq.h | 10 --- 2 files changed, 77 insertions(+), 43 deletions(-)
tools/testing/selftests/rseq/rseq.c +75 -35
@@ -60,12 +60,6 @@ unsigned int rseq_size = -1U;/* Flags used during rseq registration. */ unsigned int rseq_flags; -/* -* rseq feature size supported by the kernel. 0 if the registration was -* unsuccessful. -*/ -unsigned int rseq_feature_size =-1U ; -static int rseq_ownership;static int rseq_reg_success;/* At least one rseq registration has succeded. */
@@ -111,6 +105,43 @@ int rseq_available(void) } } +/* The rseq areas need to be at least 32 bytes. */ +static +unsigned int get_rseq_min_alloc_size (void ) +{ +unsigned int alloc_size = rseq_size; + +if (alloc_size <ORIG_RSEQ_ALLOC_SIZE ) + alloc_size =ORIG_RSEQ_ALLOC_SIZE ; +return alloc_size; +} + +/* +* Return the feature size supported by the kernel. +* +* Depending on the value returned by getauxval(AT_RSEQ_FEATURE_SIZE): +* +* 0: Return ORIG_RSEQ_FEATURE_SIZE (20) +* > 0: Return the value from getauxval(AT_RSEQ_FEATURE_SIZE). +* +* It should never return a value below ORIG_RSEQ_FEATURE_SIZE. +*/ +static +unsigned int get_rseq_kernel_feature_size (void ) +{ +unsigned long auxv_rseq_feature_size, auxv_rseq_align; + + auxv_rseq_align =getauxval (AT_RSEQ_ALIGN ); +assert (!auxv_rseq_align || auxv_rseq_align <=RSEQ_THREAD_AREA_ALLOC_SIZE ); + + auxv_rseq_feature_size =getauxval (AT_RSEQ_FEATURE_SIZE ); +assert (!auxv_rseq_feature_size || auxv_rseq_feature_size <=RSEQ_THREAD_AREA_ALLOC_SIZE ); +if (auxv_rseq_feature_size) +return auxv_rseq_feature_size; +else +return ORIG_RSEQ_FEATURE_SIZE ; +} +int rseq_register_current_thread (void ) {int rc;
@@ -119,7 +150,7 @@ int rseq_register_current_thread(void)/* Treat libc's ownership as a successful registration. */ return 0 ; } - rc =sys_rseq (&__rseq_abi, rseq_size,0 ,RSEQ_SIG ); + rc =sys_rseq (&__rseq_abi,get_rseq_min_alloc_size (),0 ,RSEQ_SIG );if (rc) {if (RSEQ_READ_ONCE (rseq_reg_success)) {/* Incoherent success/failure within process. */
@@ -140,28 +171,12 @@ int rseq_unregister_current_thread(void)/* Treat libc's ownership as a successful unregistration. */ return 0 ; } - rc =sys_rseq (&__rseq_abi, rseq_size,RSEQ_ABI_FLAG_UNREGISTER ,RSEQ_SIG ); + rc =sys_rseq (&__rseq_abi,get_rseq_min_alloc_size (),RSEQ_ABI_FLAG_UNREGISTER ,RSEQ_SIG );if (rc)return -1 ;return 0 ; } -static -unsigned int get_rseq_feature_size (void ) -{ -unsigned long auxv_rseq_feature_size, auxv_rseq_align; - - auxv_rseq_align =getauxval (AT_RSEQ_ALIGN ); -assert (!auxv_rseq_align || auxv_rseq_align <=RSEQ_THREAD_AREA_ALLOC_SIZE ); - - auxv_rseq_feature_size =getauxval (AT_RSEQ_FEATURE_SIZE ); -assert (!auxv_rseq_feature_size || auxv_rseq_feature_size <=RSEQ_THREAD_AREA_ALLOC_SIZE ); -if (auxv_rseq_feature_size) -return auxv_rseq_feature_size; -else -return ORIG_RSEQ_FEATURE_SIZE ; -} -static __attribute__((constructor))void rseq_init (void ) {
@@ -178,28 +193,54 @@ void rseq_init(void) }if (libc_rseq_size_p && libc_rseq_offset_p && libc_rseq_flags_p && *libc_rseq_size_p !=0 ) { +unsigned int libc_rseq_size; +/* rseq registration owned by glibc */ rseq_offset = *libc_rseq_offset_p; - rseq_size = *libc_rseq_size_p; + libc_rseq_size = *libc_rseq_size_p; rseq_flags = *libc_rseq_flags_p; - rseq_feature_size =get_rseq_feature_size (); -if (rseq_feature_size > rseq_size) - rseq_feature_size = rseq_size; + +/* +* Previous versions of glibc expose the value +* 32 even though the kernel only supported 20 +* bytes initially. Therefore treat 32 as a +* special-case. glibc 2.40 exposes a 20 bytes +* __rseq_size without using getauxval(3) to +* query the supported size, while still allocating a 32 +* bytes area. Also treat 20 as a special-case. +* +* Special-cases are handled by using the following +* value as active feature set size: +* +* rseq_size = min(32, get_rseq_kernel_feature_size()) +*/ +switch (libc_rseq_size) { +case ORIG_RSEQ_FEATURE_SIZE : + fallthrough; +case ORIG_RSEQ_ALLOC_SIZE : + { +unsigned int rseq_kernel_feature_size =get_rseq_kernel_feature_size (); + +if (rseq_kernel_feature_size <ORIG_RSEQ_ALLOC_SIZE ) + rseq_size = rseq_kernel_feature_size; +else + rseq_size =ORIG_RSEQ_ALLOC_SIZE ; +break ; + } +default : +/* Otherwise just use the __rseq_size from libc as rseq_size. */ + rseq_size = libc_rseq_size; +break ; + }return ; } rseq_ownership =1 ;if (!rseq_available ()) { rseq_size =0 ; - rseq_feature_size =0 ;return ; } rseq_offset = (void *)&__rseq_abi -rseq_thread_pointer (); rseq_flags =0 ; - rseq_feature_size =get_rseq_feature_size (); -if (rseq_feature_size ==ORIG_RSEQ_FEATURE_SIZE ) - rseq_size =ORIG_RSEQ_ALLOC_SIZE ; -else - rseq_size =RSEQ_THREAD_AREA_ALLOC_SIZE ; } static __attribute__((destructor))
@@ -209,7 +250,6 @@ void rseq_exit(void)return ; rseq_offset =0 ; rseq_size =-1U ; - rseq_feature_size =-1U ; rseq_ownership =0 ; }
tools/testing/selftests/rseq/rseq.h +2 -8
@@ -68,12 +68,6 @@ extern unsigned int rseq_size;/* Flags used during rseq registration. */ extern unsigned int rseq_flags; -/* -* rseq feature size supported by the kernel. 0 if the registration was -* unsuccessful. -*/ -extern unsigned int rseq_feature_size; -enum rseq_mo {RSEQ_MO_RELAXED =0 ,RSEQ_MO_CONSUME =1 ,/* Unused */
@@ -193,7 +187,7 @@ static inline uint32_t rseq_current_cpu(static inline bool rseq_node_id_available (void ) { - return (int) rseq_feature_size >= rseq_offsetofend(struct rseq_abi, node_id); + return (int) rseq_size >= rseq_offsetofend(struct rseq_abi, node_id); }/*
@@ -207,7 +201,7 @@ static inline uint32_t rseq_current_nodestatic inline bool rseq_mm_cid_available (void ) { - return (int) rseq_feature_size >= rseq_offsetofend(struct rseq_abi, mm_cid); + return (int) rseq_size >= rseq_offsetofend(struct rseq_abi, mm_cid); }static inline uint32_t rseq_current_mm_cid (void )
Greg Kroah-Hartman
maintainerPATCH 206/214 btrfs: split remaining space to discard in chunks
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luca Stefani <[email protected]>
commit a99fcb0158978ed332009449b484e5f3ca2d7df4 upstream.
Per Qu Wenruo in case we have a very large disk, e.g. 8TiB device, mostly empty although we will do the split according to our super block locations, the last super block ends at 256G, we can submit a huge discard for the range [256G, 8T), causing a large delay.
Split the space left to discard based on BTRFS_MAX_DISCARD_CHUNK_SIZE in preparation of introduction of cancellation points to trim. The value of the chunk size is arbitrary, it can be higher or derived from actual device capabilities but we can't easily read that using bio_discard_limit().
--- fs/btrfs/extent-tree.c | 19 +++++++++++++++---- fs/btrfs/volumes.h | 6 ++++++ 2 files changed, 21 insertions(+), 4 deletions(-)
fs/btrfs/extent-tree.c +15 -4
@@ -1300,13 +1300,24 @@ static int btrfs_issue_discard(struct bl bytes_left = end - start; } -if (bytes_left) { +while (bytes_left) { +u64 bytes_to_discard =min (BTRFS_MAX_DISCARD_CHUNK_SIZE , bytes_left); + ret =blkdev_issue_discard (bdev, start >>SECTOR_SHIFT , - bytes_left >>SECTOR_SHIFT , + bytes_to_discard >>SECTOR_SHIFT ,GFP_NOFS ); -if (!ret) - *discarded_bytes += bytes_left; + +if (ret) { +if (ret != -EOPNOTSUPP ) +break ; +continue ; + } + + start += bytes_to_discard; + bytes_left -= bytes_to_discard; + *discarded_bytes += bytes_to_discard; } +return ret; }
fs/btrfs/volumes.h +6 -0
@@ -30,6 +30,12 @@ struct btrfs_zoned_device_info;#define BTRFS_MAX_DATA_CHUNK_SIZE (10ULL * SZ_1G) +/* +* Arbitratry maximum size of one discard request to limit potentially long time +* spent in blkdev_issue_discard(). +*/ +#define BTRFS_MAX_DISCARD_CHUNK_SIZE (SZ_1G) +extern struct mutex uuid_mutex;#define BTRFS_STRIPE_LEN SZ_64K
Greg Kroah-Hartman
maintainerPATCH 207/214 btrfs: add cancellation points to trim loops
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luca Stefani <[email protected]>
commit 69313850dce33ce8c24b38576a279421f4c60996 upstream.
There are reports that system cannot suspend due to running trim because the task responsible for trimming the device isn't able to finish in time, especially since we have a free extent discarding phase, which can trim a lot of unallocated space. There are no limits on the trim size (unlike the block group part).
Since trime isn't a critical call it can be interrupted at any time, in such cases we stop the trim, report the amount of discarded bytes and return an error.
--- fs/btrfs/extent-tree.c | 7 ++++++- fs/btrfs/free-space-cache.c | 4 ++-- fs/btrfs/free-space-cache.h | 6 ++++++ 3 files changed, 14 insertions(+), 3 deletions(-)
fs/btrfs/extent-tree.c +6 -1
@@ -1316,6 +1316,11 @@ static int btrfs_issue_discard(struct bl start += bytes_to_discard; bytes_left -= bytes_to_discard; *discarded_bytes += bytes_to_discard; + +if (btrfs_trim_interrupted ()) { + ret = -ERESTARTSYS ; +break ; + } }return ret;
@@ -6470,7 +6475,7 @@ static int btrfs_trim_free_extents(struc start += len; *trimmed += bytes; -if (fatal_signal_pending (current)) { +if (btrfs_trim_interrupted ()) { ret = -ERESTARTSYS ;break ; }
fs/btrfs/free-space-cache.c +2 -2
@@ -3809,7 +3809,7 @@ next:if (async && *total_trimmed)break ; -if (fatal_signal_pending (current)) { +if (btrfs_trim_interrupted ()) { ret = -ERESTARTSYS ;break ; }
@@ -4000,7 +4000,7 @@ next: } block_group->discard_cursor = start; -if (fatal_signal_pending (current)) { +if (btrfs_trim_interrupted ()) {if (start != offset)reset_trimming_bitmap (ctl, offset); ret = -ERESTARTSYS ;
fs/btrfs/free-space-cache.h +6 -0
@@ -10,6 +10,7 @@#include <linux/list.h> #include <linux/spinlock.h> #include <linux/mutex.h> +#include <linux/freezer.h> #include "fs.h" struct inode ;
@@ -56,6 +57,11 @@ static inline bool btrfs_free_space_trimreturn (info->trim_state ==BTRFS_TRIM_STATE_TRIMMING ); } +static inline bool btrfs_trim_interrupted (void ) +{ +return fatal_signal_pending (current) ||freezing (current); +} +/* * Deltas are an effective way to populate global statistics. Give macro names * to make it clear what we're doing. An example is discard_extents in
Greg Kroah-Hartman
maintainerPATCH 208/214 PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulf Hansson <[email protected]>
commit 7738568885f2eaecfc10a3f530a2693e5f0ae3d0 upstream.
The dev_pm_domain_attach|detach_list() functions are not resource managed, hence they should not use devm_* helpers to manage allocation/freeing of data. Let's fix this by converting to the traditional alloc/free functions.
--- drivers/base/power/common.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-)
drivers/base/power/common.c +15 -10
@@ -195,6 +195,7 @@ int dev_pm_domain_attach_list(struct devstruct device *pd_dev =NULL ;int ret, i, num_pds =0 ;bool by_id = true; +size_t size;u32 pd_flags = data ? data->pd_flags :0 ;u32 link_flags = pd_flags &PD_FLAG_NO_DEV_LINK ?0 :DL_FLAG_STATELESS |DL_FLAG_PM_RUNTIME ;
@@ -217,19 +218,17 @@ int dev_pm_domain_attach_list(struct devif (num_pds <=0 )return 0 ; - pds =devm_kzalloc (dev,sizeof (*pds),GFP_KERNEL ); + pds =kzalloc (sizeof (*pds),GFP_KERNEL );if (!pds)return -ENOMEM ; - pds->pd_devs =devm_kcalloc (dev, num_pds,sizeof (*pds->pd_devs), -GFP_KERNEL ); -if (!pds->pd_devs) -return -ENOMEM ; - - pds->pd_links =devm_kcalloc (dev, num_pds,sizeof (*pds->pd_links), -GFP_KERNEL ); -if (!pds->pd_links) -return -ENOMEM ; + size =sizeof (*pds->pd_devs) +sizeof (*pds->pd_links); + pds->pd_devs =kcalloc (num_pds, size,GFP_KERNEL ); +if (!pds->pd_devs) { + ret = -ENOMEM ; + goto free_pds; + } + pds->pd_links = (void *)(pds->pd_devs + num_pds);if (link_flags && pd_flags &PD_FLAG_DEV_LINK_ON ) link_flags |=DL_FLAG_RPM_ACTIVE ;
@@ -272,6 +271,9 @@ err_attach:device_link_del (pds->pd_links[i]);dev_pm_domain_detach (pds->pd_devs[i], true); } +kfree (pds->pd_devs); +free_pds: +kfree (pds);return ret; }EXPORT_SYMBOL_GPL (dev_pm_domain_attach_list);
@@ -318,6 +320,9 @@ void dev_pm_domain_detach_list(struct dedevice_link_del (list->pd_links[i]);dev_pm_domain_detach (list->pd_devs[i], true); } + +kfree (list->pd_devs); +kfree (list); }EXPORT_SYMBOL_GPL (dev_pm_domain_detach_list);
Greg Kroah-Hartman
maintainerPATCH 209/214 idpf: use actual mbx receive payload length
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joshua Hay <[email protected]>
commit 640f70063e6d3a76a63f57e130fba43ba8c7e980 upstream.
When a mailbox message is received, the driver is checking for a non 0 datalen in the controlq descriptor. If it is valid, the payload is attached to the ctlq message to give to the upper layer. However, the payload response size given to the upper layer was taken from the buffer metadata which is _always_ the max buffer size. This meant the API was returning 4K as the payload size for all messages. This went unnoticed since the virtchnl exchange response logic was checking for a response size less than 0 (error), not less than exact size, or not greater than or equal to the max mailbox buffer size (4K). All of these checks will pass in the success case since the size provided is always 4K. However, this breaks anyone that wants to validate the exact response size.
Fetch the actual payload length from the value provided in the descriptor data_len field (instead of the buffer metadata).
Unfortunately, this means we lose some extra error parsing for variable sized virtchnl responses such as create vport and get ptypes. However, the original checks weren't really helping anyways since the size was _always_ 4K.
--- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-)
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +1 -8
@@ -666,7 +666,7 @@ idpf_vc_xn_forward_reply(struct idpf_adaif (ctlq_msg->data_len) { payload = ctlq_msg->ctx.indirect.payload->va; - payload_size = ctlq_msg->ctx.indirect.payload->size; + payload_size = ctlq_msg->data_len; } xn->reply_sz = payload_size;
@@ -1295,10 +1295,6 @@ int idpf_send_create_vport_msg(struct id err = reply_sz; goto free_vport_params; } -if (reply_sz <IDPF_CTLQ_MAX_BUF_LEN ) { - err = -EIO ; - goto free_vport_params; - }return 0 ;
@@ -2602,9 +2598,6 @@ int idpf_send_get_rx_ptype_msg(struct idif (reply_sz <0 )return reply_sz; -if (reply_sz <IDPF_CTLQ_MAX_BUF_LEN ) -return -EIO ; - ptypes_recvd +=le16_to_cpu (ptype_info->num_ptypes);if (ptypes_recvd > max_ptype)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 210/214 kthread: unpark only parked kthread
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frederic Weisbecker <[email protected]>
commit 214e01ad4ed7158cab66498810094fac5d09b218 upstream.
Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state.
However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked.
As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning:
WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 <TASK> kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
Fix this with skipping unecessary unparking while stopping a kthread.
--- kernel/kthread.c | 2 ++ 1 file changed, 2 insertions(+)
kernel/kthread.c +2 -0
@@ -623,6 +623,8 @@ void kthread_unpark(struct task_struct * {struct kthread *kthread =to_kthread (k); +if (!test_bit (KTHREAD_SHOULD_PARK , &kthread->flags)) +return ;/* * Newly created kthread was parked when the CPU was offline. * The binding was lost and we need to set it again.
Greg Kroah-Hartman
maintainerPATCH 211/214 fs/proc/kcore.c: allow translation of physical memory addresses
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Gordeev <[email protected]>
commit 3d5854d75e3187147613130561b58f0b06166172 upstream.
When /proc/kcore is read an attempt to read the first two pages results in HW-specific page swap on s390 and another (so called prefix) pages are accessed instead. That leads to a wrong read.
Allow architecture-specific translation of memory addresses using kc_xlate_dev_mem_ptr() and kc_unxlate_dev_mem_ptr() callbacks similarily to /dev/mem xlate_dev_mem_ptr() and unxlate_dev_mem_ptr() callbacks. That way an architecture can deal with specific physical memory ranges.
Re-use the existing /dev/mem callback implementation on s390, which handles the described prefix pages swapping correctly.
For other architectures the default callback is basically NOP. It is expected the condition (vaddr == __va(__pa(vaddr))) always holds true for KCORE_RAM memory type.
--- arch/s390/include/asm/io.h | 2 ++ fs/proc/kcore.c | 36 ++++++++++++++++++++++++++++++++++-- 2 files changed, 36 insertions(+), 2 deletions(-)
arch/s390/include/asm/io.h +2 -0
@@ -16,8 +16,10 @@#include <asm/pci_io.h> #define xlate_dev_mem_ptr xlate_dev_mem_ptr +#define kc_xlate_dev_mem_ptr xlate_dev_mem_ptrvoid *xlate_dev_mem_ptr (phys_addr_t phys);#define unxlate_dev_mem_ptr unxlate_dev_mem_ptr +#define kc_unxlate_dev_mem_ptr unxlate_dev_mem_ptrvoid unxlate_dev_mem_ptr (phys_addr_t phys,void *addr);#define IO_SPACE_LIMIT 0
fs/proc/kcore.c +34 -2
@@ -50,6 +50,20 @@ static struct proc_dir_entry *proc_root_#define kc_offset_to_vaddr (o) ((o) + PAGE_OFFSET)#endif +#ifndef kc_xlate_dev_mem_ptr +#define kc_xlate_dev_mem_ptr kc_xlate_dev_mem_ptr +static inline void *kc_xlate_dev_mem_ptr (phys_addr_t phys) +{ +return __va (phys); +} +#endif +#ifndef kc_unxlate_dev_mem_ptr +#define kc_unxlate_dev_mem_ptr kc_unxlate_dev_mem_ptr +static inline void kc_unxlate_dev_mem_ptr (phys_addr_t phys,void *virt) +{ +} +#endif +static LIST_HEAD (kclist_head);static DECLARE_RWSEM (kclist_lock);static int kcore_need_update =1 ;
@@ -471,6 +485,8 @@ static ssize_t read_kcore_iter(struct kiwhile (buflen) {struct page *page;unsigned long pfn; +phys_addr_t phys; +void *__start;/* * If this is the first iteration or the address is not within
@@ -537,7 +553,8 @@ static ssize_t read_kcore_iter(struct ki }break ;case KCORE_RAM : - pfn =__pa (start) >>PAGE_SHIFT ; + phys =__pa (start); + pfn = phys >>PAGE_SHIFT ; page =pfn_to_online_page (pfn);/*
@@ -557,13 +574,28 @@ static ssize_t read_kcore_iter(struct ki fallthrough;case KCORE_VMEMMAP :case KCORE_TEXT : +if (m->type ==KCORE_RAM ) { + __start =kc_xlate_dev_mem_ptr (phys); +if (!__start) { + ret = -ENOMEM ; +if (iov_iter_zero (tsz, iter) != tsz) + ret = -EFAULT ; + goto out; + } + }else { + __start = (void *)start; + } +/* * Sadly we must use a bounce buffer here to be able to * make use of copy_from_kernel_nofault(), as these * memory regions might not always be mapped on all * architectures. */ -if (copy_from_kernel_nofault (buf, (void *)start, tsz)) { + ret =copy_from_kernel_nofault (buf, __start, tsz); +if (m->type ==KCORE_RAM ) +kc_unxlate_dev_mem_ptr (phys, __start); +if (ret) {if (iov_iter_zero (tsz, iter) != tsz) { ret = -EFAULT ; goto out;
Greg Kroah-Hartman
maintainerPATCH 212/214 secretmem: disable memfd_secret() if arch cannot set direct map
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Roy <[email protected]>
commit 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 upstream.
Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages).
More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success
(0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map.
Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected.
Quoted 1 line
From going through the iterations of the original
memfd_secretpatch
series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations.
[1]: https://lore.kernel.org/lkml/[email protected]/
[2]: https://lore.kernel.org/lkml/[email protected]/#t
[3]: https://lore.kernel.org/lkml/[email protected]/
--- mm/secretmem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
mm/secretmem.c +2 -2
@@ -238,7 +238,7 @@ SYSCALL_DEFINE1(memfd_secret, unsigned i/* make sure local flags do not confict with global fcntl.h */ BUILD_BUG_ON (SECRETMEM_FLAGS_MASK &O_CLOEXEC ); -if (!secretmem_enable) +if (!secretmem_enable || !can_set_direct_map ())return -ENOSYS ;if (flags & ~(SECRETMEM_FLAGS_MASK |O_CLOEXEC ))
@@ -280,7 +280,7 @@ static struct file_system_type secretmemstatic int __init secretmem_init (void ) { -if (!secretmem_enable) +if (!secretmem_enable || !can_set_direct_map ())return 0 ; secretmem_mnt =kern_mount (&secretmem_fs);
Greg Kroah-Hartman
maintainerPATCH 213/214 PCI: Pass domain number to pci_bus_release_domain_nr() explicitly
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manivannan Sadhasivam <[email protected]>
commit 0cca961a026177af69044f10d6ae76d8ce043764 upstream.
The pci_bus_release_domain_nr() API is supposed to free the domain number allocated by pci_bus_find_domain_nr(). Most of the callers of pci_bus_find_domain_nr(), store the domain number in pci_bus::domain_nr.
As such, the pci_bus_release_domain_nr() implicitly frees the domain number by dereferencing 'struct pci_bus'. However, one of the callers of this API, the PCI endpoint subsystem, doesn't have 'struct pci_bus', so it only passes NULL. Due to this, the API will end up dereferencing the NULL pointer.
To fix this issue, pass the domain number to this API explicitly. Since 'struct pci_bus' is not used for anything else other than extracting the domain number, it makes sense to pass the domain number directly.
--- drivers/pci/endpoint/pci-epc-core.c | 2 +- drivers/pci/pci.c | 14 +++++++------- drivers/pci/probe.c | 2 +- drivers/pci/remove.c | 2 +- include/linux/pci.h | 2 +- 5 files changed, 11 insertions(+), 11 deletions(-)
drivers/pci/endpoint/pci-epc-core.c +1 -1
@@ -840,7 +840,7 @@ void pci_epc_destroy(struct pci_epc *epcdevice_unregister (&epc->dev);#ifdef CONFIG_PCI_DOMAINS_GENERIC -pci_bus_release_domain_nr (NULL , &epc->dev); +pci_bus_release_domain_nr (&epc->dev, epc->domain_nr);#endif }EXPORT_SYMBOL_GPL (pci_epc_destroy);
drivers/pci/pci.c +7 -7
@@ -6814,16 +6814,16 @@ static int of_pci_bus_find_domain_nr(strreturn ida_alloc (&pci_domain_nr_dynamic_ida,GFP_KERNEL ); } -static void of_pci_bus_release_domain_nr (struct pci_bus *bus,struct device *parent) +static void of_pci_bus_release_domain_nr (struct device *parent,int domain_nr) { -if (bus->domain_nr <0 ) +if (domain_nr <0 )return ;/* Release domain from IDA where it was allocated. */ -if (of_get_pci_domain_nr (parent->of_node) == bus->domain_nr) -ida_free (&pci_domain_nr_static_ida, bus->domain_nr); +if (of_get_pci_domain_nr (parent->of_node) == domain_nr) +ida_free (&pci_domain_nr_static_ida, domain_nr);else -ida_free (&pci_domain_nr_dynamic_ida, bus->domain_nr); +ida_free (&pci_domain_nr_dynamic_ida, domain_nr); }int pci_bus_find_domain_nr (struct pci_bus *bus,struct device *parent)
@@ -6832,11 +6832,11 @@ int pci_bus_find_domain_nr(struct pci_bu acpi_pci_bus_find_domain_nr(bus); } -void pci_bus_release_domain_nr (struct pci_bus *bus,struct device *parent) +void pci_bus_release_domain_nr (struct device *parent,int domain_nr) {if (!acpi_disabled)return ; -of_pci_bus_release_domain_nr (bus, parent); +of_pci_bus_release_domain_nr (parent, domain_nr); }#endif
drivers/pci/probe.c +1 -1
@@ -1061,7 +1061,7 @@ unregister: free:#ifdef CONFIG_PCI_DOMAINS_GENERIC -pci_bus_release_domain_nr (bus ,parent ); +pci_bus_release_domain_nr (parent, bus->domain_nr);#endif kfree (bus);return err;
drivers/pci/remove.c +1 -1
@@ -179,7 +179,7 @@ void pci_remove_root_bus(struct pci_bus#ifdef CONFIG_PCI_DOMAINS_GENERIC /* Release domain_nr if it was dynamically allocated */ if (host_bridge->domain_nr ==PCI_DOMAIN_NR_NOT_SET ) -pci_bus_release_domain_nr (bus, host_bridge->dev.parent); +pci_bus_release_domain_nr (host_bridge->dev.parent, bus->domain_nr);#endif pci_remove_bus (bus);
include/linux/pci.h +1 -1
@@ -1884,7 +1884,7 @@ static inline int acpi_pci_bus_find_doma {return 0 ; }#endif int pci_bus_find_domain_nr (struct pci_bus *bus,struct device *parent); -void pci_bus_release_domain_nr (struct pci_bus *bus,struct device *parent); +void pci_bus_release_domain_nr (struct device *parent,int domain_nr);#endif /* Some architectures require additional setup to direct VGA traffic */
Greg Kroah-Hartman
maintainerPATCH 214/214 io_uring/rw: fix cflags posting for single issue multishot read
In reply to Greg Kroah-Hartman6.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
Commit c9d952b9103b600ddafc5d1c0e2f2dbd30f0b805 upstream.
If multishot gets disabled, and hence the request will get terminated rather than persist for more iterations, then posting the CQE with the right cflags is still important. Most notably, the buffer reference needs to be included.
Refactor the return of __io_read() a bit, so that the provided buffer is always put correctly, and hence returned to the application.
--- io_uring/rw.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
io_uring/rw.c +12 -7
@@ -973,17 +973,21 @@ int io_read_mshot(struct io_kiocb *req,if (issue_flags &IO_URING_F_MULTISHOT )return IOU_ISSUE_SKIP_COMPLETE ;return -EAGAIN ; - } - -/* -* Any successful return value will keep the multishot read armed. -*/ -if (ret >0 && req->flags &REQ_F_APOLL_MULTISHOT ) { + }else if (ret <=0 ) { +io_kbuf_recycle (req, issue_flags); +if (ret <0 ) +req_set_fail (req); + }else {/* -* Put our buffer and post a CQE. If we fail to post a CQE, then +* Any successful return value will keep the multishot read +* armed, if it's still set. Put our buffer and post a CQE. If +* we fail to post a CQE, or multishot is no longer set, then * jump to the termination path. This request is then done. */ cflags =io_put_kbuf (req, issue_flags); +if (!(req->flags &REQ_F_APOLL_MULTISHOT )) + goto done; + rw->len =0 ;/* similarly to above, reset len to 0 */ if (io_req_post_cqe (req, ret, cflags |IORING_CQE_F_MORE )) {
@@ -1004,6 +1008,7 @@ int io_read_mshot(struct io_kiocb *req,* Either an error, or we've hit overflow posting the CQE. For any * multishot request, hitting overflow will terminate it. */ +done:io_req_set_res (req, ret, cflags);io_req_rw_cleanup (req, issue_flags);if (issue_flags &IO_URING_F_MULTISHOT )
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +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.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Am 14.10.2024 um 16:17 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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]
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +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.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.11:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 115 pass, 1 failLinux version: 6.11.4-rc1-ga491a66f8da4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra194-p2972-0000: boot.py
Jon
Jon Hunter
maintainerHi Greg,
Quoted 26 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +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.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.11:
10 builds: 10 pass, 0 fail 26 boots: 26 pass, 0 fail 116 tests: 115 pass, 1 fail
Quoted 7 lines
Linux version: 6.11.4-rc1-ga491a66f8da4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra194-p2972-0000:
boot.py
I am seeing the following kernel warning with this updated on the above board ...
ERR KERN ucsi_ccg 2-0008: con1: failed to get status ERR KERN ucsi_ccg 2-0008: con2: failed to get status
If I revert the following change I don't see these warnings ...
Heikki Krogerus <[email protected]>
usb: typec: ucsi: Don't truncate the reads
Please note that I am not seeing these warnings on mainline/next with this board.
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 45 lines · Jon Hunter
Hi Greg,
Quoted 26 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +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.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.11:
10 builds: 10 pass, 0 fail 26 boots: 26 pass, 0 fail 116 tests: 115 pass, 1 failQuoted 7 lines
Linux version: 6.11.4-rc1-ga491a66f8da4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra194-p2972-0000:
boot.pyI am seeing the following kernel warning with this updated on the above board ...
ERR KERN
ucsi_ccg2-0008: con1: failed to get status ERR KERNucsi_ccg2-0008: con2: failed to get status
Quoted 8 lines
If I revert the following change I don't see these warnings ...
Heikki Krogerus <[email protected]>
usb: typec: ucsi: Don't truncate the readsPlease note that I am not seeing these warnings on mainline/next with this board.
Odd, I'll go drop this now, thanks for reporting it!
greg k-h
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +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.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.thanks,
greg k-h
The S390 build broke on the stable-rc linux-6.11.y branch due to following build warnings / errors.
First seen on v6.11.3-215-ga491a66f8da4
GOOD: v6.11.3
BAD: v6.11.3-215-ga491a66f8da4
List of regressions,
* s390, build
- clang-19-allnoconfig
- clang-19-defconfig
- clang-nightly-allnoconfig
- clang-nightly-defconfig
- gcc-13-allmodconfig
- gcc-13-allnoconfig
- gcc-13-defconfig
- gcc-13-tinyconfig
- gcc-8-allnoconfig
- gcc-8-defconfig-fe40093d
- gcc-8-tinyconfig
Build log:
-------
arch/s390/include/asm/cpu_mf.h: Assembler messages:
arch/s390/include/asm/cpu_mf.h:165: Error: Unrecognized opcode: `lpp' make[3]: *** [scripts/Makefile.build:244: arch/s390/boot/startup.o] Error 1
arch/s390/include/asm/atomic_ops.h: Assembler messages:
arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode: laag' arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode: laag' make[3]: *** [scripts/Makefile.build:244: arch/s390/boot/vmem.o] Error 1
arch/s390/include/asm/bitops.h: Assembler messages:
arch/s390/include/asm/bitops.h:308: Error: Unrecognized opcode: `flogr' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/pgm_check_info.o] Error 1
arch/s390/include/asm/timex.h: Assembler messages:
arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode: stckf' arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode: stckf' make[3]: *** [scripts/Makefile.build:244: arch/s390/boot/kaslr.o] Error 1 make[3]: Target 'arch/s390/boot/bzImage' not remade because of errors. make[2]: *** [arch/s390/Makefile:137: bzImage] Error 2
Build log:
---------
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.11.y/build/v6.11.3-215-ga491a66f8da4/testrun/25429522/suite/build/test/gcc-13-defconfig/log
metadata:
----
git describe: v6.11.3-215-ga491a66f8da4
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git sha: a491a66f8da4fbfc06aedae9a8b0586d11a51fa9
kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2nQsfudCDSTlwmKIKEozbcVOnCs/config
build url: https://storage.tuxsuite.com/public/linaro/lkft/builds/2nQsfudCDSTlwmKIKEozbcVOnCs/
toolchain: clang-19 and gcc-13
config: defconfig
arch: S390
Steps to reproduce:
-------
# tuxmake --runtime podman --target-arch s390 --toolchain gcc-13 --kconfig defconfig
--
Linaro LKFT
https://lkft.linaro.org
Quoted 58 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +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.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.thanks,
greg k-h
The S390 build broke on the stable-rc linux-6.11.y branch due to following build warnings / errors.
First seen on v6.11.3-215-ga491a66f8da4
GOOD: v6.11.3
BAD: v6.11.3-215-ga491a66f8da4List of regressions,
* s390, build
- clang-19-allnoconfig
- clang-19-defconfig
- clang-nightly-allnoconfig
- clang-nightly-defconfig
- gcc-13-allmodconfig
- gcc-13-allnoconfig
- gcc-13-defconfig
- gcc-13-tinyconfig
- gcc-8-allnoconfig
- gcc-8-defconfig-fe40093d
- gcc-8-tinyconfigBuild log:
-------
arch/s390/include/asm/cpu_mf.h: Assembler messages:
arch/s390/include/asm/cpu_mf.h:165: Error: Unrecognized opcode: `lpp' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/startup.o] Error 1
arch/s390/include/asm/atomic_ops.h: Assembler messages:
arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode:laag' arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode:laag' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/vmem.o] Error 1
arch/s390/include/asm/bitops.h: Assembler messages:
arch/s390/include/asm/bitops.h:308: Error: Unrecognized opcode: `flogr' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/pgm_check_info.o] Error 1
Quoted 6 lines
arch/s390/include/asm/timex.h: Assembler messages:
arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode:stckf' arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode:stckf' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/kaslr.o] Error 1 make[3]: Target 'arch/s390/boot/bzImage' not remade because of errors. make[2]: *** [arch/s390/Makefile:137: bzImage] Error 2
The diff of cflags used for arch/s390/boot:
bad 2024-10-15 09:13:39.393060183 +0200 renamed from good 2024-10-15 09:13:59.769479783 +0200 +1 -1
@@ -55,10 +55,10 @@ -Wno -array -bounds --march=z196 -mtune=z13 -Wa, -I/dev/shm/jslaby/linux/arch/s390/include +-march=z900 -I/dev/shm/jslaby/linux/arch/s390/boot -Iarch/s390/boot -DKBUILD_MODFILE='"arch/s390/boot/startup"'
Reverting of this makes it work again:
commit 51ab63c4cc8fbcfee58b8342a35006b45afbbd0d
Refs: v6.11.3-19-g51ab63c4cc8f Author: Heiko Carstens <[email protected]> AuthorDate: Wed Sep 4 11:39:27 2024 +0200 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Mon Oct 14 16:10:09 2024 +0200
s390/boot: Compile all files with the same march flag
[ Upstream commit fccb175bc89a0d37e3ff513bb6bf1f73b3a48950 ]
If the above is to be really used in stable (REASONS?), I believe at least these are missing:ebcc369f1891 s390: Use MARCH_HAS_*_FEATURES defines697b37371f4a s390: Provide MARCH_HAS_*_FEATURES defines
thanks,
Signature · 2 lines
js suse labs
Quoted 95 lines · Jiri Slaby
Quoted 60 lines · Naresh Kamboju
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.11.4-rc1.gz
or in the git tree and branch at:Quoted 6 lines
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y and the diffstat can be found below.thanks,
greg k-h
The S390 build broke on the stable-rc linux-6.11.y branch due to following build warnings / errors.
First seen on v6.11.3-215-ga491a66f8da4
GOOD: v6.11.3
BAD: v6.11.3-215-ga491a66f8da4List of regressions,
* s390, build
- clang-19-allnoconfig
- clang-19-defconfig
- clang-nightly-allnoconfig
- clang-nightly-defconfig
- gcc-13-allmodconfig
- gcc-13-allnoconfig
- gcc-13-defconfig
- gcc-13-tinyconfig
- gcc-8-allnoconfig
- gcc-8-defconfig-fe40093d
- gcc-8-tinyconfigBuild log:
-------
arch/s390/include/asm/cpu_mf.h: Assembler messages:
arch/s390/include/asm/cpu_mf.h:165: Error: Unrecognized opcode: `lpp' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/startup.o] Error 1
arch/s390/include/asm/atomic_ops.h: Assembler messages:
arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode:laag' arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode:laag' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/vmem.o] Error 1
arch/s390/include/asm/bitops.h: Assembler messages:
arch/s390/include/asm/bitops.h:308: Error: Unrecognized opcode: `flogr' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/pgm_check_info.o] Error 1Quoted 6 lines
arch/s390/include/asm/timex.h: Assembler messages:
arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode:stckf' arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode:stckf' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/kaslr.o] Error 1 make[3]: Target 'arch/s390/boot/bzImage' not remade because of errors. make[2]: *** [arch/s390/Makefile:137: bzImage] Error 2The diff of cflags used for
arch/s390/boot:bad 2024-10-15 09:13:39.393060183 +0200 renamed from good 2024-10-15 09:13:59.769479783 +0200 +1
-1@@ -55,10 +55,10 @@ -Wno -array -bounds --march=z196 -mtune=z13 -Wa, -I/dev/shm/jslaby/linux/arch/s390/include +-march=z900 -I/dev/shm/jslaby/linux/arch/s390/boot -Iarch/s390/boot -DKBUILD_MODFILE='"arch/s390/boot/startup"'Reverting of this makes it work again:
commit51ab63c4cc8fbcfee58b8342a35006b45afbbd0d
Refs: v6.11.3-19-g51ab63c4cc8f
Author: Heiko Carstens <[email protected]>
AuthorDate: Wed Sep 4 11:39:27 2024 +0200
Commit: Greg Kroah-Hartman <[email protected]>
CommitDate: Mon Oct 14 16:10:09 2024 +0200
Quoted 8 lines
s390/boot: Compile all files with the same march flag
[ Upstream commit
fccb175bc89a0d37e3ff513bb6bf1f73b3a48950]If the above is to be really used in stable (REASONS?), I believe at least these are missing:
ebcc369f1891s390: Use MARCH_HAS_*_FEATURES defines697b37371f4as390: Provide MARCH_HAS_*_FEATURES defines
And this one:db545f538747 s390/boot: Increase minimum architecture to z10
Quoted 1 line
thanks,
Signature · 3 lines
-- js suse labs
Heiko Carstens
maintainerQuoted 16 lines · Jiri Slaby
Quoted 15 lines · Jiri Slaby
Quoted 1 line · Naresh Kamboju
On Mon, 14 Oct 2024 at 19:55, Greg Kroah-Hartman
Reverting of this makes it work again:
commit51ab63c4cc8fbcfee58b8342a35006b45afbbd0d
Refs: v6.11.3-19-g51ab63c4cc8f
Author: Heiko Carstens <[email protected]>
AuthorDate: Wed Sep 4 11:39:27 2024 +0200
Commit: Greg Kroah-Hartman <[email protected]>
CommitDate: Mon Oct 14 16:10:09 2024 +0200s390/boot: Compile all files with the same march flag
[ Upstream commit
fccb175bc89a0d37e3ff513bb6bf1f73b3a48950]
Quoted 7 lines
Quoted 4 lines
If the above is to be really used in stable (REASONS?), I believe at least these are missing:
ebcc369f1891s390: Use MARCH_HAS_*_FEATURES defines697b37371f4as390: Provide MARCH_HAS_*_FEATURES definesAnd this one:
db545f538747s390/boot: Increase minimum architecture to z10
All of this is not supposed to be stable material.
Greg Kroah-Hartman
maintainerQuoted 22 lines · Heiko Carstens
Quoted 21 lines · Jiri Slaby
Quoted 19 lines · Jiri Slaby
Quoted 1 line · Naresh Kamboju
On Mon, 14 Oct 2024 at 19:55, Greg Kroah-Hartman
Reverting of this makes it work again:
commit51ab63c4cc8fbcfee58b8342a35006b45afbbd0d
Refs: v6.11.3-19-g51ab63c4cc8f
Author: Heiko Carstens <[email protected]>
AuthorDate: Wed Sep 4 11:39:27 2024 +0200
Commit: Greg Kroah-Hartman <[email protected]>
CommitDate: Mon Oct 14 16:10:09 2024 +0200s390/boot: Compile all files with the same march flag
[ Upstream commit
fccb175bc89a0d37e3ff513bb6bf1f73b3a48950]If the above is to be really used in stable (REASONS?), I believe at least these are missing:
ebcc369f1891s390: Use MARCH_HAS_*_FEATURES defines697b37371f4as390: Provide MARCH_HAS_*_FEATURES defines
Quoted 5 lines
Quoted 2 lines
And this one:
db545f538747s390/boot: Increase minimum architecture to z10All of this is not supposed to be stable material.
Agreed, I'm dropping this compile s390 patch, thanks for the build testing everyone! Something went wrong with the testing on our end, odd...
thanks,
greg k-h
Quoted 18 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.
Quoted 3 lines
Quoted 3 lines
thanks,
greg k-h
[Adding Reported-by: ]
Quoted 7 lines
The S390 build broke on the stable-rc linux-6.11.y branch due to following build warnings / errors.
First seen on v6.11.3-215-ga491a66f8da4
GOOD: v6.11.3
BAD: v6.11.3-215-ga491a66f8da4
This S390 build regressions are noticed on stable-rc branches
- linux-6.11.y
- linux-6.6.y
- linux-6.1.y
Quoted 62 lines
List of regressions,
* s390, build
- clang-19-allnoconfig
- clang-19-defconfig
- clang-nightly-allnoconfig
- clang-nightly-defconfig
- gcc-13-allmodconfig
- gcc-13-allnoconfig
- gcc-13-defconfig
- gcc-13-tinyconfig
- gcc-8-allnoconfig
- gcc-8-defconfig-fe40093d
- gcc-8-tinyconfigBuild log:
-------
arch/s390/include/asm/cpu_mf.h: Assembler messages:
arch/s390/include/asm/cpu_mf.h:165: Error: Unrecognized opcode: `lpp' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/startup.o] Error 1
arch/s390/include/asm/atomic_ops.h: Assembler messages:
arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode:laag' arch/s390/include/asm/atomic_ops.h:83: Error: Unrecognized opcode:laag' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/vmem.o] Error 1
arch/s390/include/asm/bitops.h: Assembler messages:
arch/s390/include/asm/bitops.h:308: Error: Unrecognized opcode: `flogr' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/pgm_check_info.o] Error 1
arch/s390/include/asm/timex.h: Assembler messages:
arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode:stckf' arch/s390/include/asm/timex.h:192: Error: Unrecognized opcode:stckf' make[3]: *** [scripts/Makefile.build:244:arch/s390/boot/kaslr.o] Error 1 make[3]: Target 'arch/s390/boot/bzImage' not remade because of errors. make[2]: *** [arch/s390/Makefile:137: bzImage] Error 2Build log:
---------
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.11.y/build/v6.11.3-215-ga491a66f8da4/testrun/25429522/suite/build/test/gcc-13-defconfig/logmetadata:
----
git describe: v6.11.3-215-ga491a66f8da4
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git sha:a491a66f8da4fbfc06aedae9a8b0586d11a51fa9
kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2nQsfudCDSTlwmKIKEozbcVOnCs/config
build url: https://storage.tuxsuite.com/public/linaro/lkft/builds/2nQsfudCDSTlwmKIKEozbcVOnCs/
toolchain: clang-19 and gcc-13
config: defconfig
arch: S390Steps to reproduce:
-------# tuxmake --runtime podman --target-arch s390 --toolchain gcc-13 --kconfig defconfig--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +0000. Anything received after that time might be too late.
Tested on a ThinkPad E14 Gen 3 with a AMD Ryzen 5 5500U CPU and on the Steam Deck (LCD variant).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.11.4 release. There are 214 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 Wed, 16 Oct 2024 14:09:57 +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.11.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.11.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah