6.1.156-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 154/196 RDMA/siw: Always report immediate post SQ errors
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernard Metzler <[email protected]>
[ Upstream commit fdd0fe94d68649322e391c5c27dd9f436b4e955e ]
In siw_post_send(), any immediate error encountered during processing of the work request list must be reported to the caller, even if previous work requests in that list were just accepted and added to the send queue.
Not reporting those errors confuses the caller, which would wait indefinitely for the failing and potentially subsequently aborted work requests completion.
This fixes a case where immediate errors were overwritten by subsequent code in siw_post_send().
--- drivers/infiniband/sw/siw/siw_verbs.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
drivers/infiniband/sw/siw/siw_verbs.c +14 -11
@@ -761,7 +761,7 @@ int siw_post_send(struct ib_qp *base_qp, const struct ib_send_wr *wr,struct siw_wqe *wqe =tx_wqe (qp);unsigned long flags; -int rv =0 ; +int rv =0 , imm_err =0 ;if (wr && !rdma_is_kernel_res (&qp->base_qp.res)) {siw_dbg_qp (qp,"wr must be empty for user mapped sq\n" );
@@ -947,9 +947,17 @@ int siw_post_send(struct ib_qp *base_qp, const struct ib_send_wr *wr,* Send directly if SQ processing is not in progress. * Eventual immediate errors (rv < 0) do not affect the involved * RI resources (Verbs, 8.3.1) and thus do not prevent from SQ -* processing, if new work is already pending. But rv must be passed -* to caller. +* processing, if new work is already pending. But rv and pointer +* to failed work request must be passed to caller. */ +if (unlikely (rv <0 )) { +/* +* Immediate error +*/ +siw_dbg_qp (qp,"Immediate error %d\n" , rv); + imm_err = rv; + *bad_wr = wr; + }if (wqe->wr_status !=SIW_WR_IDLE ) {spin_unlock_irqrestore (&qp->sq_lock, flags); goto skip_direct_sending;
@@ -974,15 +982,10 @@ int siw_post_send(struct ib_qp *base_qp, const struct ib_send_wr *wr,up_read (&qp->state_lock); -if (rv >=0 ) -return 0 ; -/* -* Immediate error -*/ -siw_dbg_qp (qp,"error %d\n" , rv); +if (unlikely (imm_err)) +return imm_err; - *bad_wr = wr; -return rv; +return (rv >=0 ) ?0 : rv; }/*
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 155/196 net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: I Viswanath <[email protected]>
[ Upstream commit 958baf5eaee394e5fd976979b0791a875f14a179 ]
syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb. This is the sequence of events that leads to the warning:
rtl8150_start_xmit() {
netif_stop_queue();
usb_submit_urb(dev->tx_urb);
}rtl8150_set_multicast() {
netif_stop_queue();
netif_wake_queue(); <-- wakes up TX queue before URB is done
}rtl8150_start_xmit() {
netif_stop_queue();
usb_submit_urb(dev->tx_urb); <-- double submission
}rtl8150_set_multicast being the ndo_set_rx_mode callback should not be calling netif_stop_queue and notif_start_queue as these handle TX queue synchronization.
The net core function dev_set_rx_mode handles the synchronization for rtl8150_set_multicast making it safe to remove these locks.
--- drivers/net/usb/rtl8150.c | 2 -- 1 file changed, 2 deletions(-)
drivers/net/usb/rtl8150.c +0 -2
@@ -664,7 +664,6 @@ static void rtl8150_set_multicast(struct net_device *netdev)rtl8150_t *dev =netdev_priv (netdev);u16 rx_creg =0x9e ; -netif_stop_queue (netdev);if (netdev->flags &IFF_PROMISC ) { rx_creg |=0x0001 ;dev_info (&netdev->dev,"%s: promiscuous mode\n" , netdev->name);
@@ -678,7 +677,6 @@ static void rtl8150_set_multicast(struct net_device *netdev) rx_creg &=0x00fc ; }async_set_registers (dev,RCR ,sizeof (rx_creg), rx_creg); -netif_wake_queue (netdev); } static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 156/196 vhost: vringh: Fix copy_to_iter return value check
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael S. Tsirkin <[email protected]>
[ Upstream commit 439263376c2c4e126cac0d07e4987568de4eaba5 ]
The return value of copy_to_iter can't be negative, check whether the copied length is equal to the requested length instead of checking for negative values.
--- drivers/vhost/vringh.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/vhost/vringh.c +4 -3
@@ -1195,6 +1195,7 @@ static inline int copy_to_iotlb(const struct vringh *vrh, void *dst,struct iov_iter iter;u64 translated;int ret; +size_t size; ret = iotlb_translate(vrh, (u64)(uintptr_t)dst, len - total_translated, &translated,
@@ -1206,9 +1207,9 @@ static inline int copy_to_iotlb(const struct vringh *vrh, void *dst,iov_iter_bvec (&iter,ITER_DEST , iov, ret, translated); - ret =copy_to_iter (src, translated, &iter); -if (ret <0 ) -return ret; + size =copy_to_iter (src, translated, &iter); +if (size != translated) +return -EFAULT ; src += translated; dst += translated;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 157/196 Bluetooth: MGMT: Fix not exposing debug UUID on MGMT_OP_READ_EXP_FEATURES_INFO
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit 79e562a52adea4afa0601a15964498fae66c823c ]
The debug UUID was only getting set if MGMT_OP_READ_EXP_FEATURES_INFO was not called with a specific index which breaks the likes of bluetoothd since it only invokes MGMT_OP_READ_EXP_FEATURES_INFO when an adapter is plugged, so instead of depending hdev not to be set just enable the UUID on any index like it was done with iso_sock_uuid.
--- net/bluetooth/mgmt.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
net/bluetooth/mgmt.c +4 -6
@@ -4483,13 +4483,11 @@ static int read_exp_features_info(struct sock *sk, struct hci_dev *hdev,return -ENOMEM ;#ifdef CONFIG_BT_FEATURE_DEBUG -if (!hdev) { - flags =bt_dbg_get () ?BIT (0 ) :0 ; + flags =bt_dbg_get () ?BIT (0 ) :0 ; -memcpy (rp->features[idx].uuid, debug_uuid,16 ); - rp->features[idx].flags =cpu_to_le32 (flags); - idx++; - } +memcpy (rp->features[idx].uuid, debug_uuid,16 ); + rp->features[idx].flags =cpu_to_le32 (flags); + idx++;#endif if (hdev &&hci_dev_le_state_simultaneous (hdev)) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 158/196 Bluetooth: ISO: Fix possible UAF on iso_conn_free
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit 9950f095d6c875dbe0c9ebfcf972ec88fdf26fc8 ]
This attempt to fix similar issue to sco_conn_free where if the conn->sk is not set to NULL may lead to UAF on iso_conn_free.
--- net/bluetooth/iso.c | 7 +++++++ 1 file changed, 7 insertions(+)
net/bluetooth/iso.c +7 -0
@@ -581,6 +581,13 @@ static void iso_sock_kill(struct sock *sk)BT_DBG ("sk %p state %d" , sk, sk->sk_state); +/* Sock is dead, so set conn->sk to NULL to avoid possible UAF */ +if (iso_pi (sk)->conn) { +iso_conn_lock (iso_pi (sk)->conn); +iso_pi (sk)->conn->sk =NULL ; +iso_conn_unlock (iso_pi (sk)->conn); + } +/* Kill poor orphan */ bt_sock_unlink (&iso_sk_list, sk);sock_set_flag (sk,SOCK_DEAD );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 159/196 Bluetooth: ISO: dont leak skb in ISO_CONT RX
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pauli Virtanen <[email protected]>
[ Upstream commit 5bf863f4c5da055c1eb08887ae4f26d99dbc4aac ]
For ISO_CONT RX, the data from skb is copied to conn->rx_skb, but the skb is leaked.
Free skb after copying its data.
--- net/bluetooth/iso.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bluetooth/iso.c +1 -1
@@ -1729,7 +1729,7 @@ void iso_recv(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)skb_copy_from_linear_data (skb,skb_put (conn->rx_skb, skb->len), skb->len); conn->rx_len -= skb->len; -return ; +break ;case ISO_END : skb_copy_from_linear_data(skb, skb_put(conn->rx_skb, skb->len),
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 160/196 Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit 03ddb4ac251463ec5b7b069395d9ab89163dd56c ]
When creating an advertisement for BIG the address shall not be non-resolvable since in case of acting as BASS/Broadcast Assistant the address must be the same as the connection in order to use the PAST method and even when PAST/BASS are not in the picture a Periodic Advertisement can still be synchronized thus the same argument as to connectable advertisements still stand.
--- net/bluetooth/hci_sync.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
net/bluetooth/hci_sync.c +6 -4
@@ -1304,7 +1304,7 @@ int hci_setup_ext_adv_instance_sync(struct hci_dev *hdev, u8 instance) {struct hci_cp_le_set_ext_adv_params cp;struct hci_rp_le_set_ext_adv_params rp; -bool connectable; +bool connectable, require_privacy;u32 flags;bdaddr_t random_addr;u8 own_addr_type;
@@ -1342,10 +1342,12 @@ int hci_setup_ext_adv_instance_sync(struct hci_dev *hdev, u8 instance)return -EPERM ;/* Set require_privacy to true only when non-connectable -* advertising is used. In that case it is fine to use a -* non-resolvable private address. +* advertising is used and it is not periodic. +* In that case it is fine to use a non-resolvable private address. */ - err =hci_get_random_address (hdev, !connectable, + require_privacy = !connectable && !(adv && adv->periodic); + + err =hci_get_random_address (hdev, require_privacy,adv_use_rpa (hdev, flags), adv, &own_addr_type, &random_addr);if (err <0 )
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 161/196 hwrng: ks-sa - fix division by zero in ks_sa_rng_init
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nishanth Menon <[email protected]>
[ Upstream commit 612b1dfeb414dfa780a6316014ceddf9a74ff5c0 ]
Fix division by zero in ks_sa_rng_init caused by missing clock pointer initialization. The clk_get_rate() call is performed on an uninitialized clk pointer, resulting in division by zero when calculating delay values.
Add clock initialization code before using the clock.
drivers/char/hw_random/ks-sa-rng.c | 7 +++++++ 1 file changed, 7 insertions(+)
--- drivers/char/hw_random/ks-sa-rng.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/char/hw_random/ks-sa-rng.c +4 -0
@@ -240,6 +240,10 @@ static int ks_sa_rng_probe(struct platform_device *pdev)return -EINVAL ; } + ks_sa_rng->clk =devm_clk_get_enabled (dev,NULL ); +if (IS_ERR (ks_sa_rng->clk)) +return dev_err_probe (dev,PTR_ERR (ks_sa_rng->clk),"Failed to get clock\n" ); +pm_runtime_enable (dev); ret =pm_runtime_resume_and_get (dev);if (ret <0 ) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 162/196 ocfs2: fix double free in user_cluster_connect()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 8f45f089337d924db24397f55697cda0e6960516 ]
user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free.
--- fs/ocfs2/stack_user.c | 1 + 1 file changed, 1 insertion(+)
fs/ocfs2/stack_user.c +1 -0
@@ -1024,6 +1024,7 @@ static int user_cluster_connect(struct ocfs2_cluster_connection *conn)printk (KERN_ERR "ocfs2: Could not determine" " locking version\n" );user_cluster_disconnect (conn); + lc =NULL ; goto out; }wait_event (lc->oc_wait, (atomic_read (&lc->oc_this_node) >0 ));
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 163/196 drivers/base/node: fix double free in register_one_node()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Donet Tom <[email protected]>
[ Upstream commit 0efdedfa537eb534c251a5b4794caaf72cc55869 ]
When device_register() fails in register_node(), it calls put_device(&node->dev). This triggers node_device_release(), which calls kfree(to_node(dev)), thereby freeing the entire node structure.
As a result, when register_node() returns an error, the node memory has already been freed. Calling kfree(node) again in register_one_node() leads to a double free.
This patch removes the redundant kfree(node) from register_one_node() to prevent the double free.
--- drivers/base/node.c | 1 - 1 file changed, 1 deletion(-)
drivers/base/node.c +0 -1
@@ -871,7 +871,6 @@ int __register_one_node(int nid) error =register_node (node_devices[nid], nid);if (error) { node_devices[nid] =NULL ; -kfree (node);return error; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 164/196 mtd: rawnand: atmel: Fix error handling path in atmel_nand_controller_add_nands
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Erick Karanja <[email protected]>
[ Upstream commit 8ed4728eb9f10b57c3eb02e0f6933a89ffcb8a91 ]
In case of a jump to the err label due to atmel_nand_create() or atmel_nand_controller_add_nand() failure, the reference to nand_np need to be released
Use for_each_child_of_node_scoped() to fix the issue.
--- drivers/mtd/nand/raw/atmel/nand-controller.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mtd/nand/raw/atmel/nand-controller.c +2 -2
@@ -1859,7 +1859,7 @@ atmel_nand_controller_legacy_add_nands(struct atmel_nand_controller *nc)static int atmel_nand_controller_add_nands (struct atmel_nand_controller *nc) { -struct device_node *np, *nand_np; +struct device_node *np;struct device *dev = nc->dev;int ret, reg_cells;u32 val;
@@ -1886,7 +1886,7 @@ static int atmel_nand_controller_add_nands(struct atmel_nand_controller *nc) reg_cells += val; -for_each_child_of_node (np, nand_np) { +for_each_child_of_node_scoped (np, nand_np) {struct atmel_nand *nand; nand =atmel_nand_create (nc, nand_np, reg_cells);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 165/196 nfp: fix RSS hash key size when RSS is not supported
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kohei Enju <[email protected]>
[ Upstream commit 8425161ac1204d2185e0a10f5ae652bae75d2451 ]
The nfp_net_get_rxfh_key_size() function returns -EOPNOTSUPP when devices don't support RSS, and callers treat the negative value as a large positive value since the return type is u32.
Return 0 when devices don't support RSS, aligning with the ethtool interface .get_rxfh_key_size() that requires returning 0 in such cases.
--- drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c +1 -1
@@ -1409,7 +1409,7 @@ static u32 nfp_net_get_rxfh_key_size(struct net_device *netdev)struct nfp_net *nn =netdev_priv (netdev);if (!(nn->cap &NFP_NET_CFG_CTRL_RSS_ANY )) -return -EOPNOTSUPP ; +return 0 ;return nfp_net_rss_key_sz (nn); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 166/196 net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not configurable
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kohei Enju <[email protected]>
[ Upstream commit f017156aea60db8720e47591ed1e041993381ad2 ]
In EC2 instances where the RSS hash key is not configurable, ethtool shows bogus RSS hash key since ena_get_rxfh_key_size() unconditionally returns ENA_HASH_KEY_SIZE.
Commit 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not supported") added proper handling for devices that don't support RSS hash key configuration, but ena_get_rxfh_key_size() has been unchanged.
When the RSS hash key is not configurable, return 0 instead of ENA_HASH_KEY_SIZE to clarify getting the value is not supported.
Tested on m5 instance families.
Without patch:
# ethtool -x ens5 | grep -A 1 "RSS hash key" RSS hash key: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
With patch:
# ethtool -x ens5 | grep -A 1 "RSS hash key" RSS hash key: Operation not supported
--- drivers/net/ethernet/amazon/ena/ena_ethtool.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/amazon/ena/ena_ethtool.c +4 -1
@@ -695,7 +695,10 @@ static u32 ena_get_rxfh_indir_size(struct net_device *netdev)static u32 ena_get_rxfh_key_size (struct net_device *netdev) { -return ENA_HASH_KEY_SIZE ; +struct ena_adapter *adapter =netdev_priv (netdev); +struct ena_rss *rss = &adapter->ena_dev->rss; + +return rss->hash_key ?ENA_HASH_KEY_SIZE :0 ; } static int ena_indirection_table_set(struct ena_adapter *adapter,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 167/196 net: dlink: handle copy_thresh allocation failure
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yeounsu Moon <[email protected]>
[ Upstream commit 8169a6011c5fecc6cb1c3654c541c567d3318de8 ]
The driver did not handle failure of netdev_alloc_skb_ip_align(). If the allocation failed, dereferencing skb->protocol could lead to a NULL pointer dereference.
This patch tries to allocate skb. If the allocation fails, it falls back to the normal path.
Tested-on: D-Link DGE-550T Rev-A3
--- drivers/net/ethernet/dlink/dl2k.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/dlink/dl2k.c +5 -2
@@ -956,15 +956,18 @@ receive_packet (struct net_device *dev) }else {struct sk_buff *skb; + skb =NULL ;/* Small skbuffs for short packets */ -if (pkt_len > copy_thresh) { +if (pkt_len <= copy_thresh) + skb =netdev_alloc_skb_ip_align (dev, pkt_len); +if (!skb) {dma_unmap_single (&np->pdev->dev,desc_to_dma (desc), np->rx_buf_sz,DMA_FROM_DEVICE );skb_put (skb = np->rx_skbuff[entry], pkt_len); np->rx_skbuff[entry] =NULL ; - }else if ((skb =netdev_alloc_skb_ip_align (dev, pkt_len))) { + }else { dma_sync_single_for_cpu(&np->pdev->dev, desc_to_dma(desc), np->rx_buf_sz,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 168/196 net/mlx5: Stop polling for command response if interface goes down
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Moshe Shemesh <[email protected]>
[ Upstream commit b1f0349bd6d320c382df2e7f6fc2ac95c85f2b18 ]
Stop polling on firmware response to command in polling mode if the command interface got down. This situation can occur, for example, if a firmware fatal error is detected during polling.
This change halts the polling process when the command interface goes down, preventing unnecessary waits.
--- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/cmd.c +5 -1
@@ -289,6 +289,10 @@ static void poll_timeout(struct mlx5_cmd_work_ent *ent)return ; }cond_resched (); +if (mlx5_cmd_is_down (dev)) { + ent->ret = -ENXIO ; +return ; + } }while (time_before (jiffies, poll_end)); ent->ret = -ETIMEDOUT ;
@@ -1056,7 +1060,7 @@ static void cmd_work_handler(struct work_struct *work)poll_timeout (ent);/* make sure we read the descriptor after ownership is SW */ rmb (); -mlx5_cmd_comp_handler (dev,1ULL << ent->idx, (ent->ret == -ETIMEDOUT )); +mlx5_cmd_comp_handler (dev,1ULL << ent->idx, !!ent->ret); } }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 169/196 net/mlx5: pagealloc: Fix reclaim race during command interface teardown
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shay Drory <[email protected]>
[ Upstream commit 79a0e32b32ac4e4f9e4bb22be97f371c8c116c88 ]
The reclaim_pages_cmd() function sends a command to the firmware to reclaim pages if the command interface is active.
A race condition can occur if the command interface goes down (e.g., due to a PCI error) while the mlx5_cmd_do() call is in flight. In this case, mlx5_cmd_do() will return an error. The original code would propagate this error immediately, bypassing the software-based page reclamation logic that is supposed to run when the command interface is down.
Fix this by checking whether mlx5_cmd_do() returns -ENXIO, which mark that command interface is down. If this is the case, fall through to the software reclamation path. If the command failed for any another reason, or finished successfully, return as before.
--- drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c +5 -2
@@ -483,9 +483,12 @@ static int reclaim_pages_cmd(struct mlx5_core_dev *dev,u32 func_id;u32 npages;u32 i =0 ; +int err; -if (!mlx5_cmd_is_down (dev)) -return mlx5_cmd_do (dev, in, in_size, out, out_size); + err =mlx5_cmd_do (dev, in, in_size, out, out_size); +/* If FW is gone (-ENXIO), proceed to forceful reclaim */ +if (err != -ENXIO ) +return err;/* No hard feelings, we want our pages back! */ npages =MLX5_GET (manage_pages_in, in, input_num_entries);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 170/196 net/mlx5: fw reset, add reset timeout work
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Moshe Shemesh <[email protected]>
[ Upstream commit 5cfbe7ebfa42fd3c517a701dab5bd73524da9088 ]
Add sync reset timeout to stop poll_sync_reset in case there was no reset done or abort event within timeout. Otherwise poll sync reset will just continue and in case of fw fatal error no health reporting will be done.
--- .../ethernet/mellanox/mlx5/core/fw_reset.c | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c +24 -0
@@ -22,6 +22,7 @@ struct mlx5_fw_reset {struct work_struct reset_reload_work;struct work_struct reset_now_work;struct work_struct reset_abort_work; +struct delayed_work reset_timeout_work;unsigned long reset_flags;struct timer_list timer;struct completion done;
@@ -180,6 +181,8 @@ static int mlx5_sync_reset_clear_reset_requested(struct mlx5_core_dev *dev, boolreturn -EALREADY ; } +if (current_work () != &fw_reset->reset_timeout_work.work) +cancel_delayed_work (&fw_reset->reset_timeout_work);mlx5_stop_sync_reset_poll (dev);if (poll_health)mlx5_start_health_poll (dev);
@@ -250,6 +253,11 @@ static int mlx5_sync_reset_set_reset_requested(struct mlx5_core_dev *dev) }mlx5_stop_health_poll (dev, true);mlx5_start_sync_reset_poll (dev); + +if (!test_bit (MLX5_FW_RESET_FLAGS_DROP_NEW_REQUESTS , + &fw_reset->reset_flags)) +schedule_delayed_work (&fw_reset->reset_timeout_work, +msecs_to_jiffies (mlx5_tout_ms (dev,PCI_SYNC_UPDATE )));return 0 ; }
@@ -445,6 +453,19 @@ static void mlx5_sync_reset_events_handle(struct mlx5_fw_reset *fw_reset, struct } } +static void mlx5_sync_reset_timeout_work (struct work_struct *work) +{ + struct delayed_work *dwork = container_of(work, struct delayed_work, + work); +struct mlx5_fw_reset *fw_reset = + container_of(dwork, struct mlx5_fw_reset, reset_timeout_work); +struct mlx5_core_dev *dev = fw_reset->dev; + +if (mlx5_sync_reset_clear_reset_requested (dev, true)) +return ; +mlx5_core_warn (dev,"PCI Sync FW Update Reset Timeout.\n" ); +} +static int fw_reset_event_notifier (struct notifier_block *nb,unsigned long action,void *data) { struct mlx5_fw_reset *fw_reset = mlx5_nb_cof(nb, struct mlx5_fw_reset, nb);
@@ -513,6 +534,7 @@ void mlx5_drain_fw_reset(struct mlx5_core_dev *dev)cancel_work_sync (&fw_reset->reset_reload_work);cancel_work_sync (&fw_reset->reset_now_work);cancel_work_sync (&fw_reset->reset_abort_work); +cancel_delayed_work (&fw_reset->reset_timeout_work); }int mlx5_fw_reset_init (struct mlx5_core_dev *dev)
@@ -535,6 +557,8 @@ int mlx5_fw_reset_init(struct mlx5_core_dev *dev)INIT_WORK (&fw_reset->reset_reload_work, mlx5_sync_reset_reload_work);INIT_WORK (&fw_reset->reset_now_work, mlx5_sync_reset_now_event);INIT_WORK (&fw_reset->reset_abort_work, mlx5_sync_reset_abort_event); +INIT_DELAYED_WORK (&fw_reset->reset_timeout_work, + mlx5_sync_reset_timeout_work);init_completion (&fw_reset->done);return 0 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 171/196 Revert "net/mlx5e: Update and set Xon/Xoff upon MTU set"
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit 6f5dacf88a32b3fd8b52c8ea781bf188c42aaa95 ]
This reverts commit ceddedc969f0532b7c62ca971ee50d519d2bc0cb.
Commit in question breaks the mapping of PGs to pools for some SKUs. Specifically multi-host NICs seem to be shipped with a custom buffer configuration which maps the lossy PG to pool 4. But the bad commit overrides this with pool 0 which does not have sufficient buffer space reserved. Resulting in ~40% packet loss. The commit also breaks BMC / OOB connection completely (100% packet loss).
Revert, similarly to commit 3fbfe251cc9f ("Revert "net/mlx5e: Update and set Xon/Xoff upon port speed set""). The breakage is exactly the same, the only difference is that quoted commit would break the NIC immediately on boot, and the currently reverted commit only when MTU is changed.
Note: "good" kernels do not restore the configuration, so downgrade isn't enough to recover machines. A NIC power cycle seems to be necessary to return to a healthy state (or overriding the relevant registers using a custom patch).
--- .../mellanox/mlx5/core/en/port_buffer.h | 12 ------------ .../net/ethernet/mellanox/mlx5/core/en_main.c | 17 +---------------- 2 files changed, 1 insertion(+), 28 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.h +0 -12
@@ -63,23 +63,11 @@ struct mlx5e_port_buffer {struct mlx5e_bufferx_reg buffer[MLX5E_MAX_BUFFER ]; }; -#ifdef CONFIG_MLX5_CORE_EN_DCB int mlx5e_port_manual_buffer_config (struct mlx5e_priv *priv,u32 change,unsigned int mtu,struct ieee_pfc *pfc,u32 *buffer_size,u8 *prio2buffer); -#else -static inline int -mlx5e_port_manual_buffer_config (struct mlx5e_priv *priv, -u32 change,unsigned int mtu, -void *pfc, -u32 *buffer_size, -u8 *prio2buffer) -{ -return 0 ; -} -#endif int mlx5e_port_query_buffer (struct mlx5e_priv *priv,struct mlx5e_port_buffer *port_buffer);
drivers/net/ethernet/mellanox/mlx5/core/en_main.c +1 -16
@@ -42,7 +42,6 @@#include "eswitch.h" #include "en.h" #include "en/txrx.h" -#include "en/port_buffer.h" #include "en_tc.h" #include "en_rep.h" #include "en_accel/ipsec.h"
@@ -2641,11 +2640,9 @@ int mlx5e_set_dev_port_mtu(struct mlx5e_priv *priv)struct mlx5e_params *params = &priv->channels.params;struct net_device *netdev = priv->netdev;struct mlx5_core_dev *mdev = priv->mdev; -u16 mtu, prev_mtu; +u16 mtu;int err; -mlx5e_query_mtu (mdev, params, &prev_mtu); - err =mlx5e_set_mtu (mdev, params, params->sw_mtu);if (err)return err;
@@ -2655,18 +2652,6 @@ int mlx5e_set_dev_port_mtu(struct mlx5e_priv *priv)netdev_warn (netdev,"%s: VPort MTU %d is different than netdev mtu %d\n" , __func__, mtu, params->sw_mtu); -if (mtu != prev_mtu &&MLX5_BUFFER_SUPPORTED (mdev)) { - err =mlx5e_port_manual_buffer_config (priv,0 , mtu, -NULL ,NULL ,NULL ); -if (err) { -netdev_warn (netdev,"%s: Failed to set Xon/Xoff values with MTU %d (err %d), setting back to previous MTU %d\n" , - __func__, mtu, err, prev_mtu); - -mlx5e_set_mtu (mdev, params, prev_mtu); -return err; - } - } - params->sw_mtu = mtu;return 0 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 172/196 vhost: vringh: Modify the return value check
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhang jiao <[email protected]>
[ Upstream commit 82a8d0fda55b35361ee7f35b54fa2b66d7847d2b ]
The return value of copy_from_iter and copy_to_iter can't be negative, check whether the copied lengths are equal.
Message-Id: <[email protected]>
--- drivers/vhost/vringh.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/vhost/vringh.c +4 -3
@@ -1162,6 +1162,7 @@ static inline int copy_from_iotlb(const struct vringh *vrh, void *dst,struct iov_iter iter;u64 translated;int ret; +size_t size; ret = iotlb_translate(vrh, (u64)(uintptr_t)src, len - total_translated, &translated,
@@ -1173,9 +1174,9 @@ static inline int copy_from_iotlb(const struct vringh *vrh, void *dst,iov_iter_bvec (&iter,ITER_SOURCE , iov, ret, translated); - ret =copy_from_iter (dst, translated, &iter); -if (ret <0 ) -return ret; + size =copy_from_iter (dst, translated, &iter); +if (size != translated) +return -EFAULT ; src += translated; dst += translated;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 173/196 Squashfs: fix uninit-value in squashfs_get_parent
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phillip Lougher <[email protected]>
commit 74058c0a9fc8b2b4d5f4a0ef7ee2cfa66a9e49cf upstream.
Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.
This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory.
Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field.
unsigned int parent_ino = squashfs_i(inode)->parent;
Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access.
The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned.
Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0.
--- fs/squashfs/inode.c | 7 +++++++ fs/squashfs/squashfs_fs_i.h | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-)
fs/squashfs/inode.c +7 -0
@@ -165,6 +165,7 @@ int squashfs_read_inode(struct inode *insquashfs_i (inode)->start =le32_to_cpu (sqsh_ino->start_block);squashfs_i (inode)->block_list_start = block;squashfs_i (inode)->offset = offset; +squashfs_i (inode)->parent =0 ; inode->i_data.a_ops = &squashfs_aops; TRACE("File inode %x:%x, start_block %llx, block_list_start "
@@ -212,6 +213,7 @@ int squashfs_read_inode(struct inode *insquashfs_i (inode)->start =le64_to_cpu (sqsh_ino->start_block);squashfs_i (inode)->block_list_start = block;squashfs_i (inode)->offset = offset; +squashfs_i (inode)->parent =0 ; inode->i_data.a_ops = &squashfs_aops; TRACE("File inode %x:%x, start_block %llx, block_list_start "
@@ -292,6 +294,7 @@ int squashfs_read_inode(struct inode *in inode->i_mode |=S_IFLNK ;squashfs_i (inode)->start = block;squashfs_i (inode)->offset = offset; +squashfs_i (inode)->parent =0 ;if (type ==SQUASHFS_LSYMLINK_TYPE ) {__le32 xattr;
@@ -329,6 +332,7 @@ int squashfs_read_inode(struct inode *inset_nlink (inode,le32_to_cpu (sqsh_ino->nlink)); rdev =le32_to_cpu (sqsh_ino->rdev);init_special_inode (inode, inode->i_mode,new_decode_dev (rdev)); +squashfs_i (inode)->parent =0 ;TRACE ("Device inode %x:%x, rdev %x\n" ,SQUASHFS_INODE_BLK (ino), offset, rdev);
@@ -353,6 +357,7 @@ int squashfs_read_inode(struct inode *inset_nlink (inode,le32_to_cpu (sqsh_ino->nlink)); rdev =le32_to_cpu (sqsh_ino->rdev);init_special_inode (inode, inode->i_mode,new_decode_dev (rdev)); +squashfs_i (inode)->parent =0 ;TRACE ("Device inode %x:%x, rdev %x\n" ,SQUASHFS_INODE_BLK (ino), offset, rdev);
@@ -373,6 +378,7 @@ int squashfs_read_inode(struct inode *in inode->i_mode |=S_IFSOCK ;set_nlink (inode,le32_to_cpu (sqsh_ino->nlink));init_special_inode (inode, inode->i_mode,0 ); +squashfs_i (inode)->parent =0 ;break ; }case SQUASHFS_LFIFO_TYPE :
@@ -392,6 +398,7 @@ int squashfs_read_inode(struct inode *in inode->i_op = &squashfs_inode_ops;set_nlink (inode,le32_to_cpu (sqsh_ino->nlink));init_special_inode (inode, inode->i_mode,0 ); +squashfs_i (inode)->parent =0 ;break ; }default :
fs/squashfs/squashfs_fs_i.h +1 -1
@@ -16,6 +16,7 @@ struct squashfs_inode_info {u64 xattr;unsigned int xattr_size;int xattr_count; +int parent; union { struct { u64 fragment_block;
@@ -27,7 +28,6 @@ struct squashfs_inode_info {u64 dir_idx_start;int dir_idx_offset;int dir_idx_cnt; -int parent; }; };struct inode vfs_inode;
Greg Kroah-Hartman
maintainerPATCH 174/196 uio_hv_generic: Let userspace take care of interrupt mask
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Naman Jain <[email protected]>
commit b15b7d2a1b09ef5428a8db260251897405a19496 upstream.
Remove the logic to set interrupt mask by default in uio_hv_generic driver as the interrupt mask value is supposed to be controlled completely by the user space. If the mask bit gets changed by the driver, concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, and the user-mode driver will miss an interrupt which will cause a hang.
For eg- when the driver sets inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. So let’s assume that happens, the host puts a message into the ring buffer but does not interrupt.
Subsequently, the user space code in the guest sets the inbound ring buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”. User space code then calls pread() to wait for an interrupt. Then one of two things happens:
* The host never sends another message. So the pread() waits forever.
* The host does send another message. But because there’s already a message in the ring buffer, it doesn’t generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.
This could be easily reproduced in hv_fcopy_uio_daemon if we delay setting interrupt mask to 0.
Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1, there’s a race condition. Once user space empties the inbound ring buffer, but before user space sets interrupt_mask to 0, the host could put another message in the ring buffer but it wouldn’t interrupt. Then the next pread() would hang.
Fix these by removing all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable userspace control the interrupt mask by writing 0/1 to /dev/uioX.
--- drivers/uio/uio_hv_generic.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
drivers/uio/uio_hv_generic.c +1 -6
@@ -96,7 +96,6 @@ static void hv_uio_channel_cb(void *contstruct hv_device *hv_dev = chan->device_obj;struct hv_uio_private_data *pdata =hv_get_drvdata (hv_dev); - chan->inbound.ring_buffer->interrupt_mask =1 ;virt_mb ();uio_event_notify (&pdata->info);
@@ -173,8 +172,6 @@ hv_uio_new_channel(struct vmbus_channelreturn ; } -/* Disable interrupts on sub channel */ - new_sc->inbound.ring_buffer->interrupt_mask =1 ;set_channel_read_mode (new_sc,HV_CALL_ISR ); ret =sysfs_create_bin_file (&new_sc->kobj, &ring_buffer_bin_attr);
@@ -218,9 +215,7 @@ hv_uio_open(struct uio_info *info, struc ret =vmbus_connect_ring (dev->channel, hv_uio_channel_cb, dev->channel); -if (ret ==0 ) - dev->channel->inbound.ring_buffer->interrupt_mask =1 ; -else +if (ret)atomic_dec (&pdata->refcnt);return ret;
Greg Kroah-Hartman
maintainerPATCH 175/196 fs: udf: fix OOB read in lengthAllocDescs handling
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larshin Sergey <[email protected]>
commit 3bd5e45c2ce30e239d596becd5db720f7eb83c99 upstream.
When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read.
BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309 CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
Validate the computed total length against epos->bh->b_size.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
--- fs/udf/inode.c | 3 +++ 1 file changed, 3 insertions(+)
fs/udf/inode.c +3 -0
@@ -2112,6 +2112,9 @@ int udf_current_aext(struct inode *inodeif (check_add_overflow (sizeof (struct allocExtDesc ),le32_to_cpu (header->lengthAllocDescs), &alen))return -1 ; + +if (alen > epos->bh->b_size) +return -1 ; }switch (iinfo->i_alloc_type) {
Greg Kroah-Hartman
maintainerPATCH 176/196 net: nfc: nci: Add parameter validation for packet data
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepak Sharma <[email protected]>
commit 9c328f54741bd5465ca1dc717c84c04242fac2e1 upstream.
Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' ofgit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").
This bug arises due to very limited and poor input validation that was done at nic_valid_size(). This validation only validates the skb->len (directly reflects size provided at the userspace interface) with the length provided in the buffer itself (interpreted as NCI_HEADER). This leads to the processing of memory content at the address assuming the correct layout per what opcode requires there. This leads to the accesses to buffer of skb_buff->data which is not assigned anything yet.
Following the same silent drop of packets of invalid sizes at nic_valid_size(), add validation of the data in the respective handlers and return error values in case of failure. Release the skb if error values are returned from handlers in nci_nft_packet and effectively do a silent drop
Possible TODO: because we silently drop the packets, the call to nci_request will be waiting for completion of request and will face timeouts. These timeouts can get excessively logged in the dmesg. A proper handling of them may require to export nci_request_cancel (or propagate error handling from the nft packets handlers).
--- net/nfc/nci/ntf.c | 135 +++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 99 insertions(+), 36 deletions(-)
net/nfc/nci/ntf.c +99 -36
@@ -27,11 +27,16 @@/* Handle NCI Notification packets */ -static void nci_core_reset_ntf_packet (struct nci_dev *ndev, -const struct sk_buff *skb) +static int nci_core_reset_ntf_packet (struct nci_dev *ndev, +const struct sk_buff *skb) {/* Handle NCI 2.x core reset notification */ -const struct nci_core_reset_ntf *ntf = (void *)skb->data; +const struct nci_core_reset_ntf *ntf; + +if (skb->len <sizeof (struct nci_core_reset_ntf )) +return -EINVAL ; + + ntf = (struct nci_core_reset_ntf *)skb->data; ndev->nci_ver = ntf->nci_ver; pr_debug("nci_ver 0x%x, config_status 0x%x\n",
@@ -42,15 +47,22 @@ static void nci_core_reset_ntf_packet(st__le32_to_cpu (ntf->manufact_specific_info);nci_req_complete (ndev,NCI_STATUS_OK ); + +return 0 ; } -static void nci_core_conn_credits_ntf_packet (struct nci_dev *ndev, -struct sk_buff *skb) +static int nci_core_conn_credits_ntf_packet (struct nci_dev *ndev, +struct sk_buff *skb) { -struct nci_core_conn_credit_ntf *ntf = (void *) skb->data; +struct nci_core_conn_credit_ntf *ntf;struct nci_conn_info *conn_info;int i; +if (skb->len <sizeof (struct nci_core_conn_credit_ntf )) +return -EINVAL ; + + ntf = (struct nci_core_conn_credit_ntf *)skb->data; +pr_debug ("num_entries %d\n" , ntf->num_entries);if (ntf->num_entries >NCI_MAX_NUM_CONN )
@@ -68,7 +80,7 @@ static void nci_core_conn_credits_ntf_pa conn_info =nci_get_conn_info_by_conn_id (ndev, ntf->conn_entries[i].conn_id);if (!conn_info) -return ; +return 0 ;atomic_add (ntf->conn_entries[i].credits, &conn_info->credits_cnt);
@@ -77,12 +89,19 @@ static void nci_core_conn_credits_ntf_pa/* trigger the next tx */ if (!skb_queue_empty (&ndev->tx_q))queue_work (ndev->tx_wq, &ndev->tx_work); + +return 0 ; } -static void nci_core_generic_error_ntf_packet (struct nci_dev *ndev, -const struct sk_buff *skb) +static int nci_core_generic_error_ntf_packet (struct nci_dev *ndev, +const struct sk_buff *skb) { -__u8 status = skb->data[0 ]; +__u8 status; + +if (skb->len <1 ) +return -EINVAL ; + + status = skb->data[0 ];pr_debug ("status 0x%x\n" , status);
@@ -91,12 +110,19 @@ static void nci_core_generic_error_ntf_p(the state remains the same) */ nci_req_complete (ndev, status); } + +return 0 ; } -static void nci_core_conn_intf_error_ntf_packet (struct nci_dev *ndev, -struct sk_buff *skb) +static int nci_core_conn_intf_error_ntf_packet (struct nci_dev *ndev, +struct sk_buff *skb) { -struct nci_core_intf_error_ntf *ntf = (void *) skb->data; +struct nci_core_intf_error_ntf *ntf; + +if (skb->len <sizeof (struct nci_core_intf_error_ntf )) +return -EINVAL ; + + ntf = (struct nci_core_intf_error_ntf *)skb->data; ntf->conn_id =nci_conn_id (&ntf->conn_id);
@@ -105,6 +131,8 @@ static void nci_core_conn_intf_error_ntf/* complete the data exchange transaction, if exists */ if (test_bit (NCI_DATA_EXCHANGE , &ndev->flags))nci_data_exchange_complete (ndev,NULL , ntf->conn_id, -EIO ); + +return 0 ; } static const __u8 *
@@ -329,13 +357,18 @@ void nci_clear_target_list(struct nci_de ndev->n_targets =0 ; } -static void nci_rf_discover_ntf_packet (struct nci_dev *ndev, -const struct sk_buff *skb) +static int nci_rf_discover_ntf_packet (struct nci_dev *ndev, +const struct sk_buff *skb) {struct nci_rf_discover_ntf ntf; -const __u8 *data = skb->data; +const __u8 *data;bool add_target = true; +if (skb->len <sizeof (struct nci_rf_discover_ntf )) +return -EINVAL ; + + data = skb->data; + ntf.rf_discovery_id = *data++; ntf.rf_protocol = *data++; ntf.rf_tech_and_mode = *data++;
@@ -390,6 +423,8 @@ static void nci_rf_discover_ntf_packet(snfc_targets_found (ndev->nfc_dev, ndev->targets, ndev->n_targets); } + +return 0 ; } static int nci_extract_activation_params_iso_dep(struct nci_dev *ndev,
@@ -531,14 +566,19 @@ static int nci_store_general_bytes_nfc_dreturn NCI_STATUS_OK ; } -static void nci_rf_intf_activated_ntf_packet (struct nci_dev *ndev, -const struct sk_buff *skb) +static int nci_rf_intf_activated_ntf_packet (struct nci_dev *ndev, +const struct sk_buff *skb) {struct nci_conn_info *conn_info;struct nci_rf_intf_activated_ntf ntf; -const __u8 *data = skb->data; +const __u8 *data;int err =NCI_STATUS_OK ; +if (skb->len <sizeof (struct nci_rf_intf_activated_ntf )) +return -EINVAL ; + + data = skb->data; + ntf.rf_discovery_id = *data++; ntf.rf_interface = *data++; ntf.rf_protocol = *data++;
@@ -645,7 +685,7 @@ exit:if (err ==NCI_STATUS_OK ) { conn_info = ndev->rf_conn_info;if (!conn_info) -return ; +return 0 ; conn_info->max_pkt_payload_len = ntf.max_data_pkt_payload_size; conn_info->initial_num_credits = ntf.initial_num_credits;
@@ -691,19 +731,26 @@ listen:pr_err ("error when signaling tm activation\n" ); } } + +return 0 ; } -static void nci_rf_deactivate_ntf_packet (struct nci_dev *ndev, -const struct sk_buff *skb) +static int nci_rf_deactivate_ntf_packet (struct nci_dev *ndev, +const struct sk_buff *skb) {const struct nci_conn_info *conn_info; -const struct nci_rf_deactivate_ntf *ntf = (void *)skb->data; +const struct nci_rf_deactivate_ntf *ntf; + +if (skb->len <sizeof (struct nci_rf_deactivate_ntf )) +return -EINVAL ; + + ntf = (struct nci_rf_deactivate_ntf *)skb->data;pr_debug ("entry, type 0x%x, reason 0x%x\n" , ntf->type, ntf->reason); conn_info = ndev->rf_conn_info;if (!conn_info) -return ; +return 0 ;/* drop tx data queue */ skb_queue_purge (&ndev->tx_q);
@@ -735,14 +782,20 @@ static void nci_rf_deactivate_ntf_packet }nci_req_complete (ndev,NCI_STATUS_OK ); + +return 0 ; } -static void nci_nfcee_discover_ntf_packet (struct nci_dev *ndev, -const struct sk_buff *skb) +static int nci_nfcee_discover_ntf_packet (struct nci_dev *ndev, +const struct sk_buff *skb) {u8 status =NCI_STATUS_OK ; -const struct nci_nfcee_discover_ntf *nfcee_ntf = - (struct nci_nfcee_discover_ntf *)skb->data; +const struct nci_nfcee_discover_ntf *nfcee_ntf; + +if (skb->len <sizeof (struct nci_nfcee_discover_ntf )) +return -EINVAL ; + + nfcee_ntf = (struct nci_nfcee_discover_ntf *)skb->data;/* NFCForum NCI 9.2.1 HCI Network Specific Handling * If the NFCC supports the HCI Network, it SHALL return one,
@@ -753,6 +806,8 @@ static void nci_nfcee_discover_ntf_packe ndev->cur_params.id = nfcee_ntf->nfcee_id;nci_req_complete (ndev, status); + +return 0 ; }void nci_ntf_packet (struct nci_dev *ndev,struct sk_buff *skb)
@@ -779,35 +834,43 @@ void nci_ntf_packet(struct nci_dev *ndevswitch (ntf_opcode) {case NCI_OP_CORE_RESET_NTF : -nci_core_reset_ntf_packet (ndev, skb); +if (nci_core_reset_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_CORE_CONN_CREDITS_NTF : -nci_core_conn_credits_ntf_packet (ndev, skb); +if (nci_core_conn_credits_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_CORE_GENERIC_ERROR_NTF : -nci_core_generic_error_ntf_packet (ndev, skb); +if (nci_core_generic_error_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_CORE_INTF_ERROR_NTF : -nci_core_conn_intf_error_ntf_packet (ndev, skb); +if (nci_core_conn_intf_error_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_RF_DISCOVER_NTF : -nci_rf_discover_ntf_packet (ndev, skb); +if (nci_rf_discover_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_RF_INTF_ACTIVATED_NTF : -nci_rf_intf_activated_ntf_packet (ndev, skb); +if (nci_rf_intf_activated_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_RF_DEACTIVATE_NTF : -nci_rf_deactivate_ntf_packet (ndev, skb); +if (nci_rf_deactivate_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_NFCEE_DISCOVER_NTF : -nci_nfcee_discover_ntf_packet (ndev, skb); +if (nci_nfcee_discover_ntf_packet (ndev, skb)) + goto end;break ;case NCI_OP_RF_NFCEE_ACTION_NTF :
Greg Kroah-Hartman
maintainerPATCH 177/196 mfd: vexpress-sysreg: Check the return value of devm_gpiochip_add_data()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
commit 1efbee6852f1ff698a9981bd731308dd027189fb upstream.
Commit 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells") removed the return value check from the call to gpiochip_add_data() (or rather gpiochip_add() back then and later converted to devres) with no explanation. This function however can still fail, so check the return value and bail-out if it does.
--- drivers/mfd/vexpress-sysreg.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/mfd/vexpress-sysreg.c +5 -1
@@ -98,6 +98,7 @@ static int vexpress_sysreg_probe(structstruct resource *mem;void __iomem *base;struct gpio_chip *mmc_gpio_chip; +int ret; mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 );if (!mem)
@@ -118,7 +119,10 @@ static int vexpress_sysreg_probe(structbgpio_init (mmc_gpio_chip, &pdev->dev,0x4 , base +SYS_MCI ,NULL ,NULL ,NULL ,NULL ,0 ); mmc_gpio_chip->ngpio =2 ; -devm_gpiochip_add_data (&pdev->dev, mmc_gpio_chip,NULL ); + + ret =devm_gpiochip_add_data (&pdev->dev, mmc_gpio_chip,NULL ); +if (ret) +return ret; return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, vexpress_sysreg_cells,
Greg Kroah-Hartman
maintainerPATCH 178/196 dm: fix queue start/stop imbalance under suspend/load/resume races
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheng Qixing <[email protected]>
commit 7f597c2cdb9d3263a6fce07c4fc0a9eaa8e8fc43 upstream.
When suspend and load run concurrently, before q->mq_ops is set in blk_mq_init_allocated_queue(), __dm_suspend() skip dm_stop_queue(). As a result, the queue's quiesce depth is not incremented.
Later, once table load has finished and __dm_resume() runs, which triggers q->quiesce_depth ==0 warning in blk_mq_unquiesce_queue():
Call Trace: <TASK> dm_start_queue+0x16/0x20 [dm_mod] __dm_resume+0xac/0xb0 [dm_mod] dm_resume+0x12d/0x150 [dm_mod] do_resume+0x2c2/0x420 [dm_mod] dev_suspend+0x30/0x130 [dm_mod] ctl_ioctl+0x402/0x570 [dm_mod] dm_ctl_ioctl+0x23/0x30 [dm_mod]
Fix this by explicitly tracking whether the request queue was stopped in __dm_suspend() via a new DMF_QUEUE_STOPPED flag. Only call dm_start_queue() in __dm_resume() if the queue was actually stopped.
--- drivers/md/dm-core.h | 1 + drivers/md/dm.c | 8 +++++--- 2 files changed, 6 insertions(+), 3 deletions(-)
drivers/md/dm-core.h +1 -0
@@ -160,6 +160,7 @@ struct mapped_device {#define DMF_SUSPENDED_INTERNALLY 7#define DMF_POST_SUSPENDING 8#define DMF_EMULATE_ZONE_APPEND 9 +#define DMF_QUEUE_STOPPED 10void disable_discard (struct mapped_device *md);void disable_write_zeroes (struct mapped_device *md);
drivers/md/dm.c +5 -3
@@ -2720,8 +2720,10 @@ static int __dm_suspend(struct mapped_de* Stop md->queue before flushing md->wq in case request-based * dm defers requests to md->wq from md->queue. */ -if (dm_request_based (md)) +if (dm_request_based (md)) {dm_stop_queue (md->queue); +set_bit (DMF_QUEUE_STOPPED , &md->flags); + }flush_workqueue (md->wq);
@@ -2743,7 +2745,7 @@ static int __dm_suspend(struct mapped_deif (r <0 ) {dm_queue_flush (md); -if (dm_request_based (md)) +if (test_and_clear_bit (DMF_QUEUE_STOPPED , &md->flags))dm_start_queue (md->queue);unlock_fs (md);
@@ -2826,7 +2828,7 @@ static int __dm_resume(struct mapped_dev* so that mapping of targets can work correctly. * Request-based dm is queueing the deferred I/Os in its request_queue. */ -if (dm_request_based (md)) +if (test_and_clear_bit (DMF_QUEUE_STOPPED , &md->flags))dm_start_queue (md->queue);unlock_fs (md);
Greg Kroah-Hartman
maintainerPATCH 179/196 dm: fix NULL pointer dereference in __dm_suspend()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheng Qixing <[email protected]>
commit 8d33a030c566e1f105cd5bf27f37940b6367f3be upstream.
There is a race condition between dm device suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes:
BUG: kernel NULL pointer dereference, address: 0000000000000054 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50 Call Trace: <TASK> blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0
The issue can be triggered as below:
T1 T2dm_suspend table_load__dm_suspend dm_setup_md_queue
dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1) dm_stop_queue / dm_wait_for_completion => q->tag_set NULL pointer! (2) => q->tag_set = set; (3)
Fix this by checking if a valid table (map) exists before performing request-based suspend and waiting for target I/O. When map is NULL, skip these table-dependent suspend steps.
Even when map is NULL, no I/O can reach any target because there is no table loaded; I/O submitted in this state will fail early in the DM layer. Skipping the table-dependent suspend logic in this case is safe and avoids NULL pointer dereferences.
--- drivers/md/dm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/md/dm.c +4 -3
@@ -2668,7 +2668,7 @@ static int __dm_suspend(struct mapped_de {bool do_lockfs = suspend_flags &DM_SUSPEND_LOCKFS_FLAG ;bool noflush = suspend_flags &DM_SUSPEND_NOFLUSH_FLAG ; -int r; +int r =0 ;lockdep_assert_held (&md->suspend_lock);
@@ -2720,7 +2720,7 @@ static int __dm_suspend(struct mapped_de* Stop md->queue before flushing md->wq in case request-based * dm defers requests to md->wq from md->queue. */ -if (dm_request_based (md)) { +if (map &&dm_request_based (md)) {dm_stop_queue (md->queue);set_bit (DMF_QUEUE_STOPPED , &md->flags); }
@@ -2732,7 +2732,8 @@ static int __dm_suspend(struct mapped_de* We call dm_wait_for_completion to wait for all existing requests * to finish. */ - r =dm_wait_for_completion (md, task_state); +if (map) + r =dm_wait_for_completion (md, task_state);if (!r)set_bit (dmf_suspended_flag, &md->flags);
Greg Kroah-Hartman
maintainerPATCH 180/196 ksmbd: fix error code overwriting in smb2_get_info_filesystem()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matvey Kovalev <[email protected]>
commit 88daf2f448aad05a2e6df738d66fe8b0cf85cee0 upstream.
If client doesn't negotiate with SMB3.1.1 POSIX Extensions, then proper error code won't be returned due to overwriting.
Return error immediately.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- fs/smb/server/smb2pdu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/smb/server/smb2pdu.c +2 -1
@@ -5233,7 +5233,8 @@ static int smb2_get_info_filesystem(struif (!work->tcon->posix_extensions) {pr_err ("client doesn't negotiate with SMB3.1.1 POSIX Extensions\n" ); - rc = -EOPNOTSUPP ; +path_put (&path); +return -EOPNOTSUPP ; }else { info = (struct filesystem_posix_info *)(rsp->Buffer); info->OptimalTransferSize =cpu_to_le32 (stfs.f_bsize);
Greg Kroah-Hartman
maintainerPATCH 181/196 ext4: fix checks for orphan inodes
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit acf943e9768ec9d9be80982ca0ebc4bfd6b7631e upstream.
When orphan file feature is enabled, inode can be tracked as orphan either in the standard orphan list or in the orphan file. The first can be tested by checking ei->i_orphan list head, the second is recorded by EXT4_STATE_ORPHAN_FILE inode state flag. There are several places where we want to check whether inode is tracked as orphan and only some of them properly check for both possibilities. Luckily the consequences are mostly minor, the worst that can happen is that we track an inode as orphan although we don't need to and e2fsck then complains (resulting in occasional ext4/307 xfstest failures). Fix the problem by introducing a helper for checking whether an inode is tracked as orphan and use it in appropriate places.
Message-ID: <[email protected]>
--- fs/ext4/ext4.h | 10 ++++++++++ fs/ext4/file.c | 2 +- fs/ext4/inode.c | 2 +- fs/ext4/orphan.c | 6 +----- fs/ext4/super.c | 4 ++-- 5 files changed, 15 insertions(+), 9 deletions(-)
fs/ext4/ext4.h +10 -0
@@ -1962,6 +1962,16 @@ static inline bool ext4_verity_in_progre#define NEXT_ORPHAN (inode) EXT4_I(inode)->i_dtime/* +* Check whether the inode is tracked as orphan (either in orphan file or +* orphan list). +*/ +static inline bool ext4_inode_orphan_tracked (struct inode *inode) +{ +return ext4_test_inode_state (inode,EXT4_STATE_ORPHAN_FILE ) || + !list_empty (&EXT4_I (inode)->i_orphan); +} + +/* * Codes for operating systems */ #define EXT4_OS_LINUX 0
fs/ext4/file.c +1 -1
@@ -344,7 +344,7 @@ static void ext4_inode_extension_cleanup* to cleanup the orphan list in ext4_handle_inode_extension(). Do it * now. */ -if (!list_empty (&EXT4_I (inode)->i_orphan) && inode->i_nlink) { +if (ext4_inode_orphan_tracked (inode) && inode->i_nlink) {handle_t *handle =ext4_journal_start (inode,EXT4_HT_INODE ,2 );if (IS_ERR (handle)) {
fs/ext4/inode.c +1 -1
@@ -4394,7 +4394,7 @@ static int ext4_fill_raw_inode(struct in* old inodes get re-used with the upper 16 bits of the * uid/gid intact. */ -if (ei->i_dtime &&list_empty (&ei->i_orphan)) { +if (ei->i_dtime && !ext4_inode_orphan_tracked (inode)) { raw_inode->i_uid_high =0 ; raw_inode->i_gid_high =0 ; }else {
fs/ext4/orphan.c +1 -5
@@ -109,11 +109,7 @@ int ext4_orphan_add(handle_t *handle, stWARN_ON_ONCE (!(inode->i_state & (I_NEW |I_FREEING )) && !inode_is_locked (inode)); -/* -* Inode orphaned in orphan file or in orphan list? -*/ -if (ext4_test_inode_state (inode,EXT4_STATE_ORPHAN_FILE ) || - !list_empty (&EXT4_I (inode)->i_orphan)) +if (ext4_inode_orphan_tracked (inode))return 0 ;/*
fs/ext4/super.c +2 -2
@@ -1379,9 +1379,9 @@ static void ext4_free_in_core_inode(strustatic void ext4_destroy_inode (struct inode *inode) { -if (!list_empty (&(EXT4_I (inode)->i_orphan))) { +if (ext4_inode_orphan_tracked (inode)) {ext4_msg (inode->i_sb,KERN_ERR , -"Inode %lu (%p): orphan list check failed!" , +"Inode %lu (%p): inode tracked as orphan!" , inode->i_ino,EXT4_I (inode)); print_hex_dump(KERN_INFO, "", DUMP_PREFIX_ADDRESS, 16, 4, EXT4_I(inode), sizeof(struct ext4_inode_info),
Greg Kroah-Hartman
maintainerPATCH 182/196 mm: hugetlb: avoid soft lockup when mprotect to large memory area
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Shi <[email protected]>
commit f52ce0ea90c83a28904c7cc203a70e6434adfecb upstream.
When calling mprotect() to a large hugetlb memory area in our customer's workload (~300GB hugetlb memory), soft lockup was observed:
watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916] CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7 Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mte_clear_page_tags+0x14/0x24
lr : mte_sync_tags+0x1c0/0x240
sp : ffff80003150bb80
x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000
x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458
x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000
x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000 x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000
Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8
Soft lockup is not triggered with THP or base page because there is cond_resched() called for each PMD size.
Although the soft lockup was triggered by MTE, it should be not MTE specific. The other processing which takes long time in the loop may trigger soft lockup too.
So add cond_resched() for hugetlb to avoid soft lockup.
--- mm/hugetlb.c | 2 ++ 1 file changed, 2 insertions(+)
mm/hugetlb.c +2 -0
@@ -6779,6 +6779,8 @@ unsigned long hugetlb_change_protection( make_pte_marker(PTE_MARKER_UFFD_WP)); }spin_unlock (ptl); + +cond_resched (); }/* * Must flush TLB before releasing i_mmap_rwsem: x86's huge_pmd_unshare
Greg Kroah-Hartman
maintainerPATCH 183/196 nvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
commit a9e6aa994917ee602798bbb03180a194b37865bb upstream.
devm_kcalloc() may fail. ndtest_probe() allocates three DMA address arrays (dcr_dma, label_dma, dimm_dma) and later unconditionally uses them in ndtest_nvdimm_init(), which can lead to a NULL pointer dereference under low-memory conditions.
Check all three allocations and return -ENOMEM if any allocation fails, jumping to the common error path. Do not emit an extra error message since the allocator already warns on allocation failure.
--- tools/testing/nvdimm/test/ndtest.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
tools/testing/nvdimm/test/ndtest.c +12 -1
@@ -845,11 +845,22 @@ static int ndtest_probe(struct platform_ p->dcr_dma =devm_kcalloc (&p->pdev.dev,NUM_DCR ,sizeof (dma_addr_t),GFP_KERNEL ); +if (!p->dcr_dma) { + rc = -ENOMEM ; + goto err; + } p->label_dma =devm_kcalloc (&p->pdev.dev,NUM_DCR ,sizeof (dma_addr_t),GFP_KERNEL ); +if (!p->label_dma) { + rc = -ENOMEM ; + goto err; + } p->dimm_dma =devm_kcalloc (&p->pdev.dev,NUM_DCR ,sizeof (dma_addr_t),GFP_KERNEL ); - +if (!p->dimm_dma) { + rc = -ENOMEM ; + goto err; + } rc =ndtest_nvdimm_init (p);if (rc) goto err;
Greg Kroah-Hartman
maintainerPATCH 184/196 misc: fastrpc: Fix fastrpc_map_lookup operation
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ling Xu <[email protected]>
commit 9031626ade38b092b72638dfe0c6ffce8d8acd43 upstream.
Fastrpc driver creates maps for user allocated fd buffers. Before creating a new map, the map list is checked for any already existing maps using map fd. Checking with just map fd is not sufficient as the user can pass offsetted buffer with less size when the map is created and then a larger size the next time which could result in memory issues. Check for dma_buf object also when looking up for the map.
--- drivers/misc/fastrpc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/misc/fastrpc.c +6 -1
@@ -346,11 +346,16 @@ static int fastrpc_map_lookup(struct fas {struct fastrpc_session_ctx *sess = fl->sctx;struct fastrpc_map *map =NULL ; +struct dma_buf *buf;int ret = -ENOENT ; + buf =dma_buf_get (fd); +if (IS_ERR (buf)) +return PTR_ERR (buf); +spin_lock (&fl->lock);list_for_each_entry (map, &fl->maps, node) { -if (map->fd != fd) +if (map->fd != fd || map->buf != buf)continue ;if (take_ref) {
Greg Kroah-Hartman
maintainerPATCH 185/196 misc: fastrpc: fix possible map leak in fastrpc_put_args
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ling Xu <[email protected]>
commit da1ba64176e0138f2bfa96f9e43e8c3640d01e1e upstream.
copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning.
--- drivers/misc/fastrpc.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/misc/fastrpc.c +7 -3
@@ -1018,6 +1018,7 @@ static int fastrpc_put_args(struct fastrstruct fastrpc_phy_page *pages;u64 *fdlist;int i, inbufs, outbufs, handles; +int ret =0 ; inbufs =REMOTE_SCALARS_INBUFS (ctx->sc); outbufs =REMOTE_SCALARS_OUTBUFS (ctx->sc);
@@ -1033,14 +1034,17 @@ static int fastrpc_put_args(struct fastru64 len = rpra[i].buf.len;if (!kernel) { -if (copy_to_user ((void __user *)dst, src, len)) -return -EFAULT ; +if (copy_to_user ((void __user *)dst, src, len)) { + ret = -EFAULT ; + goto cleanup_fdlist; + } }else {memcpy (dst, src, len); } } } +cleanup_fdlist:/* Clean up fdlist which is updated by DSP */ for (i =0 ; i <FASTRPC_MAX_FDLIST ; i++) {if (!fdlist[i])
@@ -1049,7 +1053,7 @@ static int fastrpc_put_args(struct fastrfastrpc_map_put (mmap); } -return 0 ; +return ret; } static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx,
Greg Kroah-Hartman
maintainerPATCH 186/196 misc: fastrpc: Skip reference for DMA handles
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ling Xu <[email protected]>
commit 10df039834f84a297c72ec962c0f9b7c8c5ca31a upstream.
If multiple dma handles are passed with same fd over a remote call the kernel driver takes a reference and expects that put for the map will be called as many times to free the map. But DSP only updates the fd one time in the fd list when the DSP refcount goes to zero and hence kernel make put call only once for the fd. This can cause SMMU fault issue as the same fd can be used in future for some other call.
--- drivers/misc/fastrpc.c | 45 +++++++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 18 deletions(-)
drivers/misc/fastrpc.c +27 -18
@@ -342,9 +342,8 @@ static int fastrpc_map_get(struct fastrpstatic int fastrpc_map_lookup (struct fastrpc_user *fl,int fd, -struct fastrpc_map **ppmap,bool take_ref) +struct fastrpc_map **ppmap) { -struct fastrpc_session_ctx *sess = fl->sctx;struct fastrpc_map *map =NULL ;struct dma_buf *buf;int ret = -ENOENT ;
@@ -358,15 +357,6 @@ static int fastrpc_map_lookup(struct fasif (map->fd != fd || map->buf != buf)continue ; -if (take_ref) { - ret =fastrpc_map_get (map); -if (ret) { -dev_dbg (sess->dev,"%s: Failed to get map fd=%d ret=%d\n" , - __func__, fd, ret); -break ; - } - } - *ppmap = map; ret =0 ;break ;
@@ -711,7 +701,7 @@ static const struct dma_buf_ops fastrpc_ .release = fastrpc_release, }; -static int fastrpc_map_create (struct fastrpc_user *fl,int fd, +static int fastrpc_map_attach (struct fastrpc_user *fl,int fd,u64 len,u32 attr,struct fastrpc_map **ppmap) {struct fastrpc_session_ctx *sess = fl->sctx;
@@ -719,9 +709,6 @@ static int fastrpc_map_create(struct fasstruct sg_table *table;int err =0 ; -if (!fastrpc_map_lookup (fl, fd, ppmap, true)) -return 0 ; - map =kzalloc (sizeof (*map),GFP_KERNEL );if (!map)return -ENOMEM ;
@@ -789,6 +776,24 @@ get_err:return err; } +static int fastrpc_map_create (struct fastrpc_user *fl,int fd, +u64 len,u32 attr,struct fastrpc_map **ppmap) +{ +struct fastrpc_session_ctx *sess = fl->sctx; +int err =0 ; + +if (!fastrpc_map_lookup (fl, fd, ppmap)) { +if (!fastrpc_map_get (*ppmap)) +return 0 ; +dev_dbg (sess->dev,"%s: Failed to get map fd=%d\n" , + __func__, fd); + } + + err =fastrpc_map_attach (fl, fd, len, attr, ppmap); + +return err; +} +/* * Fastrpc payload buffer with metadata looks like: *
@@ -861,8 +866,12 @@ static int fastrpc_create_maps(struct fa ctx->args[i].length == 0)continue ; - err =fastrpc_map_create (ctx->fl, ctx->args[i].fd, - ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]); +if (i < ctx->nbufs) + err =fastrpc_map_create (ctx->fl, ctx->args[i].fd, + ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]); +else + err =fastrpc_map_attach (ctx->fl, ctx->args[i].fd, + ctx->args[i].length, ctx->args[i].attr, &ctx->maps[i]);if (err) {dev_err (dev,"Error Creating map %d\n" , err);return -EINVAL ;
@@ -1049,7 +1058,7 @@ cleanup_fdlist:for (i =0 ; i <FASTRPC_MAX_FDLIST ; i++) {if (!fdlist[i])break ; -if (!fastrpc_map_lookup (fl, (int )fdlist[i], &mmap, false)) +if (!fastrpc_map_lookup (fl, (int )fdlist[i], &mmap))fastrpc_map_put (mmap); }
Greg Kroah-Hartman
maintainerPATCH 187/196 Input: atmel_mxt_ts - allow reset GPIO to sleep
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Vasut <[email protected]>
commit c7866ee0a9ddd9789faadf58cdac6abd7aabf045 upstream.
The reset GPIO is not toggled in any critical section where it couldn't sleep, allow the reset GPIO to sleep. This allows the driver to operate reset GPIOs connected to I2C GPIO expanders.
--- drivers/input/touchscreen/atmel_mxt_ts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/input/touchscreen/atmel_mxt_ts.c +1 -1
@@ -3239,7 +3239,7 @@ static int mxt_probe(struct i2c_client *if (data->reset_gpio) {/* Wait a while and then de-assert the RESET GPIO line */ msleep (MXT_RESET_GPIO_TIME ); -gpiod_set_value (data->reset_gpio,0 ); +gpiod_set_value_cansleep (data->reset_gpio,0 );msleep (MXT_RESET_INVALID_CHG ); }
Greg Kroah-Hartman
maintainerPATCH 188/196 Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhen Ni <[email protected]>
commit d3366a04770eea807f2826cbdb96934dd8c9bf79 upstream.
Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace.
Initialize ff_up_compat to zero before filling valid fields.
--- drivers/input/misc/uinput.c | 1 + 1 file changed, 1 insertion(+)
drivers/input/misc/uinput.c +1 -0
@@ -741,6 +741,7 @@ static int uinput_ff_upload_to_user(charif (in_compat_syscall ()) {struct uinput_ff_upload_compat ff_up_compat; +memset (&ff_up_compat,0 ,sizeof (ff_up_compat)); ff_up_compat.request_id = ff_up->request_id; ff_up_compat.retval = ff_up->retval;/*
Greg Kroah-Hartman
maintainerPATCH 189/196 pinctrl: check the return value of pinmux_ops::get_function_name()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
commit 4002ee98c022d671ecc1e4a84029e9ae7d8a5603 upstream.
While the API contract in docs doesn't specify it explicitly, the generic implementation of the get_function_name() callback from struct pinmux_ops - pinmux_generic_get_function_name() - can fail and return NULL. This is already checked in pinmux_check_ops() so add a similar check in pinmux_func_name_to_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions.
--- drivers/pinctrl/pinmux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/pinmux.c +1 -1
@@ -328,7 +328,7 @@ static int pinmux_func_name_to_selector(while (selector < nfuncs) {const char *fname = ops->get_function_name (pctldev, selector); -if (!strcmp (function, fname)) +if (fname && !strcmp (function, fname))return selector; selector++;
Greg Kroah-Hartman
maintainerPATCH 190/196 bus: fsl-mc: Check return value of platform_get_resource()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Salah Triki <[email protected]>
commit 25f526507b8ccc6ac3a43bc094d09b1f9b0b90ae upstream.
platform_get_resource() returns NULL in case of failure, so check its return value and propagate the error in order to prevent NULL pointer dereference.
--- drivers/bus/fsl-mc/fsl-mc-bus.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/bus/fsl-mc/fsl-mc-bus.c +3 -0
@@ -1172,6 +1172,9 @@ static int fsl_mc_bus_probe(struct platf* Get physical address of MC portal for the root DPRC: */ plat_res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); +if (!plat_res) +return -EINVAL ; + mc_portal_phys_addr = plat_res->start; mc_portal_size =resource_size (plat_res); mc_portal_base_phys_addr = mc_portal_phys_addr & ~0x3ffffff ;
Greg Kroah-Hartman
maintainerPATCH 191/196 net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleksij Rempel <[email protected]>
commit 3d3c4cd5c62f24bb3cb4511b7a95df707635e00a upstream.
Prevent USB runtime PM (autosuspend) for AX88772* in bind.
usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend.
The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues.
To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides.
Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before.
--- drivers/net/usb/asix_devices.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
drivers/net/usb/asix_devices.c +29 -0
@@ -625,6 +625,21 @@ static void ax88772_suspend(struct usbne asix_read_medium_status(dev, 1)); } +/* Notes on PM callbacks and locking context: +* +* - asix_suspend()/asix_resume() are invoked for both runtime PM and +* system-wide suspend/resume. For struct usb_driver the ->resume() +* callback does not receive pm_message_t, so the resume type cannot +* be distinguished here. +* +* - The MAC driver must hold RTNL when calling phylink interfaces such as +* phylink_suspend()/resume(). Those calls will also perform MDIO I/O. +* +* - Taking RTNL and doing MDIO from a runtime-PM resume callback (while +* the USB PM lock is held) is fragile. Since autosuspend brings no +* measurable power saving here, we block it by holding a PM usage +* reference in ax88772_bind(). +*/ static int asix_suspend (struct usb_interface *intf,pm_message_t message) {struct usbnet *dev =usb_get_intfdata (intf);
@@ -922,6 +937,13 @@ static int ax88772_bind(struct usbnet *dif (ret) goto initphy_err; +/* Keep this interface runtime-PM active by taking a usage ref. +* Prevents runtime suspend while bound and avoids resume paths +* that could deadlock (autoresume under RTNL while USB PM lock +* is held, phylink/MDIO wants RTNL). +*/ +pm_runtime_get_noresume (&intf->dev); +return 0 ; initphy_err:
@@ -951,6 +973,8 @@ static void ax88772_unbind(struct usbnetphylink_destroy (priv->phylink);ax88772_mdio_unregister (priv);asix_rx_fixup_common_free (dev->driver_priv); +/* Drop the PM usage ref taken in bind() */ +pm_runtime_put (&intf->dev); }static void ax88178_unbind (struct usbnet *dev,struct usb_interface *intf)
@@ -1575,6 +1599,11 @@ static struct usb_driver asix_driver = { .resume = asix_resume, .reset_resume = asix_resume, .disconnect = usbnet_disconnect, +/* usbnet enables autosuspend by default (supports_autosuspend=1). +* We keep runtime-PM active for AX88772* by taking a PM usage +* reference in ax88772_bind() (pm_runtime_get_noresume()) and +* dropping it in unbind(), which effectively blocks autosuspend. +*/ .supports_autosuspend = 1, .disable_hub_initiated_lpm = 1, };
Greg Kroah-Hartman
maintainerPATCH 192/196 usb: typec: tipd: Clear interrupts first
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sven Peter <[email protected]>
commit be5ae730ffa6fd774a00a4705c1e11e078b08ca1 upstream.
Right now the interrupt handler first reads all updated status registers and only then clears the interrupts. It's possible that a duplicate interrupt for a changed register or plug state comes in after the interrupts have been processed but before they have been cleared:
* plug is inserted, TPS_REG_INT_PLUG_EVENT is set
* TPS_REG_INT_EVENT1 is read
* tps6598x_handle_plug_event() has run and registered the plug
* plug is removed again, TPS_REG_INT_PLUG_EVENT is set (again)
* TPS_REG_INT_CLEAR1 is written, TPS_REG_INT_PLUG_EVENT is cleared
We then have no plug connected and no pending interrupt but the tipd core still thinks there is a plug. It's possible to trigger this with e.g. a slightly broken Type-C to USB A converter.
Fix this by first clearing the interrupts and only then reading the updated registers.
--- drivers/usb/typec/tipd/core.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-)
drivers/usb/typec/tipd/core.c +11 -13
@@ -491,24 +491,23 @@ static irqreturn_t cd321x_interrupt(intif (!event) goto err_unlock; +tps6598x_write64 (tps,TPS_REG_INT_CLEAR1 , event); +if (!tps6598x_read_status (tps, &status)) - goto err_clear_ints; + goto err_unlock;if (event &APPLE_CD_REG_INT_POWER_STATUS_UPDATE )if (!tps6598x_read_power_status (tps)) - goto err_clear_ints; + goto err_unlock;if (event &APPLE_CD_REG_INT_DATA_STATUS_UPDATE )if (!tps6598x_read_data_status (tps)) - goto err_clear_ints; + goto err_unlock;/* Handle plug insert or removal */ if (event &APPLE_CD_REG_INT_PLUG_EVENT )tps6598x_handle_plug_event (tps, status); -err_clear_ints: -tps6598x_write64 (tps,TPS_REG_INT_CLEAR1 , event); - err_unlock:mutex_unlock (&tps->lock);
@@ -555,25 +554,24 @@ static irqreturn_t tps6598x_interrupt(inif (!(event1[0 ] | event1[1 ] | event2[0 ] | event2[1 ])) goto err_unlock; +tps6598x_block_write (tps,TPS_REG_INT_CLEAR1 , event1, intev_len); +tps6598x_block_write (tps,TPS_REG_INT_CLEAR2 , event2, intev_len); +if (!tps6598x_read_status (tps, &status)) - goto err_clear_ints; + goto err_unlock;if ((event1[0 ] | event2[0 ]) &TPS_REG_INT_POWER_STATUS_UPDATE )if (!tps6598x_read_power_status (tps)) - goto err_clear_ints; + goto err_unlock;if ((event1[0 ] | event2[0 ]) &TPS_REG_INT_DATA_STATUS_UPDATE )if (!tps6598x_read_data_status (tps)) - goto err_clear_ints; + goto err_unlock;/* Handle plug insert or removal */ if ((event1[0 ] | event2[0 ]) &TPS_REG_INT_PLUG_EVENT )tps6598x_handle_plug_event (tps, status); -err_clear_ints: -tps6598x_block_write (tps,TPS_REG_INT_CLEAR1 , event1, intev_len); -tps6598x_block_write (tps,TPS_REG_INT_CLEAR2 , event2, intev_len); - err_unlock:mutex_unlock (&tps->lock);
Greg Kroah-Hartman
maintainerPATCH 193/196 usb: cdns3: cdnsp-pci: remove redundant pci_disable_device() call
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaoqian Lin <[email protected]>
commit e9c206324eeb213957a567a9d066bdeb355c7491 upstream.
The cdnsp-pci driver uses pcim_enable_device() to enable a PCI device, which means the device will be automatically disabled on driver detach through the managed device framework. The manual pci_disable_device() call in the error path is therefore redundant.
Found via static anlaysis and this is similar to commit 99ca0b57e49f ("thermal: intel: int340x: processor: Fix warning during module unload").
--- drivers/usb/cdns3/cdnsp-pci.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/usb/cdns3/cdnsp-pci.c +1 -4
@@ -90,7 +90,7 @@ static int cdnsp_pci_probe(struct pci_de cdnsp =kzalloc (sizeof (*cdnsp),GFP_KERNEL );if (!cdnsp) { ret = -ENOMEM ; - goto disable_pci; + goto put_pci; } }
@@ -173,9 +173,6 @@ free_cdnsp:if (!pci_is_enabled (func))kfree (cdnsp); -disable_pci: -pci_disable_device (pdev); - put_pci:pci_dev_put (func);
Greg Kroah-Hartman
maintainerPATCH 194/196 cacheinfo: Initialize variables in fetch_cache_info()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pierre Gondois <[email protected]>
commit ecaef469920fd6d2c7687f19081946f47684a423 upstream.
Set potentially uninitialized variables to 0. This is particularly relevant when CONFIG_ACPI_PPTT is not set.
--- drivers/base/cacheinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/cacheinfo.c +1 -1
@@ -440,7 +440,7 @@ int allocate_cache_info(int cpu)int fetch_cache_info (unsigned int cpu) {struct cpu_cacheinfo *this_cpu_ci; -unsigned int levels, split_levels; +unsigned int levels =0 , split_levels =0 ;int ret;if (acpi_disabled) {
Greg Kroah-Hartman
maintainerPATCH 195/196 cacheinfo: Fix LLC is not exported through sysfs
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yicong Yang <[email protected]>
commit 5c2712387d4850e0b64121d5fd3e6c4e84ea3266 upstream.
After entering 6.3-rc1 the LLC cacheinfo is not exported on our ACPI based arm64 server. This is because the LLC cacheinfo is partly reset when secondary CPUs boot up. On arm64 the primary cpu will allocate and setup cacheinfo:init_cpu_topology()
for_each_possible_cpu()
fetch_cache_info() // Allocate cacheinfo and init levelsdetect_cache_attributes()
cache_shared_cpu_map_setup()
if (!last_level_cache_is_valid()) // not valid, setup LLC
cache_setup_properties() // setup LLC
On secondary CPU boot up:detect_cache_attributes()
populate_cache_leaves()
get_cache_type() // Get cache type from clidr_el1,
// for LLC type=CACHE_TYPE_NOCACHE
cache_shared_cpu_map_setup()
if (!last_level_cache_is_valid()) // Valid and won't go to this branch,
// leave LLC's type=CACHE_TYPE_NOCACHE
The last_level_cache_is_valid() use cacheinfo->{attributes, fw_token} to test it's valid or not, but populate_cache_leaves() will only reset LLC's type, so we won't try to re-setup LLC's type and leave it CACHE_TYPE_NOCACHE and won't export it through sysfs.
This patch tries to fix this by not re-populating the cache leaves if the LLC is valid.
--- drivers/base/cacheinfo.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
drivers/base/cacheinfo.c +11 -5
@@ -490,12 +490,18 @@ int detect_cache_attributes(unsigned int populate_leaves:/* -* populate_cache_leaves() may completely setup the cache leaves and -* shared_cpu_map or it may leave it partially setup. +* If LLC is valid the cache leaves were already populated so just go to +* update the cpu map. */ - ret =populate_cache_leaves (cpu); -if (ret) - goto free_ci; +if (!last_level_cache_is_valid (cpu)) { +/* +* populate_cache_leaves() may completely setup the cache leaves and +* shared_cpu_map or it may leave it partially setup. +*/ + ret =populate_cache_leaves (cpu); +if (ret) + goto free_ci; + }/* * For systems using DT for cache hierarchy, fw_token
Greg Kroah-Hartman
maintainerPATCH 196/196 drivers: base: cacheinfo: Update cpu_map_populated during CPU Hotplug
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: K Prateek Nayak <[email protected]>
commit c26fabe73330d983c7ce822c6b6ec0879b4da61f upstream.
Until commit 5c2712387d48 ("cacheinfo: Fix LLC is not exported through sysfs"), cacheinfo called populate_cache_leaves() for CPU coming online which let the arch specific functions handle (at least on x86) populating the shared_cpu_map. However, with the changes in the aforementioned commit, populate_cache_leaves() is not called when a CPU comes online as a result of hotplug since last_level_cache_is_valid() returns true as the cacheinfo data is not discarded. The CPU coming online is not present in shared_cpu_map, however, it will not be added since the cpu_cacheinfo->cpu_map_populated flag is set (it is set in populate_cache_leaves() when cacheinfo is first populated for x86)
This can lead to inconsistencies in the shared_cpu_map when an offlined CPU comes online again. Example below depicts the inconsistency in the shared_cpu_list in cacheinfo when CPU8 is offlined and onlined again on a 3rd Generation EPYC processor:
# for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do echo -n "$i: "; cat $i; done
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8-15,136-143# echo 0 > /sys/devices/system/cpu/cpu8/online # echo 1 > /sys/devices/system/cpu/cpu8/online
# for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do echo -n "$i: "; cat $i; done
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8 # cat /sys/devices/system/cpu/cpu136/cache/index0/shared_cpu_list
136 # cat /sys/devices/system/cpu/cpu136/cache/index3/shared_cpu_list
9-15,136-143Clear the flag when the CPU is removed from shared_cpu_map when cache_shared_cpu_map_remove() is called during CPU hotplug. This will allow cache_shared_cpu_map_setup() to add the CPU coming back online in the shared_cpu_map. Set the flag again when the shared_cpu_map is setup. Following are results of performing the same test as described above with the changes:
# for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do echo -n "$i: "; cat $i; done
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8-15,136-143# echo 0 > /sys/devices/system/cpu/cpu8/online # echo 1 > /sys/devices/system/cpu/cpu8/online
# for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do echo -n "$i: "; cat $i; done
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8,136
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8-15,136-143 # cat /sys/devices/system/cpu/cpu136/cache/index0/shared_cpu_list
8,136 # cat /sys/devices/system/cpu/cpu136/cache/index3/shared_cpu_list
8-15,136-143--- drivers/base/cacheinfo.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/base/cacheinfo.c +6 -0
@@ -365,11 +365,14 @@ static int cache_shared_cpu_map_setup(un coherency_max_size = this_leaf->coherency_line_size; } +/* shared_cpu_map is now populated for the cpu */ + this_cpu_ci->cpu_map_populated = true;return 0 ; }static void cache_shared_cpu_map_remove (unsigned int cpu) { +struct cpu_cacheinfo *this_cpu_ci =get_cpu_cacheinfo (cpu);struct cacheinfo *this_leaf, *sib_leaf;unsigned int sibling, index, sib_index;
@@ -404,6 +407,9 @@ static void cache_shared_cpu_map_remove(if (of_have_populated_dt ())of_node_put (this_leaf->fw_token); } + +/* cpu is no longer populated in the shared map */ + this_cpu_ci->cpu_map_populated = false; }static void free_cache_attributes (unsigned int cpu)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.156-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
# Librecast Test Results
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.1.156-rc1-00197-gb9f52894e35f #109 SMP PREEMPT_DYNAMIC Mon Oct 13 17:03:04 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Am 13.10.2025 um 16:42 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.156 release. There are 196 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]
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.156 release. There are 196 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.1.y
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.156-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.1:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
119 tests: 118 pass, 1 failLinux version: 6.1.156-rc1-gb9f52894e35f
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, 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.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.156-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.1:
10 builds: 10 pass, 0 fail 28 boots: 28 pass, 0 fail 119 tests: 118 pass, 1 fail
Quoted 8 lines
Linux version: 6.1.156-rc1-gb9f52894e35f
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra186-p3509-0000+p3636-0001, 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
A new kernel warning is observed for this update which is ...
ERR KERN Early cacheinfo failed, ret = -22
Bisect is pointing to this commit ...
# first bad commit: [988121168f4a3211c7f5e561c24bb0bbe8504565] arch_topology: Build cacheinfo from primary CPU
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 39 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.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.156-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Failures detected for Tegra ...
Test results for stable-v6.1:
10 builds: 10 pass, 0 fail 28 boots: 28 pass, 0 fail 119 tests: 118 pass, 1 failQuoted 8 lines
Linux version: 6.1.156-rc1-gb9f52894e35f
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra186-p3509-0000+p3636-0001, 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
Quoted 8 lines
A new kernel warning is observed for this update which is ...
ERR KERN Early cacheinfo failed, ret = -22
Bisect is pointing to this commit ...
# first bad commit: [988121168f4a3211c7f5e561c24bb0bbe8504565] arch_topology: Build cacheinfo from primary CPU
Thanks for the info, I'll go drop this whole series from the tree now, and report this to the submitter and cc: you on it.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.156-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.156-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.1.156-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: b9f52894e35f79b1ab1c988d4202ddf668e35032
* git describe: v6.1.155-197-gb9f52894e35f
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.155-197-gb9f52894e35f
## Test Regressions (compared to v6.1.154-74-g8a8cf3637b17)
## Metric Regressions (compared to v6.1.154-74-g8a8cf3637b17)
## Test Fixes (compared to v6.1.154-74-g8a8cf3637b17)
## Metric Fixes (compared to v6.1.154-74-g8a8cf3637b17)
## Test result summary
total: 99093, pass: 82935, fail: 2925, skip: 12977, xfail: 256
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 133 total, 132 passed, 1 failed
* arm64: 41 total, 38 passed, 3 failed
* i386: 21 total, 21 passed, 0 failed
* mips: 26 total, 25 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 32 total, 31 passed, 1 failed
* riscv: 11 total, 10 passed, 1 failed
* s390: 14 total, 13 passed, 1 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 7 total, 7 passed, 0 failed
* x86_64: 33 total, 32 passed, 1 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-exec
* kselftest-fpu
* kselftest-futex
* kselftest-intel_pstate
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-mincore
* kselftest-mqueue
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.156-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · On Mon, 13 Oct 2025 16:42:53 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.1.156 release. There are 196 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, 15 Oct 2025 14:42:41 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64:
Thanks!
Cheers,
Miguel
The kernel, bpf tool, perf tool, and kselftest builds fine for v6.1.156-rc1 on x86 and arm64 Azure VM.
Thanks,
Hardik