6.5.4-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 251/285 net: microchip: vcap api: Fix possible memory leak for vcap_dup_rule()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinjie Ruan <[email protected]>
[ Upstream commit 281f65d29d6da1a9b6907fb0b145aaf34f4e4822 ]
Inject fault When select CONFIG_VCAP_KUNIT_TEST, the below memory leak occurs. If kzalloc() for duprule succeeds, but the following kmemdup() fails, the duprule, ckf and caf memory will be leaked. So kfree them in the error path.
unreferenced object 0xffff122744c50600 (size 192):
comm "kunit_try_catch", pid 346, jiffies 4294896122 (age 911.812s) hex dump (first 32 bytes):
10 27 00 00 04 00 00 00 1e 00 00 00 2c 01 00 00 .'..........,...
00 00 00 00 00 00 00 00 18 06 c5 44 27 12 ff ff ...........D'...
backtrace:
[<00000000394b0db8>] __kmem_cache_alloc_node+0x274/0x2f8
[<0000000001bedc67>] kmalloc_trace+0x38/0x88
[<00000000b0612f98>] vcap_dup_rule+0x50/0x460
[<000000005d2d3aca>] vcap_add_rule+0x8cc/0x1038
[<00000000eef9d0f8>] test_vcap_xn_rule_creator.constprop.0.isra.0+0x238/0x494
[<00000000cbda607b>] vcap_api_rule_remove_in_front_test+0x1ac/0x698
[<00000000c8766299>] kunit_try_run_case+0xe0/0x20c
[<00000000c4fe9186>] kunit_generic_run_threadfn_adapter+0x50/0x94
[<00000000f6864acf>] kthread+0x2e8/0x374
[<0000000022e639b3>] ret_from_fork+0x10/0x20--- drivers/net/ethernet/microchip/vcap/vcap_api.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
drivers/net/ethernet/microchip/vcap/vcap_api.c +16 -2
@@ -1021,18 +1021,32 @@ static struct vcap_rule_internal *vcap_dup_rule(struct vcap_rule_internal *ri,list_for_each_entry (ckf, &ri->data.keyfields, ctrl.list) { newckf =kmemdup (ckf,sizeof (*newckf),GFP_KERNEL );if (!newckf) -return ERR_PTR (-ENOMEM ); + goto err;list_add_tail (&newckf->ctrl.list, &duprule->data.keyfields); }list_for_each_entry (caf, &ri->data.actionfields, ctrl.list) { newcaf =kmemdup (caf,sizeof (*newcaf),GFP_KERNEL );if (!newcaf) -return ERR_PTR (-ENOMEM ); + goto err;list_add_tail (&newcaf->ctrl.list, &duprule->data.actionfields); }return duprule; + +err: +list_for_each_entry_safe (ckf, newckf, &duprule->data.keyfields, ctrl.list) { +list_del (&ckf->ctrl.list); +kfree (ckf); + } + +list_for_each_entry_safe (caf, newcaf, &duprule->data.actionfields, ctrl.list) { +list_del (&caf->ctrl.list); +kfree (caf); + } + +kfree (duprule); +return ERR_PTR (-ENOMEM ); }static void vcap_apply_width (u8 *dst,int width,int bytes)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 252/285 octeontx2-pf: Fix page pool cache index corruption.
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ratheesh Kannoth <[email protected]>
[ Upstream commit 88e69af061f2e061a68751ef9cad47a674527a1b ]
The access to page pool cache' array and the count' variable is not locked. Page pool cache access is fine as long as there is only one consumer per pool.
octeontx2 driver fills in rx buffers from page pool in NAPI context. If system is stressed and could not allocate buffers, refiiling work will be delegated to a delayed workqueue. This means that there are two cosumers to the page pool cache.
Either workqueue or IRQ/NAPI can be run on other CPU. This will lead to lock less access, hence corruption of cache pool indexes.
To fix this issue, NAPI is rescheduled from workqueue context to refill rx buffers.
--- .../ethernet/marvell/octeontx2/nic/cn10k.c | 6 ++- .../ethernet/marvell/octeontx2/nic/cn10k.h | 2 +- .../marvell/octeontx2/nic/otx2_common.c | 43 +++---------------- .../marvell/octeontx2/nic/otx2_common.h | 3 +- .../ethernet/marvell/octeontx2/nic/otx2_pf.c | 7 +-- .../marvell/octeontx2/nic/otx2_txrx.c | 30 ++++++++++--- .../marvell/octeontx2/nic/otx2_txrx.h | 4 +- 7 files changed, 44 insertions(+), 51 deletions(-)
drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c +4 -2
@@ -107,12 +107,13 @@ int cn10k_sq_aq_init(void *dev, u16 qidx, u16 sqb_aura) }#define NPA_MAX_BURST 16 -void cn10k_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq) +int cn10k_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq) {struct otx2_nic *pfvf = dev; +int cnt = cq->pool_ptrs;u64 ptrs[NPA_MAX_BURST ]; -int num_ptrs =1 ;dma_addr_t bufptr; +int num_ptrs =1 ;/* Refill pool with new buffers */ while (cq->pool_ptrs) {
@@ -131,6 +132,7 @@ void cn10k_refill_pool_ptrs(void *dev, struct otx2_cq_queue *cq) num_ptrs =1 ; } } +return cnt - cq->pool_ptrs; }void cn10k_sqe_flush (void *dev,struct otx2_snd_queue *sq,int size,int qidx)
drivers/net/ethernet/marvell/octeontx2/nic/cn10k.h +1 -1
@@ -24,7 +24,7 @@ static inline int mtu_to_dwrr_weight(struct otx2_nic *pfvf, int mtu)return weight; } -void cn10k_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq); +int cn10k_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq);void cn10k_sqe_flush (void *dev,struct otx2_snd_queue *sq,int size,int qidx);int cn10k_sq_aq_init (void *dev,u16 qidx,u16 sqb_aura);int cn10k_lmtst_init (struct otx2_nic *pfvf);
drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c +6 -37
65 lines not on this page · raw message
drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h +2 -1
@@ -301,6 +301,7 @@ struct flr_work {struct refill_work {struct delayed_work pool_refill_work;struct otx2_nic *pf; +struct napi_struct *napi; };/* PTPv2 originTimestamp structure */
@@ -373,7 +374,7 @@ struct dev_hw_ops {int (*sq_aq_init)(void *dev,u16 qidx,u16 sqb_aura);void (*sqe_flush)(void *dev,struct otx2_snd_queue *sq,int size,int qidx); -void (*refill_pool_ptrs)(void *dev,struct otx2_cq_queue *cq); +int (*refill_pool_ptrs)(void *dev,struct otx2_cq_queue *cq);void (*aura_freeptr)(void *dev,int aura,u64 buf); };
drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c +4 -3
@@ -1942,6 +1942,10 @@ int otx2_stop(struct net_device *netdev)netif_tx_disable (netdev); +for (wrk =0 ; wrk < pf->qset.cq_cnt; wrk++) +cancel_delayed_work_sync (&pf->refill_wrk[wrk].pool_refill_work); +devm_kfree (pf->dev, pf->refill_wrk); +otx2_free_hw_resources (pf);otx2_free_cints (pf, pf->hw.cint_cnt);otx2_disable_napi (pf);
@@ -1949,9 +1953,6 @@ int otx2_stop(struct net_device *netdev)for (qidx =0 ; qidx < netdev->num_tx_queues; qidx++)netdev_tx_reset_queue (netdev_get_tx_queue (netdev, qidx)); -for (wrk =0 ; wrk < pf->qset.cq_cnt; wrk++) -cancel_delayed_work_sync (&pf->refill_wrk[wrk].pool_refill_work); -devm_kfree (pf->dev, pf->refill_wrk);kfree (qset->sq);kfree (qset->cq);
drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c +25 -5
@@ -424,9 +424,10 @@ static int otx2_rx_napi_handler(struct otx2_nic *pfvf,return processed_cqe; } -void otx2_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq) +int otx2_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq) {struct otx2_nic *pfvf = dev; +int cnt = cq->pool_ptrs;dma_addr_t bufptr;while (cq->pool_ptrs) {
@@ -435,6 +436,8 @@ void otx2_refill_pool_ptrs(void *dev, struct otx2_cq_queue *cq)otx2_aura_freeptr (pfvf, cq->cq_idx, bufptr +OTX2_HEAD_ROOM ); cq->pool_ptrs--; } + +return cnt - cq->pool_ptrs; } static int otx2_tx_napi_handler(struct otx2_nic *pfvf,
@@ -521,6 +524,7 @@ int otx2_napi_handler(struct napi_struct *napi, int budget)struct otx2_cq_queue *cq;struct otx2_qset *qset;struct otx2_nic *pfvf; +int filled_cnt =-1 ; cq_poll = container_of(napi, struct otx2_cq_poll, napi); pfvf = (struct otx2_nic *)cq_poll->dev;
@@ -541,7 +545,7 @@ int otx2_napi_handler(struct napi_struct *napi, int budget) }if (rx_cq && rx_cq->pool_ptrs) - pfvf->hw_ops->refill_pool_ptrs (pfvf, rx_cq); + filled_cnt = pfvf->hw_ops->refill_pool_ptrs (pfvf, rx_cq);/* Clear the IRQ */ otx2_write64 (pfvf,NIX_LF_CINTX_INT (cq_poll->cint_idx),BIT_ULL (0 ));
@@ -561,9 +565,25 @@ int otx2_napi_handler(struct napi_struct *napi, int budget)otx2_config_irq_coalescing (pfvf, i); } -/* Re-enable interrupts */ -otx2_write64 (pfvf,NIX_LF_CINTX_ENA_W1S (cq_poll->cint_idx), -BIT_ULL (0 )); +if (unlikely (!filled_cnt)) { +struct refill_work *work; +struct delayed_work *dwork; + + work = &pfvf->refill_wrk[cq->cq_idx]; + dwork = &work->pool_refill_work; +/* Schedule a task if no other task is running */ +if (!cq->refill_task_sched) { + work->napi = napi; + cq->refill_task_sched = true; +schedule_delayed_work (dwork, +msecs_to_jiffies (100 )); + } + }else { +/* Re-enable interrupts */ +otx2_write64 (pfvf, +NIX_LF_CINTX_ENA_W1S (cq_poll->cint_idx), +BIT_ULL (0 )); + } }return workdone; }
drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.h +2 -2
@@ -170,6 +170,6 @@ void cn10k_sqe_flush(void *dev, struct otx2_snd_queue *sq, int size, int qidx);void otx2_sqe_flush (void *dev,struct otx2_snd_queue *sq,int size,int qidx); -void otx2_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq); -void cn10k_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq); +int otx2_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq); +int cn10k_refill_pool_ptrs (void *dev,struct otx2_cq_queue *cq);#endif /* OTX2_TXRX_H */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 253/285 net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangguan Wang <[email protected]>
[ Upstream commit f5146e3ef0a9eea405874b36178c19a4863b8989 ]
While doing smcr_port_add, there maybe linkgroup add into or delete from smc_lgr_list.list at the same time, which may result kernel crash. So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add.
The crash calltrace show below:
BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014 Workqueue: events smc_ib_port_event_work [smc] RIP: 0010:smcr_port_add+0xa6/0xf0 [smc] RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918 R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4 R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08 FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0 PKRU: 55555554 Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30
--- net/smc/smc_core.c | 2 ++ 1 file changed, 2 insertions(+)
net/smc/smc_core.c +2 -0
@@ -1654,6 +1654,7 @@ void smcr_port_add(struct smc_ib_device *smcibdev, u8 ibport) {struct smc_link_group *lgr, *n; +spin_lock_bh (&smc_lgr_list.lock);list_for_each_entry_safe (lgr, n, &smc_lgr_list.list, list) {struct smc_link *link;
@@ -1669,6 +1670,7 @@ void smcr_port_add(struct smc_ib_device *smcibdev, u8 ibport)if (link)smc_llc_add_link_local (link); } +spin_unlock_bh (&smc_lgr_list.lock); }/* link is down - switch connections to alternate link,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 254/285 net: stmmac: fix handling of zero coalescing tx-usecs
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vincent Whitchurch <[email protected]>
[ Upstream commit fa60b8163816f194786f3ee334c9a458da7699c6 ]
Setting ethtool -C eth0 tx-usecs 0 is supposed to disable the use of the coalescing timer but currently it gets programmed with zero delay instead.
Disable the use of the coalescing timer if tx-usecs is zero by preventing it from being restarted. Note that to keep things simple we don't start/stop the timer when the coalescing settings are changed, but just let that happen on the next transmit or timer expiry.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +6 -4
@@ -2703,9 +2703,7 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)/* We still have pending packets, let's call for a new scheduling */ if (tx_q->dirty_tx != tx_q->cur_tx) -hrtimer_start (&tx_q->txtimer, -STMMAC_COAL_TIMER (priv->tx_coal_timer[queue]), -HRTIMER_MODE_REL ); +stmmac_tx_timer_arm (priv, queue);__netif_tx_unlock_bh (netdev_get_tx_queue (priv->dev, queue));
@@ -2986,9 +2984,13 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)static void stmmac_tx_timer_arm (struct stmmac_priv *priv,u32 queue) {struct stmmac_tx_queue *tx_q = &priv->dma_conf.tx_queue[queue]; +u32 tx_coal_timer = priv->tx_coal_timer[queue]; + +if (!tx_coal_timer) +return ;hrtimer_start (&tx_q->txtimer, -STMMAC_COAL_TIMER (priv->tx_coal_timer[queue]), +STMMAC_COAL_TIMER (tx_coal_timer),HRTIMER_MODE_REL ); }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 255/285 net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangyu Hua <[email protected]>
[ Upstream commit 51fe0a470543f345e3c62b6798929de3ddcedc1d ]
rules is allocated in ethtool_get_rxnfc and the size is determined by rule_cnt from user space. So rule_cnt needs to be check before using rules to avoid OOB writing or NULL pointer dereference.
--- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +5 -0
@@ -5586,6 +5586,11 @@ static int mvpp2_ethtool_get_rxnfc(struct net_device *dev,break ;case ETHTOOL_GRXCLSRLALL :for (i =0 ; i <MVPP2_N_RFS_ENTRIES_PER_FLOW ; i++) { +if (loc == info->rule_cnt) { + ret = -EMSGSIZE ; +break ; + } +if (port->rfs_rules[i]) rules[loc++] = i; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 256/285 net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangyu Hua <[email protected]>
[ Upstream commit e4c79810755f66c9a933ca810da2724133b1165a ]
rule_locs is allocated in ethtool_get_rxnfc and the size is determined by rule_cnt from user space. So rule_cnt needs to be check before using rule_locs to avoid NULL pointer dereference.
--- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/mediatek/mtk_eth_soc.c +3 -0
@@ -2860,6 +2860,9 @@ static int mtk_hwlro_get_fdir_all(struct net_device *dev,int i;for (i =0 ; i <MTK_MAX_LRO_IP_CNT ; i++) { +if (cnt == cmd->rule_cnt) +return -EMSGSIZE ; +if (mac->hwlro_ip[i]) { rule_locs[cnt] = i; cnt++;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 257/285 hsr: Fix uninit-value access in fill_frame_info()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ziyang Xuan <[email protected]>
[ Upstream commit 484b4833c604c0adcf19eac1ca14b60b757355b5 ]
Syzbot reports the following uninit-value access problem.
=====================================================
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82
Uninit was created at:
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82
It is because VLAN not yet supported in hsr driver. Return error when protocol is ETH_P_8021Q in fill_frame_info() now to fix it.
--- net/hsr/hsr_forward.c | 1 + 1 file changed, 1 insertion(+)
net/hsr/hsr_forward.c +1 -0
@@ -594,6 +594,7 @@ static int fill_frame_info(struct hsr_frame_info *frame, proto = vlan_hdr->vlanhdr.h_vlan_encapsulated_proto;/* FIXME: */ netdev_warn_once (skb->dev,"VLAN not yet supported" ); +return -EINVAL ; } frame->is_from_san = false;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 258/285 net: ethernet: adi: adin1110: use eth_broadcast_addr() to assign broadcast address
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
[ Upstream commit 54024dbec95585243391caeb9f04a2620e630765 ]
Use eth_broadcast_addr() to assign broadcast address instead of memset().
Stable-dep-of: 32530dba1bd4 ("net:ethernet:adi:adin1110: Fix forwarding offload")
--- drivers/net/ethernet/adi/adin1110.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/net/ethernet/adi/adin1110.c +4 -4
@@ -739,7 +739,7 @@ static int adin1110_broadcasts_filter(struct adin1110_port_priv *port_priv,u32 port_rules =0 ;u8 mask[ETH_ALEN ]; -memset (mask,0xFF ,ETH_ALEN ); +eth_broadcast_addr (mask);if (accept_broadcast && port_priv->state ==BR_STATE_FORWARDING ) port_rules =adin1110_port_rules (port_priv, true, true);
@@ -760,7 +760,7 @@ static int adin1110_set_mac_address(struct net_device *netdev,return -EADDRNOTAVAIL ;eth_hw_addr_set (netdev, dev_addr); -memset (mask,0xFF ,ETH_ALEN ); +eth_broadcast_addr (mask); mac_slot = (!port_priv->nr) ?ADIN_MAC_P1_ADDR_SLOT :ADIN_MAC_P2_ADDR_SLOT ; port_rules =adin1110_port_rules (port_priv, true, false);
@@ -1271,7 +1271,7 @@ static int adin1110_port_set_blocking_state(struct adin1110_port_priv *port_priv goto out;/* Allow only BPDUs to be passed to the CPU */ -memset (mask,0xFF ,ETH_ALEN ); +eth_broadcast_addr (mask); port_rules =adin1110_port_rules (port_priv, true, false); ret =adin1110_write_mac_address (port_priv, mac_slot, mac, mask, port_rules);
@@ -1386,7 +1386,7 @@ static int adin1110_fdb_add(struct adin1110_port_priv *port_priv, other_port = priv->ports[!port_priv->nr]; port_rules =adin1110_port_rules (port_priv, false, true); -memset (mask,0xFF ,ETH_ALEN ); +eth_broadcast_addr (mask);return adin1110_write_mac_address (other_port, mac_nr, (u8 *)fdb->addr, mask, port_rules);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 259/285 net:ethernet:adi:adin1110: Fix forwarding offload
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ciprian Regus <[email protected]>
[ Upstream commit 32530dba1bd48da4437d18d9a8dbc9d2826938a6 ]
Currently, when a new fdb entry is added (with both ports of the ADIN2111 bridged), the driver configures the MAC filters for the wrong port, which results in the forwarding being done by the host, and not actually hardware offloaded.
The ADIN2111 offloads the forwarding by setting filters on the destination MAC address of incoming frames. Based on these, they may be routed to the other port. Thus, if a frame has to be forwarded from port 1 to port 2, the required configuration for the ADDR_FILT_UPRn register should set the APPLY2PORT1 bit (instead of APPLY2PORT2, as it's currently the case).
--- drivers/net/ethernet/adi/adin1110.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/adi/adin1110.c +1 -1
@@ -1385,7 +1385,7 @@ static int adin1110_fdb_add(struct adin1110_port_priv *port_priv,return -ENOMEM ; other_port = priv->ports[!port_priv->nr]; - port_rules =adin1110_port_rules (port_priv, false, true); + port_rules =adin1110_port_rules (other_port, false, true);eth_broadcast_addr (mask); return adin1110_write_mac_address(other_port, mac_nr, (u8 *)fdb->addr,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 260/285 net: dsa: sja1105: hide all multicast addresses from "bridge fdb show"
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit 02c652f5465011126152bbd93b6a582a1d0c32f1 ]
Commit 4d9423549501 ("net: dsa: sja1105: offload bridge port flags to device") has partially hidden some multicast entries from showing up in the "bridge fdb show" output, but it wasn't enough. Addresses which are added through "bridge mdb add" still show up. Hide them all.
--- drivers/net/dsa/sja1105/sja1105_main.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/net/dsa/sja1105/sja1105_main.c +6 -5
@@ -1875,13 +1875,14 @@ static int sja1105_fdb_dump(struct dsa_switch *ds, int port,if (!(l2_lookup.destports &BIT (port)))continue ; -/* We need to hide the FDB entry for unknown multicast */ -if (l2_lookup.macaddr ==SJA1105_UNKNOWN_MULTICAST && - l2_lookup.mask_macaddr ==SJA1105_UNKNOWN_MULTICAST ) -continue ; -u64_to_ether_addr (l2_lookup.macaddr, macaddr); +/* Hardware FDB is shared for fdb and mdb, "bridge fdb show" +* only wants to see unicast +*/ +if (is_multicast_ether_addr (macaddr)) +continue ; +/* We need to hide the dsa_8021q VLANs from the user. */ if (vid_is_dsa_8021q (l2_lookup.vlanid)) l2_lookup.vlanid =0 ;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 261/285 net: dsa: sja1105: propagate exact error code from sja1105_dynamic_config_poll_valid()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit c956798062b5a308db96e75157747291197f0378 ]
Currently, sja1105_dynamic_config_wait_complete() returns either 0 or -ETIMEDOUT, because it just looks at the read_poll_timeout() return code.
There will be future changes which move some more checks to sja1105_dynamic_config_poll_valid(). It is important that we propagate their exact return code (-ENOENT, -EINVAL), because callers of sja1105_dynamic_config_read() depend on them.
Stable-dep-of: 7cef293b9a63 ("net: dsa: sja1105: fix multicast forwarding working only for last added mdb entry")
--- drivers/net/dsa/sja1105/sja1105_dynamic_config.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
drivers/net/dsa/sja1105/sja1105_dynamic_config.c +8 -7
@@ -1211,13 +1211,14 @@ sja1105_dynamic_config_wait_complete(struct sja1105_private *priv,struct sja1105_dyn_cmd *cmd, const struct sja1105_dynamic_table_ops *ops) { - int rc; - -return read_poll_timeout (sja1105_dynamic_config_poll_valid, - rc, rc != -EAGAIN , -SJA1105_DYNAMIC_CONFIG_SLEEP_US , -SJA1105_DYNAMIC_CONFIG_TIMEOUT_US , - false, priv, cmd, ops); + int err, rc; + + err =read_poll_timeout (sja1105_dynamic_config_poll_valid, + rc, rc != -EAGAIN , +SJA1105_DYNAMIC_CONFIG_SLEEP_US , +SJA1105_DYNAMIC_CONFIG_TIMEOUT_US , + false, priv, cmd, ops); +return err <0 ? err : rc; }/* Provides read access to the settings through the dynamic interface
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 262/285 net: dsa: sja1105: fix multicast forwarding working only for last added mdb entry
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit 7cef293b9a634a05fcce9e1df4aee3aeed023345 ]
The commit cited in Fixes: did 2 things: it refactored the read-back polling from sja1105_dynamic_config_read() into a new function, sja1105_dynamic_config_wait_complete(), and it called that from sja1105_dynamic_config_write() too.
What is problematic is the refactoring.
The refactored code from sja1105_dynamic_config_poll_valid() works like the previous one, but the problem is that it uses another packed_buf[] SPI buffer, and there was code at the end of sja1105_dynamic_config_read() which was relying on the read-back packed_buf[]:
/* Don't dereference possibly NULL pointer - maybe caller * only wanted to see whether the entry existed or not. */ if (entry) ops->entry_packing(packed_buf, entry, UNPACK);
After the change, the packed_buf[] that this code sees is no longer the entry read back from hardware, but the original entry that the caller passed to the sja1105_dynamic_config_read(), packed into this buffer.
This difference is the most notable with the SJA1105_SEARCH uses from sja1105pqrs_fdb_add() - used for both fdb and mdb. There, we have logic added by commit 728db843df88 ("net: dsa: sja1105: ignore the FDB entry for unknown multicast when adding a new address") to figure out whether the address we're trying to add matches on any existing hardware entry, with the exception of the catch-all multicast address.
That logic was broken, because with sja1105_dynamic_config_read() not working properly, it doesn't return us the entry read back from hardware, but the entry that we passed to it. And, since for multicast, a match will always exist, it will tell us that any mdb entry already exists at index=0 L2 Address Lookup table. It is index=0 because the caller doesn't know the index - it wants to find it out, and sja1105_dynamic_config_read() does:
if (index < 0) { // SJA1105_SEARCH
/* Avoid copying a signed negative number to an u64 */
cmd.index = 0; // <- this
cmd.search = true;
} else {
cmd.index = index;
cmd.search = false;
}So, to the caller of sja1105_dynamic_config_read(), the returned info looks entirely legit, and it will add all mdb entries to FDB index 0. There, they will always overwrite each other (not to mention, potentially they can also overwrite a pre-existing bridge fdb entry), and the user-visible impact will be that only the last mdb entry will be forwarded as it should. The others won't (will be flooded or dropped, depending on the egress flood settings).
Fixing is a bit more complicated, and involves either passing the same packed_buf[] to sja1105_dynamic_config_wait_complete(), or moving all the extra processing on the packed_buf[] to sja1105_dynamic_config_wait_complete(). I've opted for the latter, because it makes sja1105_dynamic_config_wait_complete() a bit more self-contained.
--- .../net/dsa/sja1105/sja1105_dynamic_config.c | 80 +++++++++---------- 1 file changed, 37 insertions(+), 43 deletions(-)
drivers/net/dsa/sja1105/sja1105_dynamic_config.c +37 -43
@@ -1175,18 +1175,15 @@ const struct sja1105_dynamic_table_ops sja1110_dyn_ops[BLK_IDX_MAX_DYN] = {static int sja1105_dynamic_config_poll_valid (struct sja1105_private *priv, -struct sja1105_dyn_cmd *cmd, -const struct sja1105_dynamic_table_ops *ops) +const struct sja1105_dynamic_table_ops *ops, +void *entry,bool check_valident, +bool check_errors) {u8 packed_buf[SJA1105_MAX_DYN_CMD_SIZE ] = {}; +struct sja1105_dyn_cmd cmd = {};int rc; -/* We don't _need_ to read the full entry, just the command area which -* is a fixed SJA1105_SIZE_DYN_CMD. But our cmd_packing() API expects a -* buffer that contains the full entry too. Additionally, our API -* doesn't really know how many bytes into the buffer does the command -* area really begin. So just read back the whole entry. -*/ +/* Read back the whole entry + command structure. */ rc =sja1105_xfer_buf (priv,SPI_READ , ops->addr, packed_buf, ops->packed_size);if (rc)
@@ -1195,11 +1192,25 @@ sja1105_dynamic_config_poll_valid(struct sja1105_private *priv,/* Unpack the command structure, and return it to the caller in case it * needs to perform further checks on it (VALIDENT). */ -memset (cmd,0 ,sizeof (*cmd)); - ops->cmd_packing (packed_buf, cmd,UNPACK ); + ops->cmd_packing (packed_buf, &cmd,UNPACK );/* Hardware hasn't cleared VALID => still working on it */ -return cmd->valid ? -EAGAIN :0 ; +if (cmd.valid) +return -EAGAIN ; + +if (check_valident && !cmd.valident && !(ops->access &OP_VALID_ANYWAY )) +return -ENOENT ; + +if (check_errors && cmd.errors) +return -EINVAL ; + +/* Don't dereference possibly NULL pointer - maybe caller +* only wanted to see whether the entry existed or not. +*/ +if (entry) + ops->entry_packing (packed_buf, entry,UNPACK ); + +return 0 ; }/* Poll the dynamic config entry's control area until the hardware has
@@ -1208,8 +1219,9 @@ sja1105_dynamic_config_poll_valid(struct sja1105_private *priv,*/ static int sja1105_dynamic_config_wait_complete (struct sja1105_private *priv, -struct sja1105_dyn_cmd *cmd, -const struct sja1105_dynamic_table_ops *ops) +const struct sja1105_dynamic_table_ops *ops, +void *entry,bool check_valident, +bool check_errors) {int err, rc;
@@ -1217,7 +1229,8 @@ sja1105_dynamic_config_wait_complete(struct sja1105_private *priv, rc, rc != -EAGAIN ,SJA1105_DYNAMIC_CONFIG_SLEEP_US ,SJA1105_DYNAMIC_CONFIG_TIMEOUT_US , - false, priv, cmd, ops); + false, priv, ops, entry, check_valident, + check_errors);return err <0 ? err : rc; }
@@ -1287,25 +1300,14 @@ int sja1105_dynamic_config_read(struct sja1105_private *priv,mutex_lock (&priv->dynamic_config_lock); rc =sja1105_xfer_buf (priv,SPI_WRITE , ops->addr, packed_buf, ops->packed_size); -if (rc <0 ) { -mutex_unlock (&priv->dynamic_config_lock); -return rc; - } - - rc =sja1105_dynamic_config_wait_complete (priv, &cmd, ops); -mutex_unlock (&priv->dynamic_config_lock);if (rc <0 ) -return rc; + goto out; -if (!cmd.valident && !(ops->access &OP_VALID_ANYWAY )) -return -ENOENT ; + rc =sja1105_dynamic_config_wait_complete (priv, ops, entry, true, false); +out: +mutex_unlock (&priv->dynamic_config_lock); -/* Don't dereference possibly NULL pointer - maybe caller -* only wanted to see whether the entry existed or not. -*/ -if (entry) - ops->entry_packing (packed_buf, entry,UNPACK ); -return 0 ; +return rc; } int sja1105_dynamic_config_write(struct sja1105_private *priv,
@@ -1357,22 +1359,14 @@ int sja1105_dynamic_config_write(struct sja1105_private *priv,mutex_lock (&priv->dynamic_config_lock); rc =sja1105_xfer_buf (priv,SPI_WRITE , ops->addr, packed_buf, ops->packed_size); -if (rc <0 ) { -mutex_unlock (&priv->dynamic_config_lock); -return rc; - } - - rc =sja1105_dynamic_config_wait_complete (priv, &cmd, ops); -mutex_unlock (&priv->dynamic_config_lock);if (rc <0 ) -return rc; + goto out; - cmd = (struct sja1105_dyn_cmd ) {0 }; - ops->cmd_packing (packed_buf, &cmd,UNPACK ); -if (cmd.errors) -return -EINVAL ; + rc =sja1105_dynamic_config_wait_complete (priv, ops,NULL , false, true); +out: +mutex_unlock (&priv->dynamic_config_lock); -return 0 ; +return rc; }static u8 sja1105_crc8_add (u8 crc,u8 byte,u8 poly)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 263/285 net: dsa: sja1105: serialize sja1105_port_mcast_flood() with other FDB accesses
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit ea32690daf4fa525dc5a4d164bd00ed8c756e1c6 ]
sja1105_fdb_add() runs from the dsa_owq, and sja1105_port_mcast_flood() runs from switchdev_deferred_process_work(). Prior to the blamed commit, they used to be indirectly serialized through the rtnl_lock(), which no longer holds true because dsa_owq dropped that.
So, it is now possible that we traverse the static config BLK_IDX_L2_LOOKUP elements concurrently compared to when we change them, in sja1105_static_fdb_change(). That is not ideal, since it might result in data corruption.
Introduce a mutex which serializes accesses to the hardware FDB and to the static config elements for the L2 Address Lookup table.
I can't find a good reason to add locking around sja1105_fdb_dump(). I'll add it later if needed.
--- drivers/net/dsa/sja1105/sja1105.h | 2 + drivers/net/dsa/sja1105/sja1105_main.c | 56 ++++++++++++++++++++------ 2 files changed, 45 insertions(+), 13 deletions(-)
drivers/net/dsa/sja1105/sja1105.h +2 -0
@@ -266,6 +266,8 @@ struct sja1105_private {* the switch doesn't confuse them with one another. */ struct mutex mgmt_lock; +/* Serializes accesses to the FDB */ +struct mutex fdb_lock;/* PTP two-step TX timestamp ID, and its serialization lock */ spinlock_t ts_id_lock;u8 ts_id;
drivers/net/dsa/sja1105/sja1105_main.c +43 -13
124 lines not on this page · raw message
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 264/285 net: dsa: sja1105: block FDB accesses that are concurrent with a switch reset
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit 86899e9e1e29e854b5f6dcc24ba4f75f792c89aa ]
Currently, when we add the first sja1105 port to a bridge with vlan_filtering 1, then we sometimes see this output:
sja1105 spi2.2: port 4 failed to read back entry for be:79:b4:9e:9e:96 vid 3088: -ENOENT sja1105 spi2.2: Reset switch and programmed static config. Reason: VLAN filtering sja1105 spi2.2: port 0 failed to add be:79:b4:9e:9e:96 vid 0 to fdb: -2
It is because sja1105_fdb_add() runs from the dsa_owq which is no longer serialized with switch resets since it dropped the rtnl_lock() in the blamed commit.
Either performing the FDB accesses before the reset, or after the reset, is equally fine, because sja1105_static_fdb_change() backs up those changes in the static config, but FDB access during reset isn't ok.
Make sja1105_static_config_reload() take the fdb_lock to fix that.
--- drivers/net/dsa/sja1105/sja1105_main.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/dsa/sja1105/sja1105_main.c +2 -0
@@ -2304,6 +2304,7 @@ int sja1105_static_config_reload(struct sja1105_private *priv,int rc, i;s64 now; +mutex_lock (&priv->fdb_lock);mutex_lock (&priv->mgmt_lock); mac = priv->static_config.tables[BLK_IDX_MAC_CONFIG ].entries;
@@ -2416,6 +2417,7 @@ int sja1105_static_config_reload(struct sja1105_private *priv, goto out; out:mutex_unlock (&priv->mgmt_lock); +mutex_unlock (&priv->fdb_lock);return rc; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 265/285 r8152: check budget for r8152_poll()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hayes Wang <[email protected]>
[ Upstream commit a7b8d60b37237680009dd0b025fe8c067aba0ee3 ]
According to the document of napi, there is no rx process when the budget is 0. Therefore, r8152_poll() has to return 0 directly when the budget is equal to 0.
--- drivers/net/usb/r8152.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/usb/r8152.c +3 -0
@@ -2629,6 +2629,9 @@ static int r8152_poll(struct napi_struct *napi, int budget) struct r8152 *tp = container_of(napi, struct r8152, napi);int work_done; +if (!budget) +return 0 ; + work_done =rx_bottom (tp, budget);if (work_done < budget) {
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 266/285 kcm: Fix memory leak in error path of kcm_sendmsg()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit c821a88bd720b0046433173185fd841a100d44ad ]
syzbot reported a memory leak like below:
BUG: memory leak
unreferenced object 0xffff88810b088c00 (size 240):
comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s)
hex dump (first 32 bytes):
00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff83e5d5ff>] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634
[<ffffffff84606e59>] alloc_skb include/linux/skbuff.h:1289 [inline]
[<ffffffff84606e59>] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815
[<ffffffff83e479c6>] sock_sendmsg_nosec net/socket.c:725 [inline]
[<ffffffff83e479c6>] sock_sendmsg+0x56/0xb0 net/socket.c:748
[<ffffffff83e47f55>] ____sys_sendmsg+0x365/0x470 net/socket.c:2494
[<ffffffff83e4c389>] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548
[<ffffffff83e4c536>] __sys_sendmsg+0xa6/0x120 net/socket.c:2577
[<ffffffff84ad7bb8>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84ad7bb8>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
[<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to append newly allocated skbs to 'head'. If some bytes are copied, an error occurred, and jumped to out_error label, 'last_skb' is left unmodified. A later kcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the 'head' frag_list and causing the leak.
This patch fixes this issue by properly updating the last allocated skb in 'last_skb'.
--- net/kcm/kcmsock.c | 2 ++ 1 file changed, 2 insertions(+)
net/kcm/kcmsock.c +2 -0
@@ -939,6 +939,8 @@ static int kcm_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)if (head != kcm->seq_skb)kfree_skb (head); +else if (copied) +kcm_tx_msg (head)->last_skb = skb; err =sk_stream_error (sk, msg->msg_flags, err);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 267/285 platform/mellanox: mlxbf-tmfifo: Drop the Rx packet if no more descriptors
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liming Sun <[email protected]>
[ Upstream commit 78034cbece79c2d730ad0770b3b7f23eedbbecf5 ]
This commit fixes tmfifo console stuck issue when the virtual networking interface is in down state. In such case, the network Rx descriptors runs out and causes the Rx network packet staying in the head of the tmfifo thus blocking the console packets. The fix is to drop the Rx network packet when no more Rx descriptors. Function name mlxbf_tmfifo_release_pending_pkt() is also renamed to mlxbf_tmfifo_release_pkt() to be more approperiate.
--- drivers/platform/mellanox/mlxbf-tmfifo.c | 66 ++++++++++++++++++------ 1 file changed, 49 insertions(+), 17 deletions(-)
drivers/platform/mellanox/mlxbf-tmfifo.c +49 -17
@@ -59,6 +59,7 @@ struct mlxbf_tmfifo;* @vq: pointer to the virtio virtqueue * @desc: current descriptor of the pending packet * @desc_head: head descriptor of the pending packet +* @drop_desc: dummy desc for packet dropping * @cur_len: processed length of the current descriptor * @rem_len: remaining length of the pending packet * @pkt_len: total length of the pending packet
@@ -75,6 +76,7 @@ struct mlxbf_tmfifo_vring {struct virtqueue *vq;struct vring_desc *desc;struct vring_desc *desc_head; +struct vring_desc drop_desc;int cur_len;int rem_len;u32 pkt_len;
@@ -86,6 +88,14 @@ struct mlxbf_tmfifo_vring {struct mlxbf_tmfifo *fifo; }; +/* Check whether vring is in drop mode. */ +#define IS_VRING_DROP (_r) ({ \ + typeof(_r) (r) = (_r); \ + (r->desc_head == &r->drop_desc ? true : false); }) + +/* A stub length to drop maximum length packet. */ +#define VRING_DROP_DESC_MAX_LEN GENMASK(15, 0) +/* Interrupt types. */ enum {MLXBF_TM_RX_LWM_IRQ ,
@@ -262,6 +272,7 @@ static int mlxbf_tmfifo_alloc_vrings(struct mlxbf_tmfifo *fifo, vring->align =SMP_CACHE_BYTES ; vring->index = i; vring->vdev_id = tm_vdev->vdev.id.device; + vring->drop_desc.len =VRING_DROP_DESC_MAX_LEN ; dev = &tm_vdev->vdev.dev; size =vring_size (vring->num, vring->align);
@@ -367,7 +378,7 @@ static u32 mlxbf_tmfifo_get_pkt_len(struct mlxbf_tmfifo_vring *vring,return len; } -static void mlxbf_tmfifo_release_pending_pkt (struct mlxbf_tmfifo_vring *vring) +static void mlxbf_tmfifo_release_pkt (struct mlxbf_tmfifo_vring *vring) {struct vring_desc *desc_head;u32 len =0 ;
@@ -596,19 +607,25 @@ static void mlxbf_tmfifo_rxtx_word(struct mlxbf_tmfifo_vring *vring,if (vring->cur_len +sizeof (u64) <= len) {/* The whole word. */ -if (is_rx) -memcpy (addr + vring->cur_len, &data,sizeof (u64)); -else -memcpy (&data, addr + vring->cur_len,sizeof (u64)); +if (!IS_VRING_DROP (vring)) { +if (is_rx) +memcpy (addr + vring->cur_len, &data, +sizeof (u64)); +else +memcpy (&data, addr + vring->cur_len, +sizeof (u64)); + } vring->cur_len +=sizeof (u64); }else {/* Leftover bytes. */ -if (is_rx) -memcpy (addr + vring->cur_len, &data, - len - vring->cur_len); -else -memcpy (&data, addr + vring->cur_len, - len - vring->cur_len); +if (!IS_VRING_DROP (vring)) { +if (is_rx) +memcpy (addr + vring->cur_len, &data, + len - vring->cur_len); +else +memcpy (&data, addr + vring->cur_len, + len - vring->cur_len); + } vring->cur_len = len; }
@@ -709,8 +726,16 @@ static bool mlxbf_tmfifo_rxtx_one_desc(struct mlxbf_tmfifo_vring *vring,/* Get the descriptor of the next packet. */ if (!vring->desc) { desc =mlxbf_tmfifo_get_next_pkt (vring, is_rx); -if (!desc) -return false; +if (!desc) { +/* Drop next Rx packet to avoid stuck. */ +if (is_rx) { + desc = &vring->drop_desc; + vring->desc_head = desc; + vring->desc = desc; + }else { +return false; + } + } }else { desc = vring->desc; }
@@ -743,17 +768,24 @@ static bool mlxbf_tmfifo_rxtx_one_desc(struct mlxbf_tmfifo_vring *vring, vring->rem_len -= len;/* Get the next desc on the chain. */ -if (vring->rem_len >0 && +if (!IS_VRING_DROP (vring) && vring->rem_len >0 && (virtio16_to_cpu (vdev, desc->flags) &VRING_DESC_F_NEXT )) { idx =virtio16_to_cpu (vdev, desc->next); desc = &vr->desc[idx]; goto mlxbf_tmfifo_desc_done; } -/* Done and release the pending packet. */ -mlxbf_tmfifo_release_pending_pkt (vring); +/* Done and release the packet. */ desc =NULL ; fifo->vring[is_rx] =NULL ; +if (!IS_VRING_DROP (vring)) { +mlxbf_tmfifo_release_pkt (vring); + }else { + vring->pkt_len =0 ; + vring->desc_head =NULL ; + vring->desc =NULL ; +return false; + }/* * Make sure the load/store are in order before
@@ -933,7 +965,7 @@ static void mlxbf_tmfifo_virtio_del_vqs(struct virtio_device *vdev)/* Release the pending packet. */ if (vring->desc) -mlxbf_tmfifo_release_pending_pkt (vring); +mlxbf_tmfifo_release_pkt (vring); vq = vring->vq;if (vq) { vring->vq =NULL ;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 268/285 platform/mellanox: mlxbf-tmfifo: Drop jumbo frames
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liming Sun <[email protected]>
[ Upstream commit fc4c655821546239abb3cf4274d66b9747aa87dd ]
This commit drops over-sized network packets to avoid tmfifo queue stuck.
--- drivers/platform/mellanox/mlxbf-tmfifo.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-)
drivers/platform/mellanox/mlxbf-tmfifo.c +17 -7
@@ -224,7 +224,7 @@ static u8 mlxbf_tmfifo_net_default_mac[ETH_ALEN] = {static efi_char16_t mlxbf_tmfifo_efi_name[] =L"RshimMacAddr" ;/* Maximum L2 header length. */ -#define MLXBF_TMFIFO_NET_L2_OVERHEAD 36 +#define MLXBF_TMFIFO_NET_L2_OVERHEAD (ETH_HLEN + VLAN_HLEN)/* Supported virtio-net features. */ #define MLXBF_TMFIFO_NET_FEATURES \
@@ -642,13 +642,14 @@ static void mlxbf_tmfifo_rxtx_word(struct mlxbf_tmfifo_vring *vring,* flag is set. */ static void mlxbf_tmfifo_rxtx_header (struct mlxbf_tmfifo_vring *vring, -struct vring_desc *desc, +struct vring_desc **desc,bool is_rx,bool *vring_change) {struct mlxbf_tmfifo *fifo = vring->fifo;struct virtio_net_config *config;struct mlxbf_tmfifo_msg_hdr hdr;int vdev_id, hdr_len; +bool drop_rx = false;/* Read/Write packet header. */ if (is_rx) {
@@ -668,8 +669,8 @@ static void mlxbf_tmfifo_rxtx_header(struct mlxbf_tmfifo_vring *vring,if (ntohs (hdr.len) >__virtio16_to_cpu (virtio_legacy_is_little_endian (), config->mtu) + -MLXBF_TMFIFO_NET_L2_OVERHEAD ) -return ; +MLXBF_TMFIFO_NET_L2_OVERHEAD ) + drop_rx = true; }else { vdev_id =VIRTIO_ID_CONSOLE ; hdr_len =0 ;
@@ -684,16 +685,25 @@ static void mlxbf_tmfifo_rxtx_header(struct mlxbf_tmfifo_vring *vring,if (!tm_dev2)return ; - vring->desc = desc; + vring->desc = *desc; vring = &tm_dev2->vrings[MLXBF_TMFIFO_VRING_RX ]; *vring_change = true; } + +if (drop_rx && !IS_VRING_DROP (vring)) { +if (vring->desc_head) +mlxbf_tmfifo_release_pkt (vring); + *desc = &vring->drop_desc; + vring->desc_head = *desc; + vring->desc = *desc; + } + vring->pkt_len =ntohs (hdr.len) + hdr_len; }else {/* Network virtio has an extra header. */ hdr_len = (vring->vdev_id ==VIRTIO_ID_NET ) ?sizeof (struct virtio_net_hdr ) :0 ; - vring->pkt_len =mlxbf_tmfifo_get_pkt_len (vring, desc); + vring->pkt_len =mlxbf_tmfifo_get_pkt_len (vring, *desc); hdr.type = (vring->vdev_id ==VIRTIO_ID_NET ) ?VIRTIO_ID_NET :VIRTIO_ID_CONSOLE ; hdr.len =htons (vring->pkt_len - hdr_len);
@@ -742,7 +752,7 @@ static bool mlxbf_tmfifo_rxtx_one_desc(struct mlxbf_tmfifo_vring *vring,/* Beginning of a packet. Start to Rx/Tx packet header. */ if (vring->pkt_len ==0 ) { -mlxbf_tmfifo_rxtx_header (vring, desc, is_rx, &vring_change); +mlxbf_tmfifo_rxtx_header (vring, &desc, is_rx, &vring_change); (*avail)--;/* Return if new packet is for another ring. */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 269/285 platform/mellanox: mlxbf-pmc: Fix potential buffer overflows
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shravan Kumar Ramani <[email protected]>
[ Upstream commit 80ccd40568bcd3655b0fd0be1e9b3379fd6e1056 ]
Replace sprintf with sysfs_emit where possible.
Size check in mlxbf_pmc_event_list_show should account for "\0".
--- drivers/platform/mellanox/mlxbf-pmc.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/platform/mellanox/mlxbf-pmc.c +7 -7
@@ -1008,7 +1008,7 @@ static ssize_t mlxbf_pmc_counter_show(struct device *dev, }else return -EINVAL ; -return sprintf (buf,"0x%llx\n" , value); +return sysfs_emit (buf,"0x%llx\n" , value); }/* Store function for "counter" sysfs files */
@@ -1078,13 +1078,13 @@ static ssize_t mlxbf_pmc_event_show(struct device *dev, err =mlxbf_pmc_read_event (blk_num, cnt_num, is_l3, &evt_num);if (err) -return sprintf (buf,"No event being monitored\n" ); +return sysfs_emit (buf,"No event being monitored\n" ); evt_name =mlxbf_pmc_get_event_name (pmc->block_name[blk_num], evt_num);if (!evt_name)return -EINVAL ; -return sprintf (buf,"0x%llx: %s\n" , evt_num, evt_name); +return sysfs_emit (buf,"0x%llx: %s\n" , evt_num, evt_name); }/* Store function for "event" sysfs files */
@@ -1139,9 +1139,9 @@ static ssize_t mlxbf_pmc_event_list_show(struct device *dev,return -EINVAL ;for (i =0 , buf[0 ] ='\0' ; i < size; ++i) { - len +=sprintf (e_info,"0x%x: %s\n" , events[i].evt_num, - events[i].evt_name); -if (len >PAGE_SIZE ) + len +=snprintf (e_info,sizeof (e_info),"0x%x: %s\n" , + events[i].evt_num, events[i].evt_name); +if (len >=PAGE_SIZE )break ;strcat (buf, e_info); ret = len;
@@ -1168,7 +1168,7 @@ static ssize_t mlxbf_pmc_enable_show(struct device *dev, value =FIELD_GET (MLXBF_PMC_L3C_PERF_CNT_CFG_EN , perfcnt_cfg); -return sprintf (buf,"%d\n" , value); +return sysfs_emit (buf,"%d\n" , value); }/* Store function for "enable" sysfs files - only for l3cache */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 270/285 platform/mellanox: mlxbf-pmc: Fix reading of unprogrammed events
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shravan Kumar Ramani <[email protected]>
[ Upstream commit 0f5969452e162efc50bdc98968fb62b424a9874b ]
This fix involves 2 changes:
- All event regs have a reset value of 0, which is not a valid event_number as per the event_list for most blocks and hence seen as an error. Add a "disable" event with event_number 0 for all blocks.
- The enable bit for each counter need not be checked before reading the event info, and hence removed.
--- drivers/platform/mellanox/mlxbf-pmc.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-)
drivers/platform/mellanox/mlxbf-pmc.c +7 -20
@@ -191,6 +191,7 @@ static const struct mlxbf_pmc_events mlxbf_pmc_smgen_events[] = { };static const struct mlxbf_pmc_events mlxbf_pmc_trio_events_1[] = { + {0x0 ,"DISABLE" }, {0xa0 ,"TPIO_DATA_BEAT" }, {0xa1 ,"TDMA_DATA_BEAT" }, {0xa2 ,"MAP_DATA_BEAT" },
@@ -214,6 +215,7 @@ static const struct mlxbf_pmc_events mlxbf_pmc_trio_events_1[] = { };static const struct mlxbf_pmc_events mlxbf_pmc_trio_events_2[] = { + {0x0 ,"DISABLE" }, {0xa0 ,"TPIO_DATA_BEAT" }, {0xa1 ,"TDMA_DATA_BEAT" }, {0xa2 ,"MAP_DATA_BEAT" },
@@ -246,6 +248,7 @@ static const struct mlxbf_pmc_events mlxbf_pmc_trio_events_2[] = { };static const struct mlxbf_pmc_events mlxbf_pmc_ecc_events[] = { + {0x0 ,"DISABLE" }, {0x100 ,"ECC_SINGLE_ERROR_CNT" }, {0x104 ,"ECC_DOUBLE_ERROR_CNT" }, {0x114 ,"SERR_INJ" },
@@ -258,6 +261,7 @@ static const struct mlxbf_pmc_events mlxbf_pmc_ecc_events[] = { };static const struct mlxbf_pmc_events mlxbf_pmc_mss_events[] = { + {0x0 ,"DISABLE" }, {0xc0 ,"RXREQ_MSS" }, {0xc1 ,"RXDAT_MSS" }, {0xc2 ,"TXRSP_MSS" },
@@ -265,6 +269,7 @@ static const struct mlxbf_pmc_events mlxbf_pmc_mss_events[] = { };static const struct mlxbf_pmc_events mlxbf_pmc_hnf_events[] = { + {0x0 ,"DISABLE" }, {0x45 ,"HNF_REQUESTS" }, {0x46 ,"HNF_REJECTS" }, {0x47 ,"ALL_BUSY" },
@@ -323,6 +328,7 @@ static const struct mlxbf_pmc_events mlxbf_pmc_hnf_events[] = { };static const struct mlxbf_pmc_events mlxbf_pmc_hnfnet_events[] = { + {0x0 ,"DISABLE" }, {0x12 ,"CDN_REQ" }, {0x13 ,"DDN_REQ" }, {0x14 ,"NDN_REQ" },
@@ -892,7 +898,7 @@ static int mlxbf_pmc_read_event(int blk_num, uint32_t cnt_num, bool is_l3, uint64_t *result) {uint32_t perfcfg_offset, perfval_offset; -uint64_t perfmon_cfg, perfevt, perfctl; +uint64_t perfmon_cfg, perfevt;if (cnt_num >= pmc->block[blk_num].counters)return -EINVAL ;
@@ -904,25 +910,6 @@ static int mlxbf_pmc_read_event(int blk_num, uint32_t cnt_num, bool is_l3, perfval_offset = perfcfg_offset + pmc->block[blk_num].counters *MLXBF_PMC_REG_SIZE ; -/* Set counter in "read" mode */ - perfmon_cfg =FIELD_PREP (MLXBF_PMC_PERFMON_CONFIG_ADDR , -MLXBF_PMC_PERFCTL ); - perfmon_cfg |=FIELD_PREP (MLXBF_PMC_PERFMON_CONFIG_STROBE ,1 ); - perfmon_cfg |=FIELD_PREP (MLXBF_PMC_PERFMON_CONFIG_WR_R_B ,0 ); - -if (mlxbf_pmc_write (pmc->block[blk_num].mmio_base + perfcfg_offset, -MLXBF_PMC_WRITE_REG_64 , perfmon_cfg)) -return -EFAULT ; - -/* Check if the counter is enabled */ - -if (mlxbf_pmc_read (pmc->block[blk_num].mmio_base + perfval_offset, -MLXBF_PMC_READ_REG_64 , &perfctl)) -return -EFAULT ; - -if (!FIELD_GET (MLXBF_PMC_PERFCTL_EN0 , perfctl)) -return -EINVAL ; -/* Set counter in "read" mode */ perfmon_cfg =FIELD_PREP (MLXBF_PMC_PERFMON_CONFIG_ADDR ,MLXBF_PMC_PERFEVT );
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 271/285 platform/mellanox: NVSW_SN2201 should depend on ACPI
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geert Uytterhoeven <[email protected]>
[ Upstream commit 0a138f1670bd1af13ba6949c48ea86ddd4bf557e ]
The only probing method supported by the Nvidia SN2201 platform driver is probing through an ACPI match table. Hence add a dependency on ACPI, to prevent asking the user about this driver when configuring a kernel without ACPI support.
--- drivers/platform/mellanox/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/platform/mellanox/Kconfig +2 -2
@@ -80,8 +80,8 @@ config MLXBF_PMC config NVSW_SN2201 tristate "Nvidia SN2201 platform driver support" - depends on HWMON - depends on I2C + depends on HWMON && I2C + depends on ACPI || COMPILE_TEST select REGMAP_I2C help This driver provides support for the Nvidia SN2201 platform.
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 272/285 net/tls: do not free tls_rec on async operation in bpf_exec_tx_verdict()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Jian <[email protected]>
[ Upstream commit cfaa80c91f6f99b9342b6557f0f0e1143e434066 ]
I got the below warning when do fuzzing test:
BUG: KASAN: null-ptr-deref in scatterwalk_copychunks+0x320/0x470 Read of size 4 at addr 0000000000000008 by task kworker/u8:1/9 CPU: 0 PID: 9 Comm: kworker/u8:1 Tainted: G OE Hardware name: linux,dummy-virt (DT) Workqueue: pencrypt_parallel padata_parallel_worker Call trace: dump_backtrace+0x0/0x420 show_stack+0x34/0x44 dump_stack+0x1d0/0x248 __kasan_report+0x138/0x140 kasan_report+0x44/0x6c __asan_load4+0x94/0xd0 scatterwalk_copychunks+0x320/0x470 skcipher_next_slow+0x14c/0x290 skcipher_walk_next+0x2fc/0x480 skcipher_walk_first+0x9c/0x110 skcipher_walk_aead_common+0x380/0x440 skcipher_walk_aead_encrypt+0x54/0x70 ccm_encrypt+0x13c/0x4d0 crypto_aead_encrypt+0x7c/0xfc pcrypt_aead_enc+0x28/0x84 padata_parallel_worker+0xd0/0x2dc process_one_work+0x49c/0xbdc worker_thread+0x124/0x880 kthread+0x210/0x260 ret_from_fork+0x10/0x18
This is because the value of rec_seq of tls_crypto_info configured by the user program is too large, for example, 0xffffffffffffff. In addition, TLS is asynchronously accelerated. When tls_do_encryption() returns -EINPROGRESS and sk->sk_err is set to EBADMSG due to rec_seq overflow, skmsg is released before the asynchronous encryption process ends. As a result, the UAF problem occurs during the asynchronous processing of the encryption module.
If the operation is asynchronous and the encryption module returns EINPROGRESS, do not free the record information.
--- net/tls/tls_sw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/tls/tls_sw.c +2 -2
@@ -817,7 +817,7 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk, psock =sk_psock_get (sk);if (!psock || !policy) { err =tls_push_record (sk, flags, record_type); -if (err && sk->sk_err ==EBADMSG ) { +if (err && err != -EINPROGRESS && sk->sk_err ==EBADMSG ) { *copied -=sk_msg_free (sk, msg);tls_free_open_rec (sk); err = -sk->sk_err;
@@ -846,7 +846,7 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk,switch (psock->eval) {case __SK_PASS: err =tls_push_record (sk, flags, record_type); -if (err && sk->sk_err ==EBADMSG ) { +if (err && err != -EINPROGRESS && sk->sk_err ==EBADMSG ) { *copied -=sk_msg_free (sk, msg);tls_free_open_rec (sk); err = -sk->sk_err;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 273/285 net: macb: fix sleep inside spinlock
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sascha Hauer <[email protected]>
[ Upstream commit 403f0e771457e2b8811dc280719d11b9bacf10f4 ]
macb_set_tx_clk() is called under a spinlock but itself calls clk_set_rate() which can sleep. This results in:
| BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
| pps pps1: new PPS source ptp1
| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 40, name: kworker/u4:3
| preempt_count: 1, expected: 0
| RCU nest depth: 0, expected: 0
| 4 locks held by kworker/u4:3/40:
| #0: ffff000003409148
| macb ff0c0000.ethernet: gem-ptp-timer ptp clock registered.
| ((wq_completion)events_power_efficient){+.+.}-{0:0}, at: process_one_work+0x14c/0x51c
| #1: ffff8000833cbdd8 ((work_completion)(&pl->resolve)){+.+.}-{0:0}, at: process_one_work+0x14c/0x51c
| #2: ffff000004f01578 (&pl->state_mutex){+.+.}-{4:4}, at: phylink_resolve+0x44/0x4e8
| #3: ffff000004f06f50 (&bp->lock){....}-{3:3}, at: macb_mac_link_up+0x40/0x2ac
| irq event stamp: 113998
| hardirqs last enabled at (113997): [<ffff800080e8503c>] _raw_spin_unlock_irq+0x30/0x64
| hardirqs last disabled at (113998): [<ffff800080e84478>] _raw_spin_lock_irqsave+0xac/0xc8
| softirqs last enabled at (113608): [<ffff800080010630>] __do_softirq+0x430/0x4e4
| softirqs last disabled at (113597): [<ffff80008001614c>] ____do_softirq+0x10/0x1c
| CPU: 0 PID: 40 Comm: kworker/u4:3 Not tainted 6.5.0-11717-g9355ce8b2f50-dirty #368
| Hardware name: ... ZynqMP ... (DT)
| Workqueue: events_power_efficient phylink_resolve
| Call trace:
| dump_backtrace+0x98/0xf0
| show_stack+0x18/0x24
| dump_stack_lvl+0x60/0xac
| dump_stack+0x18/0x24
| __might_resched+0x144/0x24c
| __might_sleep+0x48/0x98
| __mutex_lock+0x58/0x7b0
| mutex_lock_nested+0x24/0x30
| clk_prepare_lock+0x4c/0xa8
| clk_set_rate+0x24/0x8c
| macb_mac_link_up+0x25c/0x2ac
| phylink_resolve+0x178/0x4e8
| process_one_work+0x1ec/0x51c
| worker_thread+0x1ec/0x3e4
| kthread+0x120/0x124
| ret_from_fork+0x10/0x20The obvious fix is to move the call to macb_set_tx_clk() out of the protected area. This seems safe as rx and tx are both disabled anyway at this point.
It is however not entirely clear what the spinlock shall protect. It could be the read-modify-write access to the NCFGR register, but this is accessed in macb_set_rx_mode() and macb_set_rxcsum_feature() as well without holding the spinlock. It could also be the register accesses done in mog_init_rings() or macb_init_buffers(), but again these functions are called without holding the spinlock in macb_hresp_error_task(). The locking seems fishy in this driver and it might deserve another look before this patch is applied.
--- drivers/net/ethernet/cadence/macb_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/ethernet/cadence/macb_main.c +3 -2
@@ -757,8 +757,6 @@ static void macb_mac_link_up(struct phylink_config *config,if (rx_pause) ctrl |=MACB_BIT (PAE ); -macb_set_tx_clk (bp, speed); -/* Initialize rings & buffers as clearing MACB_BIT(TE) in link down * cleared the pipeline and control registers. */
@@ -778,6 +776,9 @@ static void macb_mac_link_up(struct phylink_config *config,spin_unlock_irqrestore (&bp->lock, flags); +if (!(bp->caps &MACB_CAPS_MACB_IS_EMAC )) +macb_set_tx_clk (bp, speed); +/* Enable Rx and Tx; Enable PTP unicast */ ctrl =macb_readl (bp,NCR );if (gem_has_ptp (bp))
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 274/285 veth: Update XDP feature set when bringing up device
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toke Høiland-Jørgensen <[email protected]>
[ Upstream commit 7a6102aa6df0d5d032b4cbc51935d1d4cda17254 ]
There's an early return in veth_set_features() if the device is in a down state, which leads to the XDP feature flags not being updated when enabling GRO while the device is down. Which in turn leads to XDP_REDIRECT not working, because the redirect code now checks the flags.
Fix this by updating the feature flags after bringing the device up.
Before this patch:
NETDEV_XDP_ACT_BASIC: yesNETDEV_XDP_ACT_REDIRECT: yesNETDEV_XDP_ACT_NDO_XMIT: noNETDEV_XDP_ACT_XSK_ZEROCOPY: noNETDEV_XDP_ACT_HW_OFFLOAD: noNETDEV_XDP_ACT_RX_SG: yesNETDEV_XDP_ACT_NDO_XMIT_SG: no
After this patch:
NETDEV_XDP_ACT_BASIC: yesNETDEV_XDP_ACT_REDIRECT: yesNETDEV_XDP_ACT_NDO_XMIT: yesNETDEV_XDP_ACT_XSK_ZEROCOPY: noNETDEV_XDP_ACT_HW_OFFLOAD: noNETDEV_XDP_ACT_RX_SG: yesNETDEV_XDP_ACT_NDO_XMIT_SG: yes
--- drivers/net/veth.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/veth.c +2 -0
@@ -1447,6 +1447,8 @@ static int veth_open(struct net_device *dev)netif_carrier_on (peer); } +veth_set_xdp_features (dev); +return 0 ; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 275/285 ipv6: fix ip6_sock_set_addr_preferences() typo
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 8cdd9f1aaedf823006449faa4e540026c692ac43 ]
ip6_sock_set_addr_preferences() second argument should be an integer.
SUNRPC attempts to set IPV6_PREFER_SRC_PUBLIC were translated to IPV6_PREFER_SRC_TMP
--- include/net/ipv6.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/net/ipv6.h +1 -1
@@ -1356,7 +1356,7 @@ static inline int __ip6_sock_set_addr_preferences(struct sock *sk, int val)return 0 ; } -static inline int ip6_sock_set_addr_preferences (struct sock *sk,bool val) +static inline int ip6_sock_set_addr_preferences (struct sock *sk,int val) {int ret;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 276/285 tcp: Factorise sk_family-independent comparison in inet_bind2_bucket_match(_addr_any).
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit c6d277064b1da7f9015b575a562734de87a7e463 ]
This is a prep patch to make the following patches cleaner that touch inet_bind2_bucket_match() and inet_bind2_bucket_match_addr_any().
Both functions have duplicated comparison for netns, port, and l3mdev. Let's factorise them.
Stable-dep-of: aa99e5f87bd5 ("tcp: Fix bind() regression for v4-mapped-v6 wildcard address.")
--- net/ipv4/inet_hashtables.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-)
net/ipv4/inet_hashtables.c +13 -15
@@ -795,41 +795,39 @@ static bool inet_bind2_bucket_match(const struct inet_bind2_bucket *tb, const struct net *net, unsigned short port, int l3mdev, const struct sock *sk) { + if (!net_eq(ib2_net(tb), net) || tb->port != port || + tb->l3mdev != l3mdev) + return false; +#if IS_ENABLED (CONFIG_IPV6 )if (sk->sk_family != tb->family)return false;if (sk->sk_family ==AF_INET6 ) -return net_eq (ib2_net (tb), net) && tb->port == port && - tb->l3mdev == l3mdev && -ipv6_addr_equal (&tb->v6_rcv_saddr, &sk->sk_v6_rcv_saddr); - else +return ipv6_addr_equal (&tb->v6_rcv_saddr, &sk->sk_v6_rcv_saddr);#endif -return net_eq (ib2_net (tb), net) && tb->port == port && - tb->l3mdev == l3mdev && tb->rcv_saddr == sk->sk_rcv_saddr; +return tb->rcv_saddr == sk->sk_rcv_saddr; }bool inet_bind2_bucket_match_addr_any (const struct inet_bind2_bucket *tb,const struct net *net,unsigned short port,int l3mdev,const struct sock *sk) { +if (!net_eq (ib2_net (tb), net) || tb->port != port || + tb->l3mdev != l3mdev) +return false; +#if IS_ENABLED (CONFIG_IPV6 )if (sk->sk_family != tb->family) {if (sk->sk_family ==AF_INET ) -return net_eq (ib2_net (tb), net) && tb->port == port && - tb->l3mdev == l3mdev && -ipv6_addr_any (&tb->v6_rcv_saddr); +return ipv6_addr_any (&tb->v6_rcv_saddr);return false; }if (sk->sk_family ==AF_INET6 ) -return net_eq (ib2_net (tb), net) && tb->port == port && - tb->l3mdev == l3mdev && -ipv6_addr_any (&tb->v6_rcv_saddr); - else +return ipv6_addr_any (&tb->v6_rcv_saddr);#endif -return net_eq (ib2_net (tb), net) && tb->port == port && - tb->l3mdev == l3mdev && tb->rcv_saddr ==0 ; +return tb->rcv_saddr ==0 ; }/* The socket's bhash2 hashbucket spinlock must be held when this is called */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 277/285 tcp: Fix bind() regression for v4-mapped-v6 wildcard address.
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit aa99e5f87bd54db55dd37cb130bd5eb55933027f ]
Andrei Vagin reported bind() regression with strace logs.
If we bind() a TCPv6 socket to ::FFFF:0.0.0.0 and then bind() a TCPv4 socket to 127.0.0.1, the 2nd bind() should fail but now succeeds.
from socket import *
s1 = socket(AF_INET6, SOCK_STREAM)
s1.bind(('::ffff:0.0.0.0', 0))
s2 = socket(AF_INET, SOCK_STREAM)
s2.bind(('127.0.0.1', s1.getsockname()[1]))
During the 2nd bind(), if tb->family is AF_INET6 and sk->sk_family is AF_INET in inet_bind2_bucket_match_addr_any(), we still need to check if tb has the v4-mapped-v6 wildcard address.
The example above does not work after commit 5456262d2baa ("net: Fix incorrect address comparison when searching for a bind2 bucket"), but the blamed change is not the commit.
Before the commit, the leading zeros of ::FFFF:0.0.0.0 were treated as 0.0.0.0, and the sequence above worked by chance. Technically, this case has been broken since bhash2 was introduced.
Note that if we bind() two sockets to 127.0.0.1 and then ::FFFF:0.0.0.0, the 2nd bind() fails properly because we fall back to using bhash to detect conflicts for the v4-mapped-v6 address.
--- include/net/ipv6.h | 5 +++++ net/ipv4/inet_hashtables.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-)
include/net/ipv6.h +5 -0
@@ -784,6 +784,11 @@ static inline bool ipv6_addr_v4mapped(const struct in6_addr *a) cpu_to_be32(0x0000ffff))) == 0UL; } +static inline bool ipv6_addr_v4mapped_any (const struct in6_addr *a) +{ +return ipv6_addr_v4mapped (a) &&ipv4_is_zeronet (a->s6_addr32[3 ]); +} +static inline bool ipv6_addr_v4mapped_loopback (const struct in6_addr *a) {return ipv6_addr_v4mapped (a) &&ipv4_is_loopback (a->s6_addr32[3 ]);
net/ipv4/inet_hashtables.c +2 -1
@@ -819,7 +819,8 @@ bool inet_bind2_bucket_match_addr_any(const struct inet_bind2_bucket *tb, const#if IS_ENABLED (CONFIG_IPV6 )if (sk->sk_family != tb->family) {if (sk->sk_family ==AF_INET ) -return ipv6_addr_any (&tb->v6_rcv_saddr); +return ipv6_addr_any (&tb->v6_rcv_saddr) || +ipv6_addr_v4mapped_any (&tb->v6_rcv_saddr);return false; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 278/285 tcp: Fix bind() regression for v4-mapped-v6 non-wildcard address.
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit c48ef9c4aed3632566b57ba66cec6ec78624d4cb ]
Since bhash2 was introduced, the example below does not work as expected. These two bind() should conflict, but the 2nd bind() now succeeds.
from socket import *
s1 = socket(AF_INET6, SOCK_STREAM)
s1.bind(('::ffff:127.0.0.1', 0))
s2 = socket(AF_INET, SOCK_STREAM)
s2.bind(('127.0.0.1', s1.getsockname()[1]))
During the 2nd bind() in inet_csk_get_port(), inet_bind2_bucket_find() fails to find the 1st socket's tb2, so inet_bind2_bucket_create() allocates a new tb2 for the 2nd socket. Then, we call inet_csk_bind_conflict() that checks conflicts in the new tb2 by inet_bhash2_conflict(). However, the new tb2 does not include the 1st socket, thus the bind() finally succeeds.
In this case, inet_bind2_bucket_match() must check if AF_INET6 tb2 has the conflicting v4-mapped-v6 address so that inet_bind2_bucket_find() returns the 1st socket's tb2.
Note that if we bind two sockets to 127.0.0.1 and then ::FFFF:127.0.0.1, the 2nd bind() fails properly for the same reason mentinoed in the previous commit.
--- net/ipv4/inet_hashtables.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
net/ipv4/inet_hashtables.c +6 -1
@@ -800,8 +800,13 @@ static bool inet_bind2_bucket_match(const struct inet_bind2_bucket *tb,return false;#if IS_ENABLED (CONFIG_IPV6 ) -if (sk->sk_family != tb->family) +if (sk->sk_family != tb->family) { +if (sk->sk_family ==AF_INET ) +return ipv6_addr_v4mapped (&tb->v6_rcv_saddr) && + tb->v6_rcv_saddr.s6_addr32[3 ] == sk->sk_rcv_saddr; +return false; + }if (sk->sk_family ==AF_INET6 )return ipv6_addr_equal (&tb->v6_rcv_saddr, &sk->sk_v6_rcv_saddr);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 279/285 selftest: tcp: Fix address length in bind_wildcard.c.
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 0071d15517b4a3d265abc00395beb1138e7236c7 ]
The selftest passes the IPv6 address length for an IPv4 address. We should pass the correct length.
Note inet_bind_sk() does not check if the size is larger than sizeof(struct sockaddr_in), so there is no real bug in this selftest.
--- tools/testing/selftests/net/bind_wildcard.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/net/bind_wildcard.c +1 -1
@@ -100,7 +100,7 @@ void bind_sockets(struct __test_metadata *_metadata, TEST_F(bind_wildcard, v4_v6) {bind_sockets (_metadata, self, - (struct sockaddr *)&self->addr4,sizeof (self->addr6), + (struct sockaddr *)&self->addr4,sizeof (self->addr4), (struct sockaddr *)&self->addr6,sizeof (self->addr6)); }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 280/285 ixgbe: fix timestamp configuration code
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vadim Fedorenko <[email protected]>
[ Upstream commit 3c44191dd76cf9c0cc49adaf34384cbd42ef8ad2 ]
The commit in fixes introduced flags to control the status of hardware configuration while processing packets. At the same time another structure is used to provide configuration of timestamper to user-space applications. The way it was coded makes this structures go out of sync easily. The repro is easy for 82599 chips:
[root@hostname ~]# hwstamp_ctl -i eth0 -r 12 -t 1
current settings:tx_type 0rx_filter 0
new settings:tx_type 1rx_filter 12
The eth0 device is properly configured to timestamp any PTPv2 events.
[root@hostname ~]# hwstamp_ctl -i eth0 -r 1 -t 1 current settings:tx_type 1rx_filter 12
SIOCSHWTSTAMP failed: Numerical result out of range
The requested time stamping mode is not supported by the hardware.
The error is properly returned because HW doesn't support all packets timestamping. But the adapter->flags is cleared of timestamp flags even though no HW configuration was done. From that point no RX timestamps are received by user-space application. But configuration shows good values:
[root@hostname ~]# hwstamp_ctl -i eth0
current settings:tx_type 1rx_filter 12
Fix the issue by applying new flags only when the HW was actually configured.
--- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 28 +++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c +15 -13
@@ -979,6 +979,7 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,u32 tsync_tx_ctl =IXGBE_TSYNCTXCTL_ENABLED ;u32 tsync_rx_ctl =IXGBE_TSYNCRXCTL_ENABLED ;u32 tsync_rx_mtrl =PTP_EV_PORT <<16 ; +u32 aflags = adapter->flags;bool is_l2 = false;u32 regval;
@@ -996,20 +997,20 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,case HWTSTAMP_FILTER_NONE : tsync_rx_ctl =0 ; tsync_rx_mtrl =0 ; - adapter->flags &= ~(IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags &= ~(IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V1_L4_SYNC : tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_L4_V1 ; tsync_rx_mtrl |=IXGBE_RXMTRL_V1_SYNC_MSG ; - adapter->flags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ : tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_L4_V1 ; tsync_rx_mtrl |=IXGBE_RXMTRL_V1_DELAY_REQ_MSG ; - adapter->flags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V2_EVENT :case HWTSTAMP_FILTER_PTP_V2_L2_EVENT :
@@ -1023,8 +1024,8 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter, tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_EVENT_V2 ; is_l2 = true; config->rx_filter =HWTSTAMP_FILTER_PTP_V2_EVENT ; - adapter->flags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V1_L4_EVENT :case HWTSTAMP_FILTER_NTP_ALL :
@@ -1035,7 +1036,7 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,if (hw->mac.type >= ixgbe_mac_X550) { tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_ALL ; config->rx_filter =HWTSTAMP_FILTER_ALL ; - adapter->flags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ; + aflags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ;break ; } fallthrough;
@@ -1046,8 +1047,6 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,* Delay_Req messages and hardware does not support * timestamping all packets => return error */ - adapter->flags &= ~(IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); config->rx_filter =HWTSTAMP_FILTER_NONE ;return -ERANGE ; }
@@ -1079,8 +1078,8 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,IXGBE_TSYNCRXCTL_TYPE_ALL |IXGBE_TSYNCRXCTL_TSIP_UT_EN ; config->rx_filter =HWTSTAMP_FILTER_ALL ; - adapter->flags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ; - adapter->flags &= ~IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ; + aflags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ; + aflags &= ~IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ; is_l2 = true;break ;default :
@@ -1113,6 +1112,9 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,IXGBE_WRITE_FLUSH (hw); +/* configure adapter flags only when HW is actually configured */ + adapter->flags = aflags; +/* clear TX/RX time stamp registers, just to be sure */ ixgbe_ptp_clear_tx_timestamp (adapter);IXGBE_READ_REG (hw,IXGBE_RXSTMPH );
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 281/285 igb: clean up in all error paths when enabling SR-IOV
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Corinna Vinschen <[email protected]>
[ Upstream commit bc6ed2fa24b14e40e1005488bbe11268ce7108fa ]
After commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removing the igb module could hang or crash (depending on the machine) when the module has been loaded with the max_vfs parameter set to some value != 0.
In case of one test machine with a dual port 82580, this hang occurred:
[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1 [ 233.093257] igb 0000:41:00.1: IOV Disabled [ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0 [ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata) [ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000 [ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First) [ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c [ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata) [ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000 [ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First) [ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c [ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback) [ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0 [ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed [ 234.157244] igb 0000:41:00.0: IOV Disabled [ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds. [ 371.627489] Not tainted 6.4.0-dirty #2 [ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this. [ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0 [ 371.650330] Call Trace: [ 371.653061] <TASK> [ 371.655407] __schedule+0x20e/0x660 [ 371.659313] schedule+0x5a/0xd0 [ 371.662824] schedule_preempt_disabled+0x11/0x20 [ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0 [ 371.673237] ? __pfx_aer_root_reset+0x10/0x10 [ 371.678105] report_error_detected+0x25/0x1c0 [ 371.682974] ? __pfx_report_normal_detected+0x10/0x10 [ 371.688618] pci_walk_bus+0x72/0x90 [ 371.692519] pcie_do_recovery+0xb2/0x330 [ 371.696899] aer_process_err_devices+0x117/0x170 [ 371.702055] aer_isr+0x1c0/0x1e0 [ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0 [ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10 [ 371.715496] irq_thread_fn+0x20/0x60 [ 371.719491] irq_thread+0xe6/0x1b0 [ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10 [ 371.728255] ? __pfx_irq_thread+0x10/0x10 [ 371.732731] kthread+0xe2/0x110 [ 371.736243] ? __pfx_kthread+0x10/0x10 [ 371.740430] ret_from_fork+0x2c/0x50 [ 371.744428] </TASK>
The reproducer was a simple script:
#!/bin/sh
for i in seq 1 5; do
modprobe -rv igb
modprobe -v igb max_vfs=1
sleep 1
modprobe -rv igb
done
It turned out that this could only be reproduce on 82580 (quad and dual-port), but not on 82576, i350 and i210. Further debugging showed that igb_enable_sriov()'s call to pci_enable_sriov() is failing, because dev->is_physfn is 0 on 82580.
Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), igb_enable_sriov() jumped into the "err_out" cleanup branch. After this commit it only returned the error code.
So the cleanup didn't take place, and the incorrect VF setup in the igb_adapter structure fooled the igb driver into assuming that VFs have been set up where no VF actually existed.
Fix this problem by cleaning up again if pci_enable_sriov() fails.
--- drivers/net/ethernet/intel/igb/igb_main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/igb/igb_main.c +4 -1
@@ -3827,8 +3827,11 @@ static int igb_enable_sriov(struct pci_dev *pdev, int num_vfs, bool reinit) }/* only call pci_enable_sriov() if no VFs are allocated already */ -if (!old_vfs) +if (!old_vfs) { err =pci_enable_sriov (pdev, adapter->vfs_allocated_count); +if (err) + goto err_out; + } goto out;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 282/285 net: renesas: rswitch: Fix unmasking irq condition
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yoshihiro Shimoda <[email protected]>
[ Upstream commit e7b1ef29420fe52c2c1a273a9b4b36103a522625 ]
Fix unmasking irq condition by using napi_complete_done(). Otherwise, redundant interrupts happen.
--- drivers/net/ethernet/renesas/rswitch.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/net/ethernet/renesas/rswitch.c +4 -4
@@ -816,10 +816,10 @@ static int rswitch_poll(struct napi_struct *napi, int budget)netif_wake_subqueue (ndev,0 ); -napi_complete (napi); - -rswitch_enadis_data_irq (priv, rdev->tx_queue->index, true); -rswitch_enadis_data_irq (priv, rdev->rx_queue->index, true); +if (napi_complete_done (napi, budget - quota)) { +rswitch_enadis_data_irq (priv, rdev->tx_queue->index, true); +rswitch_enadis_data_irq (priv, rdev->rx_queue->index, true); + } out:return budget - quota;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 283/285 kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit a22730b1b4bf437c6bbfdeff5feddf54be4aeada ]
syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720 ("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it by updating kcm_tx_msg(head)->last_skb if partial data is copied so that the following sendmsg() will resume from the skb.
However, we cannot know how many bytes were copied when we get the error. Thus, we could mess up the MSG_MORE queue.
When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as we do so for UDP by udp_flush_pending_frames().
Even without this change, when the error occurred, the following sendmsg() resumed from a wrong skb and the queue was messed up. However, we have yet to get such a report, and only syzkaller stumbled on it. So, this can be changed safely.
Note this does not change SOCK_SEQPACKET behaviour.
--- net/kcm/kcmsock.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
net/kcm/kcmsock.c +8 -7
@@ -930,17 +930,18 @@ static int kcm_sendmsg(struct socket *sock, struct msghdr *msg, size_t len) out_error:kcm_push (kcm); -if (copied && sock->type ==SOCK_SEQPACKET ) { +if (sock->type ==SOCK_SEQPACKET ) {/* Wrote some bytes before encountering an * error, return partial success. */ - goto partial_message; - } - -if (head != kcm->seq_skb) +if (copied) + goto partial_message; +if (head != kcm->seq_skb) +kfree_skb (head); + }else {kfree_skb (head); -else if (copied) -kcm_tx_msg (head)->last_skb = skb; + kcm->seq_skb =NULL ; + } err =sk_stream_error (sk, msg->msg_flags, err);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 284/285 vm: fix move_vma() memory accounting being off
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <[email protected]>
commit 3cec50490969afd4a76ccee441f747d869ccff77 upstream.
Commit 408579cd627a ("mm: Update do_vmi_align_munmap() return semantics") seems to have updated one of the callers of do_vmi_munmap()
incorrectly: it used to check for the error case (which didn't
change: negative means error).
That commit changed the check to the success case (which did change:
before that commit, 0 was success, and 1 was "success and lock downgraded". After the change, it's always 0 for success, and the lock will have been released if requested).
This didn't change any actual VM behavior _except_ for memory accounting when 'VM_ACCOUNT' was set on the vma. Which made the wrong return value test fairly subtle, since everything continues to work.
Or rather - it continues to work but the "Committed memory" accounting goes all wonky (Committed_AS value in /proc/meminfo), and depending on settings that then causes problems much much later as the VM relies on bogus statistics for its heuristics.
Revert that one line of the change back to the original logic.
--- mm/mremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/mremap.c +1 -1
@@ -715,7 +715,7 @@ static unsigned long move_vma(struct vm_ }vma_iter_init (&vmi, mm, old_addr); -if (!do_vmi_munmap (&vmi, mm, old_addr, old_len, uf_unmap, false)) { +if (do_vmi_munmap (&vmi, mm, old_addr, old_len, uf_unmap, false) <0 ) {/* OOM: unable to split vma, just get accounts right */ if (vm_flags &VM_ACCOUNT && !(flags &MREMAP_DONTUNMAP ))vm_acct_memory (old_len >>PAGE_SHIFT );
Greg Kroah-Hartman
maintainerPATCH 285/285 drm/amd/display: Fix a bug when searching for insert_above_mpcc
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wesley Chalmers <[email protected]>
commit 3d028d5d60d516c536de1ddd3ebf3d55f3f8983b upstream.
[WHY]
Currently, when insert_plane is called with insert_above_mpcc parameter that is equal to tree->opp_list, the function returns NULL.
[HOW]
Instead, the function should insert the plane at the top of the tree.
--- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c +3 -2
@@ -212,8 +212,9 @@ struct mpcc *mpc1_insert_plane(/* check insert_above_mpcc exist in tree->opp_list */ struct mpcc *temp_mpcc = tree->opp_list; -while (temp_mpcc && temp_mpcc->mpcc_bot != insert_above_mpcc) - temp_mpcc = temp_mpcc->mpcc_bot; +if (temp_mpcc != insert_above_mpcc) +while (temp_mpcc && temp_mpcc->mpcc_bot != insert_above_mpcc) + temp_mpcc = temp_mpcc->mpcc_bot;if (temp_mpcc ==NULL )return NULL ; }
Hello,
Quoted 5 lines · On Sun, 17 Sep 2023 21:10:00 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.5.4 release. There are 285 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines
Responses should be made by Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] e5d077fb1eae ("Linux 6.5.4-rc1")
Thanks,
SJ
[...]
---
[32m
ok 1 selftests: damon: debugfs_attrs.sh
ok 2 selftests: damon: debugfs_schemes.sh
ok 3 selftests: damon: debugfs_target_ids.sh
ok 4 selftests: damon: debugfs_empty_targets.sh
ok 5 selftests: damon: debugfs_huge_count_read_write.sh
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: debugfs_rm_non_contexts.sh
ok 8 selftests: damon: sysfs.sh
ok 9 selftests: damon: sysfs_update_removed_scheme_dir.sh
ok 10 selftests: damon: reclaim.sh
ok 11 selftests: damon: lru_sort.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_m68k.sh
ok 12 selftests: damon-tests: build_arm64.sh
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m_remote_run_corr.sh SUCCESS
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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.
Successfully compiled and installed bindeb-pkgs on my computer (Acer Aspire E15, Intel Core i3 Haswell). No noticeable regressions.
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +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.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Jon Hunter
maintainerHi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
...
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rate
Unfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
Sorry about this.
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 26 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 8 lines
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rateUnfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
Is it also a problem in Linus's tree? Keeping bug-compatible is always good :)
thanks,
greg k-h
Jon Hunter
maintainerQuoted 31 lines · Greg Kroah-Hartman
Quoted 30 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rate
Quoted 7 lines
Quoted 4 lines
Unfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
Is it also a problem in Linus's tree? Keeping bug-compatible is always good :)
Yes this is also seen in Linus' tree, so we are compatible :-)
Jon
Signature · 1 line
nvpublic
Quoted 31 lines · Greg Kroah-Hartman
Quoted 30 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rate
Quoted 8 lines
Quoted 4 lines
Unfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
Is it also a problem in Linus's tree? Keeping bug-compatible is always good :)
Sorry, no, it isn't, especially in the context of at the same time suggesting that everyone should start using the most recent stable release immediately (instead of, say, selectively picking security patches).
I don't think Tegra users would be happy if their audio stopped working, and it seems unlikely that they would accept the argument that they should be happy to be bug-compatible with the latest upstream kernel - even more so if that latest upstream kernel is a release candidate and the problem was introduced in the commit window.
Guenter
Greg Kroah-Hartman
maintainerQuoted 45 lines · Guenter Roeck
Quoted 31 lines · Greg Kroah-Hartman
Quoted 30 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rateQuoted 8 lines
Quoted 4 lines
Unfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
Is it also a problem in Linus's tree? Keeping bug-compatible is always good :)
Sorry, no, it isn't, especially in the context of at the same time suggesting that everyone should start using the most recent stable release immediately (instead of, say, selectively picking security patches).
Quoted 5 lines
I don't think Tegra users would be happy if their audio stopped working, and it seems unlikely that they would accept the argument that they should be happy to be bug-compatible with the latest upstream kernel - even more so if that latest upstream kernel is a release candidate and the problem was introduced in the commit window.
Very good point, I've now dropped it.
greg k-h
Hi!
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rateUnfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
Is it also a problem in Linus's tree? Keeping bug-compatible is always good :)
Please update Documentation/process/stable-kernel-rules.rst accordingly. People expect certain properties from stable tree, and of the rules written there only "It or an equivalent fix must already exist in Linus' tree (upstream)." is followed.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Jon Hunter
maintainerQuoted 26 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.y and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 7 lines
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rateUnfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
An alternative to dropping this change is to pull in the following fixes ...
https://lore.kernel.org/linux-tegra/[email protected]/T/#t
Thanks
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 35 lines · Jon Hunter
Quoted 33 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.y and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rateUnfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Quoted 6 lines
Quoted 1 line
Can we drop this from stable for now?
An alternative to dropping this change is to pull in the following fixes ...
they aren't in Linus's tree yet, any plans on when that will happen?
And to confirm, what are the git ids of these in linux-next?
thanks,
greg k-h
Jon Hunter
maintainerQuoted 36 lines · Greg Kroah-Hartman
Quoted 35 lines · Jon Hunter
Quoted 33 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rateUnfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Can we drop this from stable for now?
An alternative to dropping this change is to pull in the following fixes ...
they aren't in Linus's tree yet, any plans on when that will happen?
Not clear at the moment, I see Mark has them queued up here ...
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/log/?h=for-6.6
Quoted 1 line
And to confirm, what are the git ids of these in linux-next?
In next I see the following git ids ...
e765886249c5 ASoC: tegra: Fix redundant PLLA and PLLA_OUT0 updates f101583fa9f8 ASoC: soc-utils: Export snd_soc_dai_is_dummy() symbol
Thanks
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 26 lines · Jon Hunter
Hi Greg,
Quoted 20 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:...
Quoted 8 lines
Quoted 2 lines
Sameer Pujar <[email protected]>
arm64: tegra: Update AHUB clock parent and rateUnfortunately, the above change is causing a regression in one of our audio tests and we are looking into why this is.
Can we drop this from stable for now?
Ok, now dropped, thanks all for the report.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +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.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +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.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.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.5.4-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.5.y
* git commit: e5d077fb1eae958bde2a55b3065972193e501b78
* git describe: v6.5.2-1016-ge5d077fb1eae
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.2-1016-ge5d077fb1eae
## Test Regressions (compared to v6.5.2-740-g7bfd1316ceae)
## Metric Regressions (compared to v6.5.2-740-g7bfd1316ceae)
## Test Fixes (compared to v6.5.2-740-g7bfd1316ceae)
## Metric Fixes (compared to v6.5.2-740-g7bfd1316ceae)
## Test result summary
total: 245581, pass: 211062, fail: 3143, skip: 31023, xfail: 353
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 278 total, 276 passed, 2 failed
* arm64: 94 total, 90 passed, 4 failed
* i386: 69 total, 69 passed, 0 failed
* mips: 59 total, 55 passed, 4 failed
* parisc: 8 total, 8 passed, 0 failed
* powerpc: 75 total, 71 passed, 4 failed
* riscv: 52 total, 48 passed, 4 failed
* s390: 32 total, 26 passed, 6 failed
* sh: 28 total, 24 passed, 4 failed
* sparc: 16 total, 16 passed, 0 failed
* x86_64: 81 total, 76 passed, 5 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 157 fail: 0 Qemu test results: total: 530 pass: 530 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +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.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.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
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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 Tue, 19 Sep 2023 19:10:04 +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.5.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.5.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 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.5.4 release. There are 285 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.
Thanks,
Conor.