7.0.11-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 360/461 drm/xe/vf: Fix signature of print functions
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Wajdeczko <[email protected]>
[ Upstream commit 9bb2f1d7e6e58b8e434ddc2048c661bf87ccdf2a ]
We have plugged-in existing VF print functions into our GT debugfs show helper as-is, but we missed that the helper expects functions to return int, while they were defined as void. This can lead to errors being reported when CFI is enabled.
--- drivers/gpu/drm/xe/xe_gt_sriov_vf.c | 24 ++++++++++++++++++------ drivers/gpu/drm/xe/xe_gt_sriov_vf.h | 6 +++--- 2 files changed, 21 insertions(+), 9 deletions(-)
drivers/gpu/drm/xe/xe_gt_sriov_vf.c +18 -6
@@ -1129,13 +1129,15 @@ void xe_gt_sriov_vf_write32(struct xe_gt *gt, struct xe_reg reg, u32 val) }/** -* xe_gt_sriov_vf_print_config - Print VF self config. +* xe_gt_sriov_vf_print_config() - Print VF self config. * @gt: the &xe_gt * @p: the &drm_printer * * This function is for VF use only. +* +* Return: always 0. */ -void xe_gt_sriov_vf_print_config (struct xe_gt *gt,struct drm_printer *p) +int xe_gt_sriov_vf_print_config (struct xe_gt *gt,struct drm_printer *p) {struct xe_gt_sriov_vf_selfconfig *config = >->sriov.vf.self_config;struct xe_device *xe =gt_to_xe (gt);
@@ -1162,16 +1164,20 @@ void xe_gt_sriov_vf_print_config(struct xe_gt *gt, struct drm_printer *p)drm_printf (p,"GuC contexts:\t%u\n" , config->num_ctxs);drm_printf (p,"GuC doorbells:\t%u\n" , config->num_dbs); + +return 0 ; }/** -* xe_gt_sriov_vf_print_runtime - Print VF's runtime regs received from PF. +* xe_gt_sriov_vf_print_runtime() - Print VF's runtime regs received from PF. * @gt: the &xe_gt * @p: the &drm_printer * * This function is for VF use only. +* +* Return: always 0. */ -void xe_gt_sriov_vf_print_runtime (struct xe_gt *gt,struct drm_printer *p) +int xe_gt_sriov_vf_print_runtime (struct xe_gt *gt,struct drm_printer *p) {struct vf_runtime_reg *vf_regs = gt->sriov.vf.runtime.regs;unsigned int size = gt->sriov.vf.runtime.num_regs;
@@ -1180,16 +1186,20 @@ void xe_gt_sriov_vf_print_runtime(struct xe_gt *gt, struct drm_printer *p)for (; size--; vf_regs++)drm_printf (p,"%#x = %#x\n" , vf_regs->offset, vf_regs->value); + +return 0 ; }/** -* xe_gt_sriov_vf_print_version - Print VF ABI versions. +* xe_gt_sriov_vf_print_version() - Print VF ABI versions. * @gt: the &xe_gt * @p: the &drm_printer * * This function is for VF use only. +* +* Return: always 0. */ -void xe_gt_sriov_vf_print_version (struct xe_gt *gt,struct drm_printer *p) +int xe_gt_sriov_vf_print_version (struct xe_gt *gt,struct drm_printer *p) {struct xe_device *xe =gt_to_xe (gt);struct xe_uc_fw_version *guc_version = >->sriov.vf.guc_version;
@@ -1219,6 +1229,8 @@ void xe_gt_sriov_vf_print_version(struct xe_gt *gt, struct drm_printer *p) GUC_RELAY_VERSION_LATEST_MAJOR, GUC_RELAY_VERSION_LATEST_MINOR);drm_printf (p,"\thandshake:\t%u.%u\n" , pf_version->major, pf_version->minor); + +return 0 ; }static bool vf_post_migration_shutdown (struct xe_gt *gt)
drivers/gpu/drm/xe/xe_gt_sriov_vf.h +3 -3
@@ -35,9 +35,9 @@ bool xe_gt_sriov_vf_sched_groups_enabled(struct xe_gt *gt);u32 xe_gt_sriov_vf_read32 (struct xe_gt *gt,struct xe_reg reg);void xe_gt_sriov_vf_write32 (struct xe_gt *gt,struct xe_reg reg,u32 val); -void xe_gt_sriov_vf_print_config (struct xe_gt *gt,struct drm_printer *p); -void xe_gt_sriov_vf_print_runtime (struct xe_gt *gt,struct drm_printer *p); -void xe_gt_sriov_vf_print_version (struct xe_gt *gt,struct drm_printer *p); +int xe_gt_sriov_vf_print_config (struct xe_gt *gt,struct drm_printer *p); +int xe_gt_sriov_vf_print_runtime (struct xe_gt *gt,struct drm_printer *p); +int xe_gt_sriov_vf_print_version (struct xe_gt *gt,struct drm_printer *p);void xe_gt_sriov_vf_wait_valid_ggtt (struct xe_gt *gt);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 361/461 drm/xe/pf: Fix CFI failure in debugfs access
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohanram Meenakshisundaram <[email protected]>
[ Upstream commit 96bf49b526e2d03a2b7f6e861925a08f46ed0d28 ]
Reading debugfs file (/sys/kernel/debug/dri/0/gt*/pf/adverse_events) with CFI (Control Flow Integrity) enabled, the kernel panics at xe_gt_debugfs_simple_show+0x82/0xc0.
xe_gt_debugfs_simple_show() declare a function pointer expecting int return type, but xe_gt_sriov_pf_monitor_print_events() is void return type, leading to CFI failure and kernel panic.
[507620.973657] CFI failure at xe_gt_debugfs_simple_show+0x82/0xc0 [xe]
(target: xe_gt_sriov_pf_monitor_print_events+0x0/0x130 [xe]; expected
type: 0xd72c7139)
Fix xe_gt_sriov_pf_monitor_print_events() function by updating to return an int type.
--- drivers/gpu/drm/xe/xe_gt_sriov_pf_monitor.c | 6 +++++- drivers/gpu/drm/xe/xe_gt_sriov_pf_monitor.h | 2 +- 2 files changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/xe_gt_sriov_pf_monitor.c +5 -1
@@ -114,8 +114,10 @@ int xe_gt_sriov_pf_monitor_process_guc2pf(struct xe_gt *gt, const u32 *msg, u32* VFs with no events are not printed. * * This function can only be called on PF. +* +* Return: always 0 */ -void xe_gt_sriov_pf_monitor_print_events (struct xe_gt *gt,struct drm_printer *p) +int xe_gt_sriov_pf_monitor_print_events (struct xe_gt *gt,struct drm_printer *p) {unsigned int n, total_vfs =xe_gt_sriov_pf_get_totalvfs (gt);const struct xe_gt_sriov_monitor *data;
@@ -144,4 +146,6 @@ void xe_gt_sriov_pf_monitor_print_events(struct xe_gt *gt, struct drm_printer *p#undef __format#undef __value } + +return 0 ; }
drivers/gpu/drm/xe/xe_gt_sriov_pf_monitor.h +1 -1
@@ -13,7 +13,7 @@ struct drm_printer;struct xe_gt ;void xe_gt_sriov_pf_monitor_flr (struct xe_gt *gt,u32 vfid); -void xe_gt_sriov_pf_monitor_print_events (struct xe_gt *gt,struct drm_printer *p); +int xe_gt_sriov_pf_monitor_print_events (struct xe_gt *gt,struct drm_printer *p);#ifdef CONFIG_PCI_IOV int xe_gt_sriov_pf_monitor_process_guc2pf (struct xe_gt *gt,const u32 *msg,u32 len);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 362/461 drm/xe: Consolidate workaround entries for Wa_14019988906
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Roper <[email protected]>
[ Upstream commit c2142a1a841525d897ef69b3e6a5ab48183e1fcf ]
Wa_14019988906 applies to all graphics versions from 20.01 through 20.04 (inclusive). Consolidate the RTP entries into a single range-based entry.
Stable-dep-of: a4660bd94973 ("drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN1")
--- drivers/gpu/drm/xe/xe_wa.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
drivers/gpu/drm/xe/xe_wa.c +4 -8
@@ -716,6 +716,10 @@ static const struct xe_rtp_entry_sr lrc_was[] = {XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2004 ),ENGINE_CLASS (RENDER )),XE_RTP_ACTIONS (SET (VF_SCRATCHPAD ,XE2_VFG_TED_CREDIT_INTERFACE_DISABLE )) }, + { XE_RTP_NAME("14019988906"), +XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2004 ),ENGINE_CLASS (RENDER )), +XE_RTP_ACTIONS (SET (XEHP_PSS_CHICKEN ,FLSH_IGNORES_PSD )) + },/* DG1 */
@@ -772,10 +776,6 @@ static const struct xe_rtp_entry_sr lrc_was[] = {/* Xe2_LPG */ - {XE_RTP_NAME ("14019988906" ), -XE_RTP_RULES (GRAPHICS_VERSION (2004 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (XEHP_PSS_CHICKEN ,FLSH_IGNORES_PSD )) - }, {XE_RTP_NAME ("18033852989" ),XE_RTP_RULES (GRAPHICS_VERSION (2004 ),ENGINE_CLASS (RENDER )),XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN1 ,DISABLE_BOTTOM_CLIP_RECTANGLE_TEST ))
@@ -810,10 +810,6 @@ static const struct xe_rtp_entry_sr lrc_was[] = {XE_RTP_RULES (GRAPHICS_VERSION (2001 ),ENGINE_CLASS (RENDER )),XE_RTP_ACTIONS (SET (WM_CHICKEN3 ,HIZ_PLANE_COMPRESSION_DIS )) }, - { XE_RTP_NAME("14019988906"), -XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2002 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (XEHP_PSS_CHICKEN ,FLSH_IGNORES_PSD )) - }, { XE_RTP_NAME("14021490052"),XE_RTP_RULES (GRAPHICS_VERSION (2001 ),ENGINE_CLASS (RENDER )), XE_RTP_ACTIONS(SET(FF_MODE,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 363/461 drm/xe: Consolidate workaround entries for Wa_18033852989
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Roper <[email protected]>
[ Upstream commit fe681e7b44d78fd77d79de21eca58c3b6bdcda0e ]
Wa_18033852989 applies to all graphics versions from 20.01 through 20.04 (inclusive). Consolidate the RTP entries into a single range-based entry.
Stable-dep-of: a4660bd94973 ("drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN1")
--- drivers/gpu/drm/xe/xe_wa.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
drivers/gpu/drm/xe/xe_wa.c +4 -8
@@ -720,6 +720,10 @@ static const struct xe_rtp_entry_sr lrc_was[] = {XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2004 ),ENGINE_CLASS (RENDER )),XE_RTP_ACTIONS (SET (XEHP_PSS_CHICKEN ,FLSH_IGNORES_PSD )) }, + { XE_RTP_NAME("18033852989"), +XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2004 ),ENGINE_CLASS (RENDER )), +XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN1 ,DISABLE_BOTTOM_CLIP_RECTANGLE_TEST )) + },/* DG1 */
@@ -776,10 +780,6 @@ static const struct xe_rtp_entry_sr lrc_was[] = {/* Xe2_LPG */ - {XE_RTP_NAME ("18033852989" ), -XE_RTP_RULES (GRAPHICS_VERSION (2004 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN1 ,DISABLE_BOTTOM_CLIP_RECTANGLE_TEST )) - }, {XE_RTP_NAME ("14021567978" ),XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,XE_RTP_END_VERSION_UNDEFINED ), ENGINE_CLASS(RENDER)),
@@ -827,10 +827,6 @@ static const struct xe_rtp_entry_sr lrc_was[] = {XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2002 ),ENGINE_CLASS (RENDER )),XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN4 ,SBE_PUSH_CONSTANT_BEHIND_FIX_ENABLE )) }, - { XE_RTP_NAME("18033852989"), -XE_RTP_RULES (GRAPHICS_VERSION (2001 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN1 ,DISABLE_BOTTOM_CLIP_RECTANGLE_TEST )) - },/* Xe3_LPG */ { XE_RTP_NAME("14021490052"),
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 364/461 drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN1
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo Sousa <[email protected]>
[ Upstream commit a4660bd949733fd6ea621fdb50fabac2608155e9 ]
The register COMMON_SLICE_CHICKEN1 is a MCR register on Xe2. Let's make sure to define a MCR version of it and use it for the relevant IP versions.
Use XEHP_ as prefix for the register name, since it is MCR as of Xe_HP.
Bspec: 66534, 71185
--- drivers/gpu/drm/xe/regs/xe_gt_regs.h | 1 + drivers/gpu/drm/xe/xe_wa.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/xe/regs/xe_gt_regs.h +1 -0
@@ -145,6 +145,7 @@#define MSAA_OPTIMIZATION_REDUC_DISABLE REG_BIT(11)#define COMMON_SLICE_CHICKEN1 XE_REG(0x7010, XE_REG_OPTION_MASKED) +#define XEHP_COMMON_SLICE_CHICKEN1 XE_REG_MCR(0x7010, XE_REG_OPTION_MASKED)#define DISABLE_BOTTOM_CLIP_RECTANGLE_TEST REG_BIT(14)#define HIZ_CHICKEN XE_REG(0x7018, XE_REG_OPTION_MASKED)
drivers/gpu/drm/xe/xe_wa.c +1 -1
@@ -722,7 +722,7 @@ static const struct xe_rtp_entry_sr lrc_was[] = { }, {XE_RTP_NAME ("18033852989" ),XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2004 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN1 ,DISABLE_BOTTOM_CLIP_RECTANGLE_TEST )) +XE_RTP_ACTIONS (SET (XEHP_COMMON_SLICE_CHICKEN1 ,DISABLE_BOTTOM_CLIP_RECTANGLE_TEST )) },/* DG1 */
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 365/461 drm/xe/tuning: Apply windower hardware filtering setting on Xe3 and Xe3p
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Roper <[email protected]>
[ Upstream commit 8ccf5f6b2295164962bbee5b0770f4366fd9bee2 ]
A recent bspec tuning guide update asks us to program COMMON_SLICE_CHICKEN4[5] on Xe3 and Xe3p platforms. Add this setting to our LRC tuning RTP table so that the setting will become part of each context's LRC.
Bspec: 72161, 55902
Stable-dep-of: 6df5678b6a94 ("drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4")
--- drivers/gpu/drm/xe/regs/xe_gt_regs.h | 1 + drivers/gpu/drm/xe/xe_tuning.c | 5 +++++ 2 files changed, 6 insertions(+)
drivers/gpu/drm/xe/regs/xe_gt_regs.h +1 -0
@@ -170,6 +170,7 @@#define COMMON_SLICE_CHICKEN4 XE_REG(0x7300, XE_REG_OPTION_MASKED)#define SBE_PUSH_CONSTANT_BEHIND_FIX_ENABLE REG_BIT(12)#define DISABLE_TDC_LOAD_BALANCING_CALC REG_BIT(6) +#define HW_FILTERING REG_BIT(5)#define COMMON_SLICE_CHICKEN3 XE_REG(0x7304, XE_REG_OPTION_MASKED)#define XEHP_COMMON_SLICE_CHICKEN3 XE_REG_MCR(0x7304, XE_REG_OPTION_MASKED)
drivers/gpu/drm/xe/xe_tuning.c +5 -0
@@ -110,6 +110,11 @@ static const struct xe_rtp_entry_sr engine_tunings[] = { };static const struct xe_rtp_entry_sr lrc_tunings[] = { + {XE_RTP_NAME ("Tuning: Windower HW Filtering" ), +XE_RTP_RULES (GRAPHICS_VERSION_RANGE (3000 ,3599 ),ENGINE_CLASS (RENDER )), +XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN4 ,HW_FILTERING )) + }, +/* DG2 */ {XE_RTP_NAME ("Tuning: L3 cache" ),
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 366/461 drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo Sousa <[email protected]>
[ Upstream commit 6df5678b6a94ac80e31e847074c4b30c21025b1f ]
The register COMMON_SLICE_CHICKEN4 is a MCR register on both Xe2 and Xe3. Let's make sure to define a MCR version of it and use it for the relevant IP versions.
Use XEHP_ as prefix for the register name, since it is MCR as of Xe_HP.
v2:
- Also change for one entry in lrc_tunnings, which was caught by manual testing and add corresponging Fixes tag in commit message. (Gustavo)
Bspec: 66534, 71185, 74417
--- drivers/gpu/drm/xe/regs/xe_gt_regs.h | 1 + drivers/gpu/drm/xe/xe_tuning.c | 2 +- drivers/gpu/drm/xe/xe_wa.c | 4 ++-- 3 files changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/xe/regs/xe_gt_regs.h +1 -0
@@ -168,6 +168,7 @@#define XEHPG_SC_INSTDONE_EXTRA2 XE_REG_MCR(0x7108)#define COMMON_SLICE_CHICKEN4 XE_REG(0x7300, XE_REG_OPTION_MASKED) +#define XEHP_COMMON_SLICE_CHICKEN4 XE_REG_MCR(0x7300, XE_REG_OPTION_MASKED)#define SBE_PUSH_CONSTANT_BEHIND_FIX_ENABLE REG_BIT(12)#define DISABLE_TDC_LOAD_BALANCING_CALC REG_BIT(6)#define HW_FILTERING REG_BIT(5)
drivers/gpu/drm/xe/xe_tuning.c +1 -1
@@ -112,7 +112,7 @@ static const struct xe_rtp_entry_sr engine_tunings[] = {static const struct xe_rtp_entry_sr lrc_tunings[] = { {XE_RTP_NAME ("Tuning: Windower HW Filtering" ),XE_RTP_RULES (GRAPHICS_VERSION_RANGE (3000 ,3599 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN4 ,HW_FILTERING )) +XE_RTP_ACTIONS (SET (XEHP_COMMON_SLICE_CHICKEN4 ,HW_FILTERING )) },/* DG2 */
drivers/gpu/drm/xe/xe_wa.c +2 -2
@@ -825,7 +825,7 @@ static const struct xe_rtp_entry_sr lrc_was[] = { }, {XE_RTP_NAME ("22021007897" ),XE_RTP_RULES (GRAPHICS_VERSION_RANGE (2001 ,2002 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN4 ,SBE_PUSH_CONSTANT_BEHIND_FIX_ENABLE )) +XE_RTP_ACTIONS (SET (XEHP_COMMON_SLICE_CHICKEN4 ,SBE_PUSH_CONSTANT_BEHIND_FIX_ENABLE )) },/* Xe3_LPG */
@@ -841,7 +841,7 @@ static const struct xe_rtp_entry_sr lrc_was[] = { }, {XE_RTP_NAME ("22021007897" ),XE_RTP_RULES (GRAPHICS_VERSION_RANGE (3000 ,3005 ),ENGINE_CLASS (RENDER )), -XE_RTP_ACTIONS (SET (COMMON_SLICE_CHICKEN4 ,SBE_PUSH_CONSTANT_BEHIND_FIX_ENABLE )) +XE_RTP_ACTIONS (SET (XEHP_COMMON_SLICE_CHICKEN4 ,SBE_PUSH_CONSTANT_BEHIND_FIX_ENABLE )) }, { XE_RTP_NAME("14024681466"), XE_RTP_RULES(GRAPHICS_VERSION_RANGE(3000, 3005), ENGINE_CLASS(RENDER)),
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 367/461 wifi: ath11k: fix peer resolution on rx path when peer_id=0
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Leach <[email protected]>
[ Upstream commit 2a2451a34afdf563b3102d36a4b6cf335cf813e2 ]
It has been observed that on certain chipsets a peer can be assigned peer_id=0. For reception of non-aggregated MPDUs this is fine as ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer based upon the source MAC address. On an aggregated link, the mpdu_start header is only populated by hardware on the first sub-MSDU. This causes the peer resolution to be skipped for the subsequent MSDUs and the encryption type of these frames to be set to an incorrect value, resulting in these MSDUs being dropped by ieee80211.
ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0 ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID of 0 to be resolved.
Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
--- drivers/net/wireless/ath/ath11k/dp_rx.c | 3 +-- drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +---- 2 files changed, 2 insertions(+), 6 deletions(-)
drivers/net/wireless/ath/ath11k/dp_rx.c +1 -2
@@ -2214,8 +2214,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)lockdep_assert_held (&ab->base_lock); -if (rxcb->peer_id) - peer =ath11k_peer_find_by_id (ab, rxcb->peer_id); + peer =ath11k_peer_find_by_id (ab, rxcb->peer_id);if (peer)return peer;
drivers/net/wireless/ath/ath11k/hal_rx.c +1 -4
@@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,case HAL_RX_MPDU_START : {struct hal_rx_mpdu_info *mpdu_info = (struct hal_rx_mpdu_info *)tlv_data; -u16 peer_id; - peer_id =ath11k_hal_rx_mpduinfo_get_peerid (ab, mpdu_info); -if (peer_id) - ppdu_info->peer_id = peer_id; + ppdu_info->peer_id =ath11k_hal_rx_mpduinfo_get_peerid (ab, mpdu_info);break ; }case HAL_RXPCU_PPDU_END_INFO : {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 368/461 wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baochen Qiang <[email protected]>
[ Upstream commit 60fb2cf51e77bb1c0261160b4be44209d68956b1 ]
When connecting to an AP configured for EHT 20 MHz with a full EHT MCS/NSS map (supporting MCS 0-13)
Supported EHT-MCS and NSS Set
EHT-MCS Map (BW <= 80MHz): 0x444444
.... .... .... .... .... 0100 = Rx Max Nss That Supports EHT-MCS 0-9: 4
.... .... .... .... 0100 .... = Tx Max Nss That Supports EHT-MCS 0-9: 4
.... .... .... 0100 .... .... = Rx Max Nss That Supports EHT-MCS 10-11: 4
.... .... 0100 .... .... .... = Tx Max Nss That Supports EHT-MCS 10-11: 4
.... 0100 .... .... .... .... = Rx Max Nss That Supports EHT-MCS 12-13: 4
0100 .... .... .... .... .... = Tx Max Nss That Supports EHT-MCS 12-13: 4TX throughput is observed to be significantly lower than expected. Investigation shows that TX rates are limited to EHT MCS 11, even though the AP advertises support for EHT MCS 12/13.
The root cause is an incorrect parsing of the Supported EHT-MCS and NSS Set element in ath12k_peer_assoc_h_eht().
IEEE Std 802.11be-2024 Figure 9-1074as describes the format for 20 MHz-Only Non-AP STAs.
IEEE Std 802.11be-2024 Figure 9-1074at describes the format for all other AP and non-AP STAs.
Currently the first format is parsed when the peer advertises no wider HE channel width support, without considering whether it is an AP or a non-AP STA. This is incorrect: the peer AP's capabilities must be parsed using Figure 9-1074at even when it operates on 20 MHz only. Parsing it as Figure 9-1074as causes rx_tx_mcs13_max_nss to be interpreted as zero, which is then passed to firmware, leading firmware to assume the peer does not support MCS 13 and to limit TX rates at MCS 11.
Fix this by parsing the Figure 9-1074as format only when the peer is a 20 MHz-Only non-AP STA, i.e. when the local interface operates as AP or mesh point.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
--- drivers/net/wireless/ath/ath12k/mac.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/net/wireless/ath/ath12k/mac.c +6 -2
@@ -3446,7 +3446,9 @@ static void ath12k_peer_assoc_h_eht(struct ath12k *ar, arg->peer_eht_mcs_count++; fallthrough;default : -if (!(link_sta->he_cap.he_cap_elem.phy_cap_info[0 ] & +if ((vif->type ==NL80211_IFTYPE_AP || + vif->type ==NL80211_IFTYPE_MESH_POINT ) && + !(link_sta->he_cap.he_cap_elem.phy_cap_info[0 ] &IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_MASK_ALL )) { bw_20 = &eht_cap->eht_mcs_nss_supp.only_20mhz;
@@ -3475,7 +3477,9 @@ static void ath12k_peer_assoc_h_eht(struct ath12k *ar, arg->punct_bitmap = ~arvif->punct_bitmap; arg->eht_disable_mcs15 = link_conf->eht_disable_mcs15; -if (!(link_sta->he_cap.he_cap_elem.phy_cap_info[0 ] & +if ((vif->type ==NL80211_IFTYPE_AP || + vif->type ==NL80211_IFTYPE_MESH_POINT ) && + !(link_sta->he_cap.he_cap_elem.phy_cap_info[0 ] &IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_MASK_ALL )) {if (bw_20->rx_tx_mcs13_max_nss) max_nss = max(max_nss, u8_get_bits(bw_20->rx_tx_mcs13_max_nss,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 369/461 drm/mediatek: mtk_hdmi_ddc_v2: Fix non-static global variable
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Louis-Alexis Eyraud <[email protected]>
[ Upstream commit e9f5e8da29762df1111a58ae0b4a83091595d834 ]
The struct 'mtk_hdmi_ddc_v2_driver' is not used outside of the mtk_hdmi_ddc_v2.c file, so make it static to silence sparse warning:
``` drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c:392:24: sparse: warning: symbol 'mtk_hdmi_ddc_v2_driver' was not declared. Should it be static? ```
--- drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c +1 -1
@@ -389,7 +389,7 @@ static const struct of_device_id mtk_hdmi_ddc_v2_match[] = { };MODULE_DEVICE_TABLE (of, mtk_hdmi_ddc_v2_match); -struct platform_driver mtk_hdmi_ddc_v2_driver = { +static struct platform_driver mtk_hdmi_ddc_v2_driver = { .probe = mtk_hdmi_ddc_v2_probe, .driver = { .name ="mediatek-hdmi-ddc-v2" ,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 370/461 drm/mediatek: mtk_hdmi_v2: Fix non-static global variable
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Louis-Alexis Eyraud <[email protected]>
[ Upstream commit dc245d9a7f1b06f86271d4e524d6e5634c5ce312 ]
The struct 'mtk_hdmi_v2_clk_names' is not used outside of the mtk_hdmi_v2.c file, so make it static to silence sparse warning:
``` drivers/gpu/drm/mediatek/mtk_hdmi_v2.c:53:12: sparse: warning: symbol 'mtk_hdmi_v2_clk_names' was not declared. Should it be static? ```
--- drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/mediatek/mtk_hdmi_v2.c +1 -1
@@ -50,7 +50,7 @@ enum mtk_hdmi_v2_clk_id { MTK_HDMI_V2_CLK_COUNT, }; -const char *const mtk_hdmi_v2_clk_names[MTK_HDMI_V2_CLK_COUNT ] = { +static const char *const mtk_hdmi_v2_clk_names[MTK_HDMI_V2_CLK_COUNT ] = { [MTK_HDMI_V2_CLK_HDMI_APB_SEL ] ="bus" , [MTK_HDMI_V2_CLK_HDCP_SEL ] ="hdcp" , [MTK_HDMI_V2_CLK_HDCP_24M_SEL ] ="hdcp24m" ,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 371/461 drm/mediatek: mtk_cec: Fix non-static global variable
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Louis-Alexis Eyraud <[email protected]>
[ Upstream commit 571f00a5fb725984049bd532ee8193cc34ff2994 ]
The struct 'mtk_cec_driver' is not used outside of the mtk_cec.c file, so make it static to silence sparse warning:
``` drivers/gpu/drm/mediatek/mtk_cec.c:243:24: sparse: warning: symbol 'mtk_cec_driver' was not declared. Should it be static? ```
--- drivers/gpu/drm/mediatek/mtk_cec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/mediatek/mtk_cec.c +1 -1
@@ -240,7 +240,7 @@ static const struct of_device_id mtk_cec_of_ids[] = { };MODULE_DEVICE_TABLE (of, mtk_cec_of_ids); -struct platform_driver mtk_cec_driver = { +static struct platform_driver mtk_cec_driver = { .probe = mtk_cec_probe, .remove = mtk_cec_remove, .driver = {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 372/461 drm/mediatek: mtk_hdmi_ddc: Fix non-static global variable
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Louis-Alexis Eyraud <[email protected]>
[ Upstream commit 87ed4e845d5a90bba1a56c0a5c580a13982e8648 ]
The struct 'mtk_hdmi_ddc_driver' is not used outside of the mtk_hdmi_ddc.c file, so make it static to silence sparse warning:
``` drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c:331:24: sparse: warning: symbol 'mtk_hdmi_ddc_driver' was not declared. Should it be static? ```
--- drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c +1 -1
@@ -328,7 +328,7 @@ static const struct of_device_id mtk_hdmi_ddc_match[] = { };MODULE_DEVICE_TABLE (of, mtk_hdmi_ddc_match); -struct platform_driver mtk_hdmi_ddc_driver = { +static struct platform_driver mtk_hdmi_ddc_driver = { .probe = mtk_hdmi_ddc_probe, .remove = mtk_hdmi_ddc_remove, .driver = {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 373/461 io_uring: propagate array_index_nospec opcode into req->opcode
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Bommarito <[email protected]>
[ Upstream commit cf18e36455603d65d4745de83e2d1743c54ada47 ]
Commit 1e988c3fe126 ("io_uring: prevent opcode speculation") added array_index_nospec() to io_init_req(), but applied it only to a local opcode variable. req->opcode is initialized from sqe->opcode before the bounds check and remains the raw value.
Keep req->opcode as the canonical opcode in io_init_req(): reject out-of-range values architecturally, then write the array_index_nospec() result back to req->opcode before any table lookup. This keeps downstream users of req->opcode from observing the raw user byte on a mispredicted path.
No functional change: array_index_nospec() is a no-op for opcodes in [0, IORING_OP_LAST), and out-of-range opcodes are still rejected at the bounds check above the assignment.
--- io_uring/io_uring.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
io_uring/io_uring.c +4 -5
@@ -1719,10 +1719,9 @@ static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,const struct io_issue_def *def;unsigned int sqe_flags;int personality; -u8 opcode; req->ctx = ctx; - req->opcode = opcode =READ_ONCE (sqe->opcode); + req->opcode =READ_ONCE (sqe->opcode);/* same numerical values with corresponding REQ_F_*, safe to copy */ sqe_flags =READ_ONCE (sqe->flags); req->flags = (__force io_req_flags_t ) sqe_flags;
@@ -1732,13 +1731,13 @@ static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req, req->cancel_seq_set = false; req->async_data =NULL ; -if (unlikely (opcode >=IORING_OP_LAST )) { +if (unlikely (req->opcode >=IORING_OP_LAST )) { req->opcode =0 ;return io_init_fail_req (req, -EINVAL ); } - opcode =array_index_nospec (opcode,IORING_OP_LAST ); + req->opcode =array_index_nospec (req->opcode,IORING_OP_LAST ); - def = &io_issue_defs[opcode]; + def = &io_issue_defs[req->opcode];if (def->is_128 && !(ctx->flags &IORING_SETUP_SQE128 )) {/* * A 128b op on a non-128b SQ requires mixed SQE support as
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 374/461 srcu: Dont queue workqueue handlers to never-online CPUs
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul E. McKenney <[email protected]>
[ Upstream commit 593889c401426004bd0ea0f6d4fcece728b03420 ]
While an srcu_struct structure is in the midst of switching from CPU-0 to all-CPUs state, it can attempt to invoke callbacks for CPUs that have never been online. Worse yet, it can attempt in invoke callbacks for CPUs that never will be online, even including imaginary CPUs not in cpu_possible_mask. This can cause hangs on s390, which is not set up to deal with workqueue handlers being scheduled on such CPUs. This commit therefore causes Tree SRCU to refrain from queueing workqueue handlers on CPUs that have not yet (and might never) come online.
Because callbacks are not invoked on CPUs that have not been online, it is an error to invoke call_srcu(), synchronize_srcu(), or synchronize_srcu_expedited() on a CPU that is not yet fully online. However, it turns out to be less code to redirect the callbacks from too-early invocations of call_srcu() than to warn about such invocations. This commit therefore also redirects callbacks queued on not-yet-fully-online CPUs to the boot CPU.
--- kernel/rcu/srcutree.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
kernel/rcu/srcutree.c +6 -6
@@ -897,11 +897,9 @@ static void srcu_schedule_cbs_snp(struct srcu_struct *ssp, struct srcu_node *snp {int cpu; -for (cpu = snp->grplo; cpu <= snp->grphi; cpu++) { -if (!(mask & (1UL << (cpu - snp->grplo)))) -continue ; -srcu_schedule_cbs_sdp (per_cpu_ptr (ssp->sda, cpu), delay); - } +for (cpu = snp->grplo; cpu <= snp->grphi; cpu++) +if ((mask & (1UL << (cpu - snp->grplo))) &&rcu_cpu_beenfullyonline (cpu)) +srcu_schedule_cbs_sdp (per_cpu_ptr (ssp->sda, cpu), delay); }/*
@@ -1322,7 +1320,9 @@ static unsigned long srcu_gp_start_if_needed(struct srcu_struct *ssp,*/ idx =__srcu_read_lock_nmisafe (ssp); ss_state =smp_load_acquire (&ssp->srcu_sup->srcu_size_state); -if (ss_state <SRCU_SIZE_WAIT_CALL ) +// If !rcu_cpu_beenfullyonline(), interrupts are still disabled, +// so no migration is possible in either direction from this CPU. +if (ss_state <SRCU_SIZE_WAIT_CALL || !rcu_cpu_beenfullyonline (raw_smp_processor_id ())) sdp =per_cpu_ptr (ssp->sda,get_boot_cpu_id ());else sdp =raw_cpu_ptr (ssp->sda);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 375/461 cgroup/rstat: validate cpu before css_rstat_cpu() access
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qing Ming <[email protected]>
[ Upstream commit 8817005efbdfdf5d4e4814cb5dc52b53d12917d7 ]
css_rstat_updated() is exposed as a BPF kfunc and accepts a caller-provided cpu argument. The function uses cpu for per-cpu rstat lookups without checking whether it refers to a valid possible CPU.
A BPF iter/cgroup program with CAP_BPF and CAP_PERFMON can pass an invalid cpu value. On an unfixed UBSCAN_BOUNDS test kernel, cpu == 0x7fffffff triggers:
UBSAN: array-index-out-of-bounds in kernel/cgroup/rstat.c:31:9
index 2147483647 is out of range for type 'long unsigned int [64]'
Call Trace:
css_rstat_updated
bpf_iter_run_prog
cgroup_iter_seq_show
bpf_seq_readAdd cpu validation to the BPF-facing css_rstat_updated() kfunc and move the common implementation to __css_rstat_updated() for in-kernel callers.
--- block/blk-cgroup.c | 2 +- include/linux/cgroup.h | 1 + kernel/cgroup/rstat.c | 30 ++++++++++++++++++++---------- mm/memcontrol.c | 6 +++--- 4 files changed, 25 insertions(+), 14 deletions(-)
block/blk-cgroup.c +1 -1
@@ -2241,7 +2241,7 @@ void blk_cgroup_bio_start(struct bio *bio) }u64_stats_update_end_irqrestore (&bis->sync, flags); -css_rstat_updated (&blkcg->css, cpu); +__css_rstat_updated (&blkcg->css, cpu);put_cpu (); }
include/linux/cgroup.h +1 -0
@@ -715,6 +715,7 @@ static inline void cgroup_path_from_kernfs_id(u64 id, char *buf, size_t buflen)/* * cgroup scalable recursive statistics. */ +void __css_rstat_updated (struct cgroup_subsys_state *css,int cpu);void css_rstat_updated (struct cgroup_subsys_state *css,int cpu);void css_rstat_flush (struct cgroup_subsys_state *css);
kernel/cgroup/rstat.c +20 -10
@@ -1,6 +1,7 @@// SPDX-License-Identifier: GPL-2.0-only #include "cgroup-internal.h" +#include <linux/cpumask.h> #include <linux/sched/cputime.h> #include <linux/bpf.h>
@@ -53,7 +54,7 @@ static inline struct llist_head *ss_lhead_cpu(struct cgroup_subsys *ss, int cpu) }/** -* css_rstat_updated - keep track of updated rstat_cpu +* __css_rstat_updated - keep track of updated rstat_cpu * @css: target cgroup subsystem state * @cpu: cpu on which rstat_cpu was updated *
@@ -63,20 +64,17 @@ static inline struct llist_head *ss_lhead_cpu(struct cgroup_subsys *ss, int cpu)* * NOTE: if the user needs the guarantee that the updater either add itself in * the lockless list or the concurrent flusher flushes its updated stats, a -* memory barrier is needed before the call to css_rstat_updated() i.e. a +* memory barrier is needed before the call to __css_rstat_updated() i.e. a * barrier after updating the per-cpu stats and before calling -* css_rstat_updated(). +* __css_rstat_updated(). */ -__bpf_kfunc void css_rstat_updated(struct cgroup_subsys_state *css, int cpu) +void __css_rstat_updated (struct cgroup_subsys_state *css,int cpu) {struct llist_head *lhead;struct css_rstat_cpu *rstatc;struct llist_node *self; -/* -* Since bpf programs can call this function, prevent access to -* uninitialized rstat pointers. -*/ +/* Prevent access to uninitialized rstat pointers. */ if (!css_uses_rstat (css))return ;
@@ -125,6 +123,18 @@ __bpf_kfunc void css_rstat_updated(struct cgroup_subsys_state *css, int cpu)llist_add (&rstatc->lnode, lhead); } +/* +* BPF-facing wrapper for __css_rstat_updated(). Validate the caller-provided +* CPU before passing it to the internal rstat updater. +*/ +__bpf_kfunc void css_rstat_updated(struct cgroup_subsys_state *css, int cpu) +{ +if (unlikely (cpu <0 || cpu >= nr_cpu_ids || !cpu_possible (cpu))) +return ; + +__css_rstat_updated (css, cpu); +} +static void __css_process_update_tree (struct cgroup_subsys_state *css,int cpu) {/* put @css and all ancestors on the corresponding updated lists */
@@ -170,7 +180,7 @@ static void css_process_update_tree(struct cgroup_subsys *ss, int cpu)* flusher flush the stats updated by the updater who have * observed that they are already on the list. The * corresponding barrier pair for this one should be before -* css_rstat_updated() by the user. +* __css_rstat_updated() by the user. * * For now, there aren't any such user, so not adding the * barrier here but if such a use-case arise, please add
@@ -614,7 +624,7 @@ static void cgroup_base_stat_cputime_account_end(struct cgroup *cgrp, unsigned long flags) {u64_stats_update_end_irqrestore (&rstatbc->bsync, flags); -css_rstat_updated (&cgrp->self,smp_processor_id ()); +__css_rstat_updated (&cgrp->self,smp_processor_id ());put_cpu_ptr (rstatbc); }
mm/memcontrol.c +3 -3
@@ -574,7 +574,7 @@ static inline void memcg_rstat_updated(struct mem_cgroup *memcg, int val,if (!val)return ; -css_rstat_updated (&memcg->css, cpu); +__css_rstat_updated (&memcg->css, cpu); statc_pcpu = memcg->vmstats_percpu;for (; statc_pcpu; statc_pcpu = statc->parent_pcpu) { statc =this_cpu_ptr (statc_pcpu);
@@ -2583,7 +2583,7 @@ static inline void account_slab_nmi_safe(struct mem_cgroup *memcg,struct mem_cgroup_per_node *pn = memcg->nodeinfo[pgdat->node_id];/* preemption is disabled in_nmi(). */ -css_rstat_updated (&memcg->css,smp_processor_id ()); +__css_rstat_updated (&memcg->css,smp_processor_id ());if (idx ==NR_SLAB_RECLAIMABLE_B )atomic_add (nr, &pn->slab_reclaimable);else
@@ -2807,7 +2807,7 @@ static inline void account_kmem_nmi_safe(struct mem_cgroup *memcg, int val)mod_memcg_state (memcg,MEMCG_KMEM , val); }else {/* preemption is disabled in_nmi(). */ -css_rstat_updated (&memcg->css,smp_processor_id ()); +__css_rstat_updated (&memcg->css,smp_processor_id ());atomic_add (val, &memcg->kmem_stat); } }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 376/461 net/mlx5e: xsk: Fix unlocked writing to ICOSQ
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dragos Tatulea <[email protected]>
[ Upstream commit c326f9c68921e2f14dfcecb2f6b4216313d50248 ]
During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected.
There are 2 such races:
A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napi_complete_done(). At this point the NAPI can be scheduled on a different CPU. Like this:
CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI)
------------------------------- --------------------------------
napi_complete_done() clears SCHED
mlx5e_cq_arm(...)
napi_schedule_prep() sets SCHED
mlx5e_napi_poll()
mlx5e_xsk_alloc_rx_mpwqe()
mlx5e_icosq_sync_lock() // noop
memcpy 640 B UMR body
advance sq->pc by 10
mlx5e_trigger_irq(&c->icosq)
wqe_info[pi] = {NOP, 1}
mlx5e_post_nop() advances sq->pcB) mlx5e_trigger_irq() is called on the ICOSQ when mlx5e_trigger_napi_icosq() is running.
The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked.
This issue was noticed in the wild with the following splat:
netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd
WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...] [...] Call Trace: <IRQ> mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core] __napi_poll+0x30/0x200 ? skb_defer_free_flush+0x9c/0xc0 net_rx_action+0x2fe/0x3f0 handle_softirqs+0xd8/0x340 __irq_exit_rcu+0xbc/0xe0 common_interrupt+0x85/0xa0 </IRQ> <TASK> asm_common_interrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2
--- drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c +1 -1
@@ -252,7 +252,7 @@ int mlx5e_napi_poll(struct napi_struct *napi, int budget)mlx5e_cq_arm (&c->xdpsq->cq);if (unlikely (aff_change && busy_xsk)) { -mlx5e_trigger_irq (&c->icosq); +mlx5e_trigger_napi_async_icosq (c); ch_stats->force_irq++; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 377/461 cifs: Fix undefined variables
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 8cf8b5ae8e093132b0dce0a932af10c9ef077936 ]
Fix a couple of undefined variables introduced by the patch to fix tearing on ->remote_i_size and ->zero_point. For some reason, make W=1 with gcc doesn't give undefined variable warnings (but clang does).
--- fs/smb/client/cifsfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/smb/client/cifsfs.c +3 -3
@@ -1339,7 +1339,7 @@ static loff_t cifs_remap_file_range(struct file *src_file, loff_t off,struct cifsFileInfo *smb_file_src = src_file->private_data;struct cifsFileInfo *smb_file_target = dst_file->private_data;struct cifs_tcon *target_tcon, *src_tcon; -unsigned long long i_size, old_size, new_size, zero_point; +unsigned long long i_size, new_size;unsigned long long destend, fstart, fend;unsigned int xid;int rc;
@@ -1407,7 +1407,7 @@ static loff_t cifs_remap_file_range(struct file *src_file, loff_t off, goto unlock;spin_lock (&target_inode->i_lock); -if (fend > zero_point) +if (fend > target_cifsi->netfs._zero_point)netfs_write_zero_point (target_inode, fend +1 ); i_size = target_inode->i_size;spin_unlock (&target_inode->i_lock);
@@ -1422,7 +1422,7 @@ static loff_t cifs_remap_file_range(struct file *src_file, loff_t off,if (target_tcon->ses->server->ops->duplicate_extents) { rc = target_tcon->ses->server->ops->duplicate_extents (xid, smb_file_src, smb_file_target, off, len, destoff); -if (rc ==0 && new_size > old_size) { +if (rc ==0 && new_size > i_size) {truncate_setsize (target_inode, new_size);fscache_resize_cookie (cifs_inode_cookie (target_inode), new_size);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 378/461 ice: ptp: serialize E825 PHY timer start with PTP lock
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Grzegorz Nitka <[email protected]>
[ Upstream commit 781ff8f2d575a794a2a4f11605288ae06757f5eb ]
ice_start_phy_timer_eth56g() programs TIMETUS registers and issues INIT_INCVAL without holding the global PTP semaphore.
This allows concurrent PTP command paths to interleave with PHY timer start, which can make the sequence fail and leave timer initialization inconsistent.
Take the PTP lock around TIMETUS registers programming and INIT_INCVAL command execution, and make sure the lock is released on all error paths.
Keep the subsequent sync step outside of this critical section, since ice_sync_phy_timer_eth56g() takes the same semaphore internally.
--- drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/ice/ice_ptp_hw.c +13 -2
@@ -2141,16 +2141,23 @@ int ice_start_phy_timer_eth56g(struct ice_hw *hw, u8 port) } incval = (u64 )hi <<32 | lo; +if (!ice_ptp_lock (hw)) { +dev_err (ice_hw_to_dev (hw),"Failed to acquire PTP semaphore\n" ); +return -EBUSY ; + } + err =ice_write_40b_ptp_reg_eth56g (hw, port,PHY_REG_TIMETUS_L , incval);if (err) -return err; + goto err_ptp_unlock; err =ice_ptp_one_port_cmd (hw, port,ICE_PTP_INIT_INCVAL );if (err) -return err; + goto err_ptp_unlock;ice_ptp_exec_tmr_cmd (hw); +ice_ptp_unlock (hw); + err =ice_sync_phy_timer_eth56g (hw, port);if (err)return err;
@@ -2166,6 +2173,10 @@ int ice_start_phy_timer_eth56g(struct ice_hw *hw, u8 port)ice_debug (hw,ICE_DBG_PTP ,"Enabled clock on PHY port %u\n" , port);return 0 ; + +err_ptp_unlock: +ice_ptp_unlock (hw); +return err; }/**
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 379/461 ice: ptp: use primary NAC semaphore on E825
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Grzegorz Nitka <[email protected]>
[ Upstream commit 7b28523546c7e4adbb8436f2986efcfc8382985e ]
For E825 2xNAC configurations, PTP semaphore operations must hit the primary NAC register block so both sides coordinate on the same lock.
Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices") updated other primary-only PTP register accesses to use the primary NAC on non-primary functions, but left ice_ptp_lock() and ice_ptp_unlock() operating on the local NAC. As a result, secondary NAC PTP paths can take a different semaphore than the primary side.
Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock() when the current function is not primary, keeping semaphore operations symmetric and consistent with the rest of the 2xNAC PTP register access path.
--- drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/net/ethernet/intel/ice/ice_ptp_hw.c +9 -0
@@ -5264,9 +5264,13 @@ static void ice_ptp_init_phy_e830(struct ice_ptp_hw *ptp)*/ bool ice_ptp_lock (struct ice_hw *hw) { + struct ice_pf *pf = container_of(hw, struct ice_pf, hw);u32 hw_lock;int i; +if (!ice_is_primary (hw)) + hw =ice_get_primary_hw (pf); +#define MAX_TRIES 15for (i =0 ; i <MAX_TRIES ; i++) {
@@ -5293,6 +5297,11 @@ bool ice_ptp_lock(struct ice_hw *hw)*/ void ice_ptp_unlock (struct ice_hw *hw) { + struct ice_pf *pf = container_of(hw, struct ice_pf, hw); + +if (!ice_is_primary (hw)) + hw =ice_get_primary_hw (pf); +wr32 (hw,PFTSYN_SEM + (PFTSYN_SEM_BYTES * hw->pf_id),0 ); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 380/461 igc: set tx buffer type for SMD frames
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kohei Enju <[email protected]>
[ Upstream commit 5acc641e590e008caaed480ed9ffae47cf7ecbdf ]
Sashiko pointed out that igc_fpe_init_smd_frame() initializes igc_tx_buffer fields for an SMD skb, but does not set the buffer type:
https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp
Since igc_tx_buffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path.
Set the buffer type to IGC_TX_BUFFER_TYPE_SKB.
--- drivers/net/ethernet/intel/igc/igc_tsn.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/intel/igc/igc_tsn.c +1 -0
@@ -34,6 +34,7 @@ static int igc_fpe_init_smd_frame(struct igc_ring *ring,return -ENOMEM ; } + buffer->type =IGC_TX_BUFFER_TYPE_SKB ; buffer->skb = skb; buffer->protocol =0 ; buffer->bytecount = skb->len;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 381/461 drm/i915/dp: Fix readback for target_rr in Adaptive Sync SDP
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ankit Nautiyal <[email protected]>
[ Upstream commit f87abd0c6604fb6cc31cc86fc7ccc6a576924352 ]
Correct the bit-shift logic to properly readback the 10 bit target_rr from DB3 and DB4.
v2: Align the style with readback for vtotal. (Ville)
--- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/display/intel_dp.c +1 -1
@@ -5067,7 +5067,7 @@ int intel_dp_as_sdp_unpack(struct drm_dp_as_sdp *as_sdp, as_sdp->length = sdp->sdp_header.HB3 &DP_ADAPTIVE_SYNC_SDP_LENGTH ; as_sdp->mode = sdp->db[0 ] &DP_ADAPTIVE_SYNC_SDP_OPERATION_MODE ; as_sdp->vtotal = (sdp->db[2 ] <<8 ) | sdp->db[1 ]; - as_sdp->target_rr = (u64 )sdp->db[3 ] | ((u64 )sdp->db[4 ] &0x3 ); + as_sdp->target_rr = ((sdp->db[4 ] &0x3 ) <<8 ) | sdp->db[3 ]; as_sdp->target_rr_divider = sdp->db[4 ] &0x20 ? true : false;return 0 ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 382/461 phy: qcom: qmp-usbc: Fix out-of-bounds array access in dp swing config
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiangxu Yin <[email protected]>
[ Upstream commit ea17fc4d7dc2ba6459b1a318962960520201baf1 ]
swing_tbl and pre_emphasis_tbl are 4x4 arrays (valid indices 0-3), but the boundary check uses "> 4" instead of ">= 4", allowing index 4 to cause an out-of-bounds access.
--- drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c +1 -1
@@ -794,7 +794,7 @@ static int qmp_v2_configure_dp_swing(struct qmp_usbc *qmp) p_level =max (p_level, dp_opts->pre[i]); } -if (v_level >4 || p_level >4 ) { +if (v_level >=4 || p_level >=4 ) {dev_err (qmp->dev,"Invalid v(%d) | p(%d) level)\n" , v_level, p_level);return -EINVAL ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 383/461 kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viktor Jägersküpper <[email protected]>
[ Upstream commit 202550713128da20d9381d6d2dc0f6b73839f434 ]
The package versioning scheme does not enable smooth upgrades from "rc" releases to the corresponding stable releases (e.g. 7.0.0-rc7 -> 7.0.0) because pacman considers that a downgrade due to the underscore in pkgver (e.g. 7.0.0_rc7), see e.g. vercmp(8) for an explanation of the package version comparison used by pacman. Package versions which are derived from said releases (e.g. built from git revisions) are similarly affected. Fix this by modifying pkgver in order to remove the hyphen from kernel versions containing "-rcN", where N is a non-negative integer.
--- scripts/package/PKGBUILD | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/package/PKGBUILD +1 -1
@@ -10,7 +10,7 @@ for pkg in $_extrapackages; do pkgname+=("${pkgbase}-${pkg}") done -pkgver="${KERNELRELEASE//-/_}" +pkgver="$(echo "${KERNELRELEASE}" | sed 's/-\(rc[0-9]\+\)/\1/;s/-/_/g')" # The PKGBUILD is evaluated multiple times. # Running scripts/build-version from here would introduce inconsistencies. pkgrel="${KBUILD_REVISION}"
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 384/461 net: dsa: mt7530: fix FDB entries not aging out with short timeout
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Golle <[email protected]>
[ Upstream commit e824e40d0e841fab66ab7897d6c7b14dc81c66a7 ]
The DSA forwarding selftests bridge_vlan_aware.sh and bridge_vlan_unaware.sh configure the bridge with ageing_time set to LOW_AGEING_TIME (1000 centiseconds, i.e. 10 seconds) and then run learning_test() in lib.sh, which expects a learned FDB entry to be removed after ageing_time + 10 seconds. On MT7530/MT7531 the entry persisted past the deadline and the "Found FDB record when should not" assertion failed.
With msecs=10000, the algorithm in mt7530_set_ageing_time() finds AGE_CNT=0 and AGE_UNIT=9 as the first exact match (starting the search from tmp_age_count=0). The per-entry aging counter is initialized to AGE_CNT when a MAC address is learned, so with AGE_CNT=0 new entries start with a counter value of 0, which the hardware treats as "already aged" and never removes, effectively disabling aging.
Fix this by starting the search from tmp_age_count=1 to ensure entries always have a non-zero initial aging counter. For a 10-second ageing time this yields AGE_CNT=1 and AGE_UNIT=4 instead:
the timer ticks every 5 seconds and entries are removed after 2 ticks.
Starting the search at AGE_CNT=1 raises the minimum representable ageing time from 1 to 2 seconds. Without bounds, a stale ageing_time of 1 second would now make the loop fall through without setting age_count and age_unit, leaving them uninitialized when written to the MT7530_AAC hardware register. Set ds->ageing_time_min and ds->ageing_time_max so the DSA core validates the range before the callback is invoked, and drop the now-redundant range check from mt7530_set_ageing_time().
--- drivers/net/dsa/mt7530.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-)
drivers/net/dsa/mt7530.c +14 -6
@@ -973,12 +973,16 @@ mt7530_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)unsigned int age_count;unsigned int age_unit; -/* Applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds */ -if (secs <1 || secs > (AGE_CNT_MAX +1 ) * (AGE_UNIT_MAX +1 )) -return -ERANGE ; - -/* iterate through all possible age_count to find the closest pair */ -for (tmp_age_count =0 ; tmp_age_count <=AGE_CNT_MAX ; ++tmp_age_count) { +/* Applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds. +* The DSA core has already validated the range using +* ds->ageing_time_min and ds->ageing_time_max. +* +* Iterate through all possible age_count values to find the closest +* pair. Start from 1 because the per-entry aging counter is +* initialized to AGE_CNT and a value of 0 means the entry will +* never be aged out. +*/ +for (tmp_age_count =1 ; tmp_age_count <=AGE_CNT_MAX ; ++tmp_age_count) {unsigned int tmp_age_unit = secs / (tmp_age_count +1 ) -1 ;if (tmp_age_unit <=AGE_UNIT_MAX ) {
@@ -2378,6 +2382,8 @@ mt7530_setup(struct dsa_switch *ds) ds->assisted_learning_on_cpu_port = true; ds->mtu_enforcement_ingress = true; + ds->ageing_time_min =2 *1000 ; + ds->ageing_time_max = (AGE_CNT_MAX +1 ) * (AGE_UNIT_MAX +1 ) *1000 ;if (priv->id ==ID_MT7530 ) {regulator_set_voltage (priv->core_pwr,1000000 ,1000000 );
@@ -2567,6 +2573,8 @@ mt7531_setup_common(struct dsa_switch *ds) ds->assisted_learning_on_cpu_port = true; ds->mtu_enforcement_ingress = true; + ds->ageing_time_min =2 *1000 ; + ds->ageing_time_max = (AGE_CNT_MAX +1 ) * (AGE_UNIT_MAX +1 ) *1000 ;mt753x_trap_frames (priv);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 385/461 net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Golle <[email protected]>
[ Upstream commit 3ac85bcfd404b588298c95c6fba8aad4ad334f57 ]
The BPC, RGAC1 and RGAC2 registers control the handling of link-local frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are correctly trapped to the CPU port, but the egress VLAN tag attribute was set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any VLAN tags from trapped frames before they reach the CPU.
This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer Delay Requests) to arrive at the CPU without their VLAN tag, so they are delivered to the base network interface instead of the VLAN sub-interface. The DSA local_termination selftest confirms this: all link-local protocol tests on VLAN upper interfaces fail.
Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default) so that the switch does not modify VLAN tags in trapped frames. This way VLAN-tagged frames retain their original tag and are delivered to the correct VLAN sub-interface, matching the behavior of non-trapped frames which pass through without VLAN tag modification.
--- drivers/net/dsa/mt7530.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-)
drivers/net/dsa/mt7530.c +15 -12
@@ -1250,37 +1250,40 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)static void mt753x_trap_frames (struct mt7530_priv *priv) { -/* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress them -* VLAN-untagged. +/* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress +* them with the EG_TAG attribute set to disabled (system default) +* so that any VLAN tags in the frame are not modified by the +* switch egress VLAN tag processing. This preserves VLAN tags +* for reception on VLAN sub-interfaces. */ mt7530_rmw (priv,MT753X_BPC ,PAE_BPDU_FR |PAE_EG_TAG_MASK |PAE_PORT_FW_MASK |BPDU_EG_TAG_MASK |BPDU_PORT_FW_MASK , -PAE_BPDU_FR |PAE_EG_TAG (MT7530_VLAN_EG_UNTAGGED ) | +PAE_BPDU_FR |PAE_EG_TAG (MT7530_VLAN_EG_DISABLED ) |PAE_PORT_FW (TO_CPU_FW_CPU_ONLY ) | -BPDU_EG_TAG (MT7530_VLAN_EG_UNTAGGED ) | +BPDU_EG_TAG (MT7530_VLAN_EG_DISABLED ) |TO_CPU_FW_CPU_ONLY ); -/* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and egress -* them VLAN-untagged. +/* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and +* egress them with EG_TAG disabled. */ mt7530_rmw (priv,MT753X_RGAC1 ,R02_BPDU_FR |R02_EG_TAG_MASK |R02_PORT_FW_MASK |R01_BPDU_FR |R01_EG_TAG_MASK |R01_PORT_FW_MASK , -R02_BPDU_FR |R02_EG_TAG (MT7530_VLAN_EG_UNTAGGED ) | +R02_BPDU_FR |R02_EG_TAG (MT7530_VLAN_EG_DISABLED ) |R02_PORT_FW (TO_CPU_FW_CPU_ONLY ) |R01_BPDU_FR | -R01_EG_TAG (MT7530_VLAN_EG_UNTAGGED ) | +R01_EG_TAG (MT7530_VLAN_EG_DISABLED ) |TO_CPU_FW_CPU_ONLY ); -/* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and egress -* them VLAN-untagged. +/* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and +* egress them with EG_TAG disabled. */ mt7530_rmw (priv,MT753X_RGAC2 ,R0E_BPDU_FR |R0E_EG_TAG_MASK |R0E_PORT_FW_MASK |R03_BPDU_FR |R03_EG_TAG_MASK |R03_PORT_FW_MASK , -R0E_BPDU_FR |R0E_EG_TAG (MT7530_VLAN_EG_UNTAGGED ) | +R0E_BPDU_FR |R0E_EG_TAG (MT7530_VLAN_EG_DISABLED ) |R0E_PORT_FW (TO_CPU_FW_CPU_ONLY ) |R03_BPDU_FR | -R03_EG_TAG (MT7530_VLAN_EG_UNTAGGED ) | +R03_EG_TAG (MT7530_VLAN_EG_DISABLED ) |TO_CPU_FW_CPU_ONLY ); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 386/461 net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Erni Sri Satya Vennela <[email protected]>
[ Upstream commit 35f0f0a2536a4d604b4dbad92c85c4a8fdebb870 ]
In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp() re-reads the same field from the same DMA buffer for test_bit() and pointer arithmetic.
DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation.
Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a stack-local variable in mana_hwc_rx_event_handler(), and passing the validated value as a parameter to mana_hwc_handle_resp().
--- .../net/ethernet/microsoft/mana/hw_channel.c | 23 +++++++++++-------- 1 file changed, 13 insertions(+), 10 deletions(-)
drivers/net/ethernet/microsoft/mana/hw_channel.c +13 -10
@@ -77,21 +77,19 @@ static int mana_hwc_post_rx_wqe(const struct hwc_wq *hwc_rxq, }static void mana_hwc_handle_resp (struct hw_channel_context *hwc,u32 resp_len, -struct hwc_work_request *rx_req) +struct hwc_work_request *rx_req,u16 msg_id) {const struct gdma_resp_hdr *resp_msg = rx_req->buf_va;struct hwc_caller_ctx *ctx;int err; -if (!test_bit (resp_msg->response.hwc_msg_id, - hwc->inflight_msg_res.map)) { -dev_err (hwc->dev,"hwc_rx: invalid msg_id = %u\n" , - resp_msg->response.hwc_msg_id); +if (!test_bit (msg_id, hwc->inflight_msg_res.map)) { +dev_err (hwc->dev,"hwc_rx: invalid msg_id = %u\n" , msg_id);mana_hwc_post_rx_wqe (hwc->rxq, rx_req);return ; } - ctx = hwc->caller_ctx + resp_msg->response.hwc_msg_id; + ctx = hwc->caller_ctx + msg_id; err =mana_hwc_verify_resp_msg (ctx, resp_msg, resp_len);if (err) goto out;
@@ -251,6 +249,7 @@ static void mana_hwc_rx_event_handler(void *ctx, u32 gdma_rxq_id,struct gdma_sge *sge;u64 rq_base_addr;u64 rx_req_idx; +u16 msg_id;u8 *wqe;if (WARN_ON_ONCE (hwc_rxq->gdma_wq->id != gdma_rxq_id))
@@ -269,13 +268,17 @@ static void mana_hwc_rx_event_handler(void *ctx, u32 gdma_rxq_id, rx_req = &hwc_rxq->msg_buf->reqs[rx_req_idx]; resp = (struct gdma_resp_hdr *)rx_req->buf_va; -if (resp->response.hwc_msg_id >= hwc->num_inflight_msg) { -dev_err (hwc->dev,"HWC RX: wrong msg_id=%u\n" , - resp->response.hwc_msg_id); +/* Read msg_id once from DMA buffer to prevent TOCTOU: +* DMA memory is shared/unencrypted in CVMs - host can +* modify it between reads. +*/ + msg_id =READ_ONCE (resp->response.hwc_msg_id); +if (msg_id >= hwc->num_inflight_msg) { +dev_err (hwc->dev,"HWC RX: wrong msg_id=%u\n" , msg_id);return ; } -mana_hwc_handle_resp (hwc, rx_oob->tx_oob_data_size, rx_req); +mana_hwc_handle_resp (hwc, rx_oob->tx_oob_data_size, rx_req, msg_id);/* Can no longer use 'resp', because the buffer is posted to the HW * in mana_hwc_handle_resp() above.
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 387/461 platform/surface: aggregator_registry: omit battery & AC nodes on Surface Laptop 7
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver White <[email protected]>
[ Upstream commit 0488073a6c84571dd3cffe581a4a73a5fceb099d ]
Surface Laptop 7 exposes battery and AC status via Qualcomm PMIC GLINK qcom_battmgr. Registering the standard SSAM battery and AC client devices on this platform causes duplicate power-supply devices to appear.
Drop the SSAM battery and AC nodes from the Surface Laptop 7 registry group so that only the qcom_battmgr power supplies are instantiated.
--- drivers/platform/surface/surface_aggregator_registry.c | 2 -- 1 file changed, 2 deletions(-)
drivers/platform/surface/surface_aggregator_registry.c +0 -2
@@ -295,8 +295,6 @@ static const struct software_node *ssam_node_group_sl6[] = {/* Devices for Surface Laptop 7. */ static const struct software_node *ssam_node_group_sl7[] = { &ssam_node_root, - &ssam_node_bat_ac, - &ssam_node_bat_main, &ssam_node_tmp_perf_profile_with_fan, &ssam_node_fan_speed, &ssam_node_hid_sam_keyboard,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 388/461 platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULL
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit e7a9a6ea40e352cd7977f6a8c80bdeadf65ad838 ]
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 adv_swbutton driver.
--- drivers/platform/x86/adv_swbutton.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/platform/x86/adv_swbutton.c +5 -1
@@ -48,10 +48,14 @@ static int adv_swbutton_probe(struct platform_device *device) {struct adv_swbutton *button;struct input_dev *input; -acpi_handle handle =ACPI_HANDLE (&device->dev); +acpi_handle handle;acpi_status status;int error; + handle =ACPI_HANDLE (&device->dev); +if (!handle) +return -ENODEV ; + button =devm_kzalloc (&device->dev,sizeof (*button),GFP_KERNEL );if (!button)return -ENOMEM ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 389/461 platform/x86: hp_accel: Check ACPI_COMPANION() against NULL
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit abfbe5ee8ae89f1f5449790423d5dd3e423545bd ]
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the platform/x86 hp_accel driver.
--- drivers/platform/x86/hp/hp_accel.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/platform/x86/hp/hp_accel.c +3 -0
@@ -300,6 +300,9 @@ static int lis3lv02d_probe(struct platform_device *device)int ret; lis3_dev.bus_priv =ACPI_COMPANION (&device->dev); +if (!lis3_dev.bus_priv) +return -ENODEV ; + lis3_dev.init = lis3lv02d_acpi_init; lis3_dev.read = lis3lv02d_acpi_read; lis3_dev.write = lis3lv02d_acpi_write;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 390/461 platform/x86: intel-hid: Check ACPI_HANDLE() against NULL
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit 5c69e090ae5dd93d910f70db0796357080707d26 ]
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel-hid driver.
--- drivers/platform/x86/intel/hid.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/platform/x86/intel/hid.c +5 -1
@@ -688,12 +688,16 @@ static bool button_array_present(struct platform_device *device)static int intel_hid_probe (struct platform_device *device) { -acpi_handle handle =ACPI_HANDLE (&device->dev);unsigned long long mode, dummy;struct intel_hid_priv *priv; +acpi_handle handle;acpi_status status;int err; + handle =ACPI_HANDLE (&device->dev); +if (!handle) +return -ENODEV ; +intel_hid_init_dsm (handle);if (!intel_hid_evaluate_method (handle,INTEL_HID_DSM_HDMM_FN , &mode)) {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 391/461 platform/x86: intel_sar: Check ACPI_HANDLE() against NULL
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit 2765f16c12af7c2533763e46b8113b727354012d ]
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel_sar driver.
--- drivers/platform/x86/intel/int1092/intel_sar.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/platform/x86/intel/int1092/intel_sar.c +6 -1
@@ -245,15 +245,20 @@ static void sar_get_data(int reg, struct wwan_sar_context *context)static int sar_probe (struct platform_device *device) {struct wwan_sar_context *context; +acpi_handle handle;int reg;int result; + handle =ACPI_HANDLE (&device->dev); +if (!handle) +return -ENODEV ; + context =kzalloc_obj (*context);if (!context)return -ENOMEM ; context->sar_device = device; - context->handle =ACPI_HANDLE (&device->dev); + context->handle = handle;dev_set_drvdata (&device->dev, context); result =guid_parse (SAR_DSM_UUID , &context->guid);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 392/461 platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULL
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit a9f305c5a355efeb240d406d378491d9eec02d07 ]
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the platform/x86 intel-vbtn driver.
--- drivers/platform/x86/intel/vbtn.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/platform/x86/intel/vbtn.c +5 -1
@@ -275,12 +275,16 @@ static bool intel_vbtn_has_switches(acpi_handle handle, bool dual_accel)static int intel_vbtn_probe (struct platform_device *device) { -acpi_handle handle =ACPI_HANDLE (&device->dev);bool dual_accel, has_buttons, has_switches;struct intel_vbtn_priv *priv; +acpi_handle handle;acpi_status status;int err; + handle =ACPI_HANDLE (&device->dev); +if (!handle) +return -ENODEV ; + dual_accel =dual_accel_detect (); has_buttons =acpi_has_method (handle,"VBDL" ); has_switches =intel_vbtn_has_switches (handle, dual_accel);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 393/461 platform/x86: uniwill-laptop: Properly initialize charging threshold
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
[ Upstream commit c12cc42dadd85dea210d5699d4f21def827382eb ]
The EC might initialize the charge threshold with 0 to signal that said threshold is uninitialized. Detect this and replace said value with 100 to signal the EC that we want to take control of battery charging. Also set the threshold to 100 if the EC-provided value is invalid.
--- drivers/platform/x86/uniwill/uniwill-acpi.c | 35 ++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)
drivers/platform/x86/uniwill/uniwill-acpi.c +34 -1
@@ -1193,6 +1193,16 @@ static int uniwill_led_init(struct uniwill_data *data) &init_data); } +static unsigned int uniwill_sanitize_battery_threshold (unsigned int value) +{ +/* 0 means "charging threshold not active" */ +if (!value) +return 100 ; + +/* Guard against invalid values */ +return min (value,100 ); +} +static int uniwill_get_property (struct power_supply *psy,const struct power_supply_ext *ext,void *drvdata,enum power_supply_property psp,union power_supply_propval *val)
@@ -1239,7 +1249,8 @@ static int uniwill_get_property(struct power_supply *psy, const struct power_supif (ret <0 )return ret; - val->intval =clamp_val (FIELD_GET (CHARGE_CTRL_MASK , regval),0 ,100 ); + regval =FIELD_GET (CHARGE_CTRL_MASK , regval); + val->intval =uniwill_sanitize_battery_threshold (regval);return 0 ;default :return -EINVAL ;
@@ -1334,11 +1345,33 @@ static int uniwill_remove_battery(struct power_supply *battery, struct acpi_battstatic int uniwill_battery_init (struct uniwill_data *data) { +unsigned int value, threshold, sanitized;int ret;if (!uniwill_device_supports (data,UNIWILL_FEATURE_BATTERY ))return 0 ; + ret =regmap_read (data->regmap,EC_ADDR_CHARGE_CTRL , &value); +if (ret <0 ) +return ret; + +/* +* The charge control threshold might be initialized with 0 by +* the EC to signal that said threshold is uninitialized. We thus +* need to replace this placeholder value with a valid one (100) +* to signal that we want to take control of battery charging. +* For the sake of completeness we also apply this to other +* invalid threshold values. +*/ + threshold =FIELD_GET (CHARGE_CTRL_MASK , value); + sanitized =uniwill_sanitize_battery_threshold (threshold); +if (threshold != sanitized) { +FIELD_MODIFY (CHARGE_CTRL_MASK , &value, sanitized); + ret =regmap_write (data->regmap,EC_ADDR_CHARGE_CTRL , value); +if (ret <0 ) +return ret; + } + ret =devm_mutex_init (data->dev, &data->battery_lock);if (ret <0 )return ret;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 394/461 platform/x86: uniwill-laptop: Accept charging threshold of 0
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
[ Upstream commit c16a4823cc60a32b891f7a148bb30c0f51d12cf4 ]
The power supply sysfs ABI states that:
Not all hardware is capable of setting this to an arbitrary percentage. Drivers will round written values to the nearest supported value. Reading back the value will show the actual threshold set by the driver.
The driver currently violates this ABI by rejecting a charging threshold of 0. Fix this by clamping this value to 1.
--- drivers/platform/x86/uniwill/uniwill-acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/platform/x86/uniwill/uniwill-acpi.c +2 -2
@@ -1265,11 +1265,11 @@ static int uniwill_set_property(struct power_supply *psy, const struct power_supswitch (psp) {case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD : -if (val->intval <1 || val->intval >100 ) +if (val->intval <0 || val->intval >100 )return -EINVAL ;return regmap_update_bits (data->regmap,EC_ADDR_CHARGE_CTRL ,CHARGE_CTRL_MASK , - val->intval); +max (val->intval,1 ));default :return -EINVAL ; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 395/461 platform/x86: uniwill-laptop: Fix behavior of "force" module param
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
[ Upstream commit fb4b67c44557cb4cbb15900083d4e1af22320339 ]
Users might want to force-enable all possible features even on machines with a valid device descriptor. Until now the "force" module param was ignored on such machines. Fix this to make it easier to test for support of new features.
--- drivers/platform/x86/uniwill/uniwill-acpi.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/platform/x86/uniwill/uniwill-acpi.c +6 -2
@@ -2189,8 +2189,6 @@ static int __init uniwill_init(void)if (!force)return -ENODEV ; -/* Assume that the device supports all features */ - device_descriptor.features =UINT_MAX ;pr_warn ("Loading on a potentially unsupported device\n" ); }else {/*
@@ -2208,6 +2206,12 @@ static int __init uniwill_init(void) device_descriptor = *descriptor; } +if (force) { +/* Assume that the device supports all features */ + device_descriptor.features =UINT_MAX ; +pr_warn ("Enabling potentially unsupported features\n" ); + } + ret =platform_driver_register (&uniwill_driver);if (ret <0 )return ret;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 396/461 platform/x86: asus-armoury: fix mini-LED mode get/set on MODE2 devices
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ahmed Yaseen <[email protected]>
[ Upstream commit d2d2e7c8fb37b27301ee5c8343b2f7037efc6ea6 ]
The mini-LED current_value attribute does not work on devices that use ASUS_WMI_DEVID_MINI_LED_MODE2 (2024 and newer models).
Reading is broken: mini_led_mode_current_value_show() fetches the mode from the device but then decodes a literal 0 instead of the value it just read:
mode = FIELD_GET(ASUS_MINI_LED_MODE_MASK, 0);
So mode is always 0, and the attribute always reports the same thing regardless of the real hardware state.
Writing is broken too. The number a user writes is an index; the value the firmware actually wants is looked up from that index in mini_led_mode_map[]. mini_led_mode_current_value_store() skips that lookup and passes the raw index straight to armoury_attr_uint_store(). On 2024 devices the firmware numbers its modes differently from the index, so some writes are rejected with -EINVAL and the rest send the wrong mode to the hardware.
Fix both paths: decode the value actually read from the device when reading, and look up the firmware value before sending it when writing. Older (MODE1) devices were unaffected because there the index and the firmware value are the same.
--- drivers/platform/x86/asus-armoury.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
drivers/platform/x86/asus-armoury.c +12 -4
@@ -370,7 +370,7 @@ static ssize_t mini_led_mode_current_value_show(struct kobject *kobj,if (err)return err; - mode =FIELD_GET (ASUS_MINI_LED_MODE_MASK ,0 ); + mode =FIELD_GET (ASUS_MINI_LED_MODE_MASK , mode);for (i =0 ; i < mini_led_mode_map_size; i++)if (mode == mini_led_mode_map[i])
@@ -386,6 +386,7 @@ static ssize_t mini_led_mode_current_value_store(struct kobject *kobj, {u32 *mini_led_mode_map;size_t mini_led_mode_map_size; +char mapped_value[12 ];u32 mode;int err;
@@ -414,9 +415,16 @@ static ssize_t mini_led_mode_current_value_store(struct kobject *kobj,return -ENODEV ; } -return armoury_attr_uint_store (kobj, attr, buf, count, -0 , mini_led_mode_map[mode], -NULL , asus_armoury.mini_led_dev_id); +/* +* armoury_attr_uint_store() parses and sends the value from the +* passed buffer; hand it the mapped firmware value so the device +* receives the translated mode instead of the raw index. +*/ +snprintf (mapped_value,sizeof (mapped_value),"%u" , mini_led_mode_map[mode]); + +return armoury_attr_uint_store (kobj, attr, mapped_value, count,0 , + mini_led_mode_map[mode],NULL , + asus_armoury.mini_led_dev_id); } static ssize_t mini_led_mode_possible_values_show(struct kobject *kobj,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 397/461 ASoC: soc-utils: Add missing va_end in snd_soc_ret()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robertus Diawan Chris <[email protected]>
[ Upstream commit 298a43b54432fbc3a32949a94c72544ee18c8c00 ]
The default case in snd_soc_ret() use va_start without va_end to cleanup "args" object which can cause undefined behavior. So, add missing va_end to cleanup "args" object.
This is reported by Coverity Scan as "Missing varargs init or cleanup".
--- sound/soc/soc-utils.c | 1 + 1 file changed, 1 insertion(+)
sound/soc/soc-utils.c +1 -0
@@ -36,6 +36,7 @@ int snd_soc_ret(const struct device *dev, int ret, const char *fmt, ...) vaf.va = &args;dev_err (dev,"ASoC error (%d): %pV" , ret, &vaf); +va_end (args); }return ret;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 398/461 drm/amdgpu: Align amdgpu_gtt_mgr entries to TLB size on Tahiti (v2)
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Timur Kristóf <[email protected]>
[ Upstream commit 4d798ea0712fddbd35b439cef32b8ac735eb76f9 ]
The TLB is organized in groups of 8 entries, each one is 4K. On Tahiti, the HW requires these GART entries to be 32K-aligned.
This fixes a VCE 1 firmware validation failure that can happen after suspend/resume since we use amdgpu_gtt_mgr for VCE 1.
v2:
- Change variable declaration order
- Add comment about "V bit HW bug"
--- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c +8 -1
@@ -199,11 +199,18 @@ int amdgpu_gtt_mgr_alloc_entries(struct amdgpu_gtt_mgr *mgr, enum drm_mm_insert_mode mode) {struct amdgpu_device *adev =container_of (mgr,typeof (*adev), mman.gtt_mgr); +u32 alignment =0 ;int r; +/* Align to TLB L2 cache entry size to work around "V bit HW bug" */ +if (adev->asic_type ==CHIP_TAHITI ) { + alignment =32 *1024 /AMDGPU_GPU_PAGE_SIZE ; + num_pages =ALIGN (num_pages, alignment); + } +spin_lock (&mgr->lock); r =drm_mm_insert_node_in_range (&mgr->mm, mm_node, num_pages, -0 ,GART_ENTRY_WITHOUT_BO_COLOR ,0 , + alignment,GART_ENTRY_WITHOUT_BO_COLOR ,0 , adev->gmc.gart_size >>PAGE_SHIFT , mode);spin_unlock (&mgr->lock);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 399/461 drm/amdgpu/vce1: Check that the GPU address is < 128 MiB
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Timur Kristóf <[email protected]>
[ Upstream commit 9f907adb66d8369dd45412794a04845011503fa8 ]
When ensuring the low 32-bit address, make sure it is less than 128 MiB, otherwise the VCE seems to fail to initialize. This seems to be an undocumented limitation of the firmware validation mechanism. Note that in case of VCE1 the BAR address is zero and we can't change it also due to the firmware validator.
When programming the mmVCE_VCPU_CACHE_OFFSETn registers, don't AND them with a mask. This is incorrect because the register mask is actually 0x0fffffff and useless because we already ensure the addresses are below the limit.
Stable-dep-of: 3e5a1d5bb2ff ("drm/amdgpu/vce1: Fix VCE 1 firmware size and offsets")
--- drivers/gpu/drm/amd/amdgpu/vce_v1_0.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/amdgpu/vce_v1_0.c +8 -4
@@ -318,17 +318,17 @@ static int vce_v1_0_mc_resume(struct amdgpu_device *adev) offset = adev->vce.gpu_addr +AMDGPU_VCE_FIRMWARE_OFFSET ; size =VCE_V1_0_FW_SIZE ; -WREG32 (mmVCE_VCPU_CACHE_OFFSET0, offset &0x7fffffff ); +WREG32 (mmVCE_VCPU_CACHE_OFFSET0, offset);WREG32 (mmVCE_VCPU_CACHE_SIZE0, size); offset += size; size =VCE_V1_0_STACK_SIZE ; -WREG32 (mmVCE_VCPU_CACHE_OFFSET1, offset &0x7fffffff ); +WREG32 (mmVCE_VCPU_CACHE_OFFSET1, offset);WREG32 (mmVCE_VCPU_CACHE_SIZE1, size); offset += size; size =VCE_V1_0_DATA_SIZE ; -WREG32 (mmVCE_VCPU_CACHE_OFFSET2, offset &0x7fffffff ); +WREG32 (mmVCE_VCPU_CACHE_OFFSET2, offset);WREG32 (mmVCE_VCPU_CACHE_SIZE2, size);WREG32_P (mmVCE_LMI_CTRL2,0x0 , ~0x100 );
@@ -532,12 +532,16 @@ static int vce_v1_0_early_init(struct amdgpu_ip_block *ip_block)* To accomodate that, we put GART to the LOW address range * and reserve some GART pages where we map the VCPU BO, * so that it gets a 32-bit address. +* +* The BAR address is zero and we can't change it +* due to the firmware validation mechanism. +* It seems that it fails to initialize if the address is >= 128 MiB. */ static int vce_v1_0_ensure_vcpu_bo_32bit_addr (struct amdgpu_device *adev) {u64 gpu_addr =amdgpu_bo_gpu_offset (adev->vce.vcpu_bo);u64 bo_size =amdgpu_bo_size (adev->vce.vcpu_bo); -u64 max_vcpu_bo_addr =0xffffffff - bo_size; +u64 max_vcpu_bo_addr =0x07ffffff - bo_size;u64 num_pages =ALIGN (bo_size,AMDGPU_GPU_PAGE_SIZE ) /AMDGPU_GPU_PAGE_SIZE ;u64 pa =amdgpu_gmc_vram_pa (adev, adev->vce.vcpu_bo);u64 flags =AMDGPU_PTE_READABLE |AMDGPU_PTE_WRITEABLE |AMDGPU_PTE_VALID ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 400/461 drm/amdgpu/vce1: Fix VCE 1 firmware size and offsets
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Timur Kristóf <[email protected]>
[ Upstream commit 3e5a1d5bb2ff061e64c7992f8e5404dfd4c2d0f3 ]
The VCPU BO contains the actual FW at an offset, but it was not calculated into the VCPU BO size. Subtract this from the FW size to make sure there is no out of bounds access.
Make sure the stack and data offsets are aligned to the 32K TLB size.
Check that the FW microcode actually fits in the
space that is reserved for it.
--- drivers/gpu/drm/amd/amdgpu/vce_v1_0.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/amdgpu/vce_v1_0.c +15 -4
@@ -42,9 +42,10 @@#include "oss/oss_1_0_d.h" #include "oss/oss_1_0_sh_mask.h" +#define VCE_V1_0_ALIGNMENT (32 * 1024)#define VCE_V1_0_FW_SIZE (256 * 1024)#define VCE_V1_0_STACK_SIZE (64 * 1024) -#define VCE_V1_0_DATA_SIZE (7808 * (AMDGPU_MAX_VCE_HANDLES + 1)) +#define VCE_V1_0_DATA_SIZE (ALIGN(7808 * (AMDGPU_MAX_VCE_HANDLES + 1), VCE_V1_0_ALIGNMENT))#define VCE_STATUS_VCPU_REPORT_FW_LOADED_MASK 0x02#define VCE_V1_0_GART_PAGE_START \
@@ -194,17 +195,22 @@ static int vce_v1_0_load_fw_signature(struct amdgpu_device *adev) {const struct common_firmware_header *hdr;struct vce_v1_0_fw_signature *sign; -unsigned int ucode_offset; +u32 ucode_offset; +u32 ucode_size;uint32_t chip_id;u32 *cpu_addr;int i; hdr = (const struct common_firmware_header *)adev->vce.fw->data; ucode_offset =le32_to_cpu (hdr->ucode_array_offset_bytes); + ucode_size = hdr->ucode_size_bytes -sizeof (struct vce_v1_0_fw_signature *); cpu_addr = adev->vce.cpu_addr; sign = (void *)adev->vce.fw->data + ucode_offset; +if (ucode_size >VCE_V1_0_FW_SIZE -AMDGPU_VCE_FIRMWARE_OFFSET ) +return -EINVAL ; +switch (adev->asic_type) {case CHIP_TAHITI : chip_id =0x01000014 ;
@@ -236,7 +242,7 @@ static int vce_v1_0_load_fw_signature(struct amdgpu_device *adev) cpu_addr[4 ] =cpu_to_le32 (le32_to_cpu (sign->length) +64 );memset_io (&cpu_addr[5 ],0 ,44 ); -memcpy_toio (&cpu_addr[16 ], &sign[1 ], hdr->ucode_size_bytes -sizeof (*sign)); +memcpy_toio (&cpu_addr[16 ], &sign[1 ], ucode_size); cpu_addr += (le32_to_cpu (sign->length) +64 ) /4 ;memcpy_toio (&cpu_addr[0 ], &sign->val[i].sigval[0 ],16 );
@@ -317,17 +323,22 @@ static int vce_v1_0_mc_resume(struct amdgpu_device *adev)WREG32 (mmVCE_VCPU_SCRATCH7,AMDGPU_MAX_VCE_HANDLES ); offset = adev->vce.gpu_addr +AMDGPU_VCE_FIRMWARE_OFFSET ; - size =VCE_V1_0_FW_SIZE ; + size =VCE_V1_0_FW_SIZE -AMDGPU_VCE_FIRMWARE_OFFSET ;WREG32 (mmVCE_VCPU_CACHE_OFFSET0, offset);WREG32 (mmVCE_VCPU_CACHE_SIZE0, size); offset += size; size =VCE_V1_0_STACK_SIZE ; +WARN_ON (!IS_ALIGNED (offset,VCE_V1_0_ALIGNMENT )); +WARN_ON (!IS_ALIGNED (size,VCE_V1_0_ALIGNMENT ));WREG32 (mmVCE_VCPU_CACHE_OFFSET1, offset);WREG32 (mmVCE_VCPU_CACHE_SIZE1, size); offset += size; size =VCE_V1_0_DATA_SIZE ; +WARN_ON (!IS_ALIGNED (offset,VCE_V1_0_ALIGNMENT )); +WARN_ON (!IS_ALIGNED (size,VCE_V1_0_ALIGNMENT )); +WARN_ON ((offset + size - adev->vce.gpu_addr) >amdgpu_bo_size (adev->vce.vcpu_bo));WREG32 (mmVCE_VCPU_CACHE_OFFSET2, offset);WREG32 (mmVCE_VCPU_CACHE_SIZE2, size);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 401/461 RDMA/mana_ib: Report max_msg_sz in mana_ib_query_port
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shiraz Saleem <[email protected]>
[ Upstream commit c9a40f6531b81baa9619bcc2697ff86896afcce7 ]
Report max_msg_sz for mana_ib, which is 16MB.
--- drivers/infiniband/hw/mana/main.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/hw/mana/main.c +1 -0
@@ -639,6 +639,7 @@ int mana_ib_query_port(struct ib_device *ibdev, u32 port,if (mana_ib_is_rnic (dev)) { props->gid_tbl_len =16 ; props->ip_gids = true; + props->max_msg_sz =SZ_16M ;if (port ==1 ) props->port_cap_flags =IB_PORT_CM_SUP ; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 402/461 RDMA/rtrs: Fix use-after-free in path file creation cleanup
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guangshuo Li <[email protected]>
[ Upstream commit 5b74373390113fba798a76b483837029ab010fef ]
In the error path of rtrs_srv_create_path_files(), the sysfs root folders may already have been created and srv_path->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobject_put(&srv_path->kobj) before rtrs_srv_destroy_once_sysfs_root_folders(srv_path).
kobject_put() may drop the last reference to srv_path->kobj and invoke the release callback, rtrs_srv_release(), which frees srv_path. The following call to rtrs_srv_destroy_once_sysfs_root_folders(srv_path) then dereferences srv_path internally to access srv_path->srv, resulting in a use-after-free.
This failure path is reached before rtrs_srv_create_path_files() returns success, so the successful-path lifetime handling is not involved.
Fix this by destroying the sysfs root folders before calling kobject_put(&srv_path->kobj), so srv_path is still valid while the helper accesses it.
This issue was found by a static analysis tool I am developing.
--- drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c +1 -1
@@ -295,8 +295,8 @@ int rtrs_srv_create_path_files(struct rtrs_srv_path *srv_path) put_kobj:kobject_del (&srv_path->kobj); destroy_root: -kobject_put (&srv_path->kobj);rtrs_srv_destroy_once_sysfs_root_folders (srv_path); +kobject_put (&srv_path->kobj);return err; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 403/461 bridge: mcast: Fix a possible use-after-free when removing a bridge port
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ido Schimmel <[email protected]>
[ Upstream commit 4df78ff02629c7729168f0696a7a2123c389818d ]
When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled.
When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled.
The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port:
# ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1
This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs.
After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1].
Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled.
[1]
ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927)
WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: <IRQ>
__debug_check_no_obj_freed (lib/debugobjects.c:1116)
kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689)rcu_do_batch (kernel/rcu/tree.c:2617)rcu_core (kernel/rcu/tree.c:2869)handle_softirqs (kernel/softirq.c:622)__irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) </IRQ>
--- net/bridge/br_multicast.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)
net/bridge/br_multicast.c +17 -5
@@ -4640,10 +4640,24 @@ static void br_multicast_start_querier(struct net_bridge_mcast *brmctx,rcu_read_unlock (); } -static void br_multicast_del_grps (struct net_bridge *br) +static void br_multicast_enable_all_ports (struct net_bridge *br) {struct net_bridge_port *port; +if (br_opt_get (br,BROPT_MCAST_VLAN_SNOOPING_ENABLED )) +return ; + +list_for_each_entry (port, &br->port_list, list) +__br_multicast_enable_port_ctx (&port->multicast_ctx); +} + +static void br_multicast_disable_all_ports (struct net_bridge *br) +{ +struct net_bridge_port *port; + +if (br_opt_get (br,BROPT_MCAST_VLAN_SNOOPING_ENABLED )) +return ; +list_for_each_entry (port, &br->port_list, list)__br_multicast_disable_port_ctx (&port->multicast_ctx); }
@@ -4651,7 +4665,6 @@ static void br_multicast_del_grps(struct net_bridge *br)int br_multicast_toggle (struct net_bridge *br,unsigned long val,struct netlink_ext_ack *extack) { -struct net_bridge_port *port;bool change_snoopers = false;int err =0 ;
@@ -4668,7 +4681,7 @@ int br_multicast_toggle(struct net_bridge *br, unsigned long val,br_opt_toggle (br,BROPT_MULTICAST_ENABLED , !!val);if (!br_opt_get (br,BROPT_MULTICAST_ENABLED )) { change_snoopers = true; -br_multicast_del_grps (br); +br_multicast_disable_all_ports (br); goto unlock; }
@@ -4676,8 +4689,7 @@ int br_multicast_toggle(struct net_bridge *br, unsigned long val, goto unlock;br_multicast_open (br); -list_for_each_entry (port, &br->port_list, list) -__br_multicast_enable_port_ctx (&port->multicast_ctx); +br_multicast_enable_all_ports (br); change_snoopers = true;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 404/461 net: phy: honor eee_disabled_modes in phy_support_eee()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolai Buchwitz <[email protected]>
[ Upstream commit 3655063e083889ed4b79b7dda9cec65478dce09a ]
phy_support_eee() copies supported_eee into advertising_eee unconditionally, overwriting any filtering applied during phy_probe() based on DT eee-broken-* properties or driver-populated eee_disabled_modes. MAC drivers that call phy_support_eee() after probe (e.g. bcmgenet, fec, lan743x, lan78xx, r8169) then cause the PHY to advertise EEE for modes the user marked as broken.
The symptom is that ethtool --show-eee on the local interface reports "not supported" (supported & ~eee_disabled_modes is empty) while the link partner sees EEE negotiated and active.
phy_probe() already filters advertising_eee via eee_disabled_modes after calling of_set_phy_eee_broken(). Apply the same mask in phy_support_eee() so the filtering survives the copy.
--- drivers/net/phy/phy_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/phy/phy_device.c +2 -1
@@ -2933,7 +2933,8 @@ EXPORT_SYMBOL_GPL(phy_advertise_eee_all);*/ void phy_support_eee (struct phy_device *phydev) { -linkmode_copy (phydev->advertising_eee, phydev->supported_eee); +linkmode_andnot (phydev->advertising_eee, phydev->supported_eee, + phydev->eee_disabled_modes); phydev->eee_cfg.tx_lpi_enabled = true; phydev->eee_cfg.eee_enabled = true; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 405/461 net: phy: honor eee_disabled_modes in phy_advertise_eee_all()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolai Buchwitz <[email protected]>
[ Upstream commit 8baa7506d793f0636e3f6f01b01ef7be19674d06 ]
phy_advertise_eee_all() copies supported_eee into advertising_eee unconditionally, overwriting any filtering applied during phy_probe() based on DT eee-broken-* properties or driver-populated eee_disabled_modes. genphy_c45_ethtool_set_eee() calls this helper when user space passes an empty advertisement, undoing the filtering.
Apply the same eee_disabled_modes mask in phy_advertise_eee_all() so the filtering survives the copy, matching the pattern in phy_probe() and phy_support_eee().
--- drivers/net/phy/phy_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/phy/phy_device.c +2 -1
@@ -2907,7 +2907,8 @@ EXPORT_SYMBOL(phy_advertise_supported);*/ void phy_advertise_eee_all (struct phy_device *phydev) { -linkmode_copy (phydev->advertising_eee, phydev->supported_eee); +linkmode_andnot (phydev->advertising_eee, phydev->supported_eee, + phydev->eee_disabled_modes); }EXPORT_SYMBOL_GPL (phy_advertise_eee_all);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 406/461 net: airoha: Fix NPU RX DMA descriptor bits
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Marangi <[email protected]>
[ Upstream commit 0cb5a74faa3bdcfa3b18735d554e12c0f615e35d ]
In an internal review from Airoha, it was notice that the RX DMA descriptor bits and mask are wrong. These values probably refer to an old NPU firmware never published. The previous value works correctly but it was reported that in some specific condition in mixed scenario with both Ethernet and WiFi offload it's possible that RX DMA descriptor signal wrong value with the problem to the RX ring or packets getting dropped.
To handle these specific scenario, apply the new suggested bits mask from Airoha.
Correct functionality of both AN7581 NPU and MT7996 variant were verified and confirmed working.
--- include/linux/soc/airoha/airoha_offload.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
include/linux/soc/airoha/airoha_offload.h +3 -3
@@ -71,9 +71,9 @@ static inline void airoha_ppe_dev_check_skb(struct airoha_ppe_dev *dev,#define NPU_RX1_DESC_NUM 512/* CTRL */ -#define NPU_RX_DMA_DESC_LAST_MASK BIT(27) -#define NPU_RX_DMA_DESC_LEN_MASK GENMASK(26, 14) -#define NPU_RX_DMA_DESC_CUR_LEN_MASK GENMASK(13, 1) +#define NPU_RX_DMA_DESC_LAST_MASK BIT(29) +#define NPU_RX_DMA_DESC_LEN_MASK GENMASK(28, 15) +#define NPU_RX_DMA_DESC_CUR_LEN_MASK GENMASK(14, 1)#define NPU_RX_DMA_DESC_DONE_MASK BIT(0)/* INFO */ #define NPU_RX_DMA_PKT_COUNT_MASK GENMASK(31, 29)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 407/461 pds_core: fix error handling in pdsc_devcmd_wait
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikhil P. Rao <[email protected]>
[ Upstream commit 0e46b6635b03d29807f810c3b415c4755a3f958d ]
Fix two cases where pdsc_devcmd_wait() returns stale success from the completion register instead of an error:
1. FW crash: If firmware stops running, the wait loop breaks early with running=false. The condition "if ((!done || timeout) && running)" is false, so error handling is bypassed and stale status is returned. Check !running first and return -ENXIO.
2. Timeout: If a command times out, err is set to -ETIMEDOUT but then overwritten by pdsc_err_to_errno(status) which reads stale status. Return -ETIMEDOUT immediately after cleaning up.
Both errors now propagate to pdsc_devcmd_locked() which queues health_work for recovery.
--- drivers/net/ethernet/amd/pds_core/dev.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/net/ethernet/amd/pds_core/dev.c +9 -2
@@ -162,12 +162,19 @@ static int pdsc_devcmd_wait(struct pdsc *pdsc, u8 opcode, int max_seconds)dev_dbg (dev,"DEVCMD %d %s after %ld secs\n" , opcode,pdsc_devcmd_str (opcode), duration /HZ ); -if ((!done || timeout) && running) { +if (!running) { +dev_err (dev,"DEVCMD %d %s fw not running\n" , + opcode,pdsc_devcmd_str (opcode)); +pdsc_devcmd_clean (pdsc); +return -ENXIO ; + } + +if (!done || timeout) {dev_err (dev,"DEVCMD %d %s timeout, done %d timeout %d max_seconds=%d\n" , opcode,pdsc_devcmd_str (opcode), done, timeout, max_seconds); - err = -ETIMEDOUT ;pdsc_devcmd_clean (pdsc); +return -ETIMEDOUT ; } status =pdsc_devcmd_status (pdsc);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 408/461 pds_core: fix debugfs_lookup dentry leak and error handling
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikhil P. Rao <[email protected]>
[ Upstream commit dc416e32baaeb620b9809e9e25fc7b30889686e9 ]
debugfs_lookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.
Additionally, when CONFIG_DEBUG_FS is disabled, debugfs_lookup() returns ERR_PTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.
--- drivers/net/ethernet/amd/pds_core/debugfs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/amd/pds_core/debugfs.c +6 -1
@@ -64,9 +64,14 @@ DEFINE_SHOW_ATTRIBUTE(identity);void pdsc_debugfs_add_ident (struct pdsc *pdsc) { +struct dentry *dentry; +/* This file will already exist in the reset flow */ -if (debugfs_lookup ("identity" , pdsc->dentry)) + dentry =debugfs_lookup ("identity" , pdsc->dentry); +if (!IS_ERR_OR_NULL (dentry)) { +dput (dentry);return ; + }debugfs_create_file ("identity" ,0400 , pdsc->dentry, pdsc, &identity_fops);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 409/461 erofs: fix managed cache race for unaligned extents
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gao Xiang <[email protected]>
[ Upstream commit 649932fc3815eda2f24eb4de4b3a5e94886ee0b9 ]
After unaligned compressed extents were introduced, the following race could occur:
[Thread 1] [Thread 2]
(z_erofs_fill_bio_vec)
<handle a Z_EROFS_PREALLOCATED_FOLIO folio>
...filemap_add_folio (1)
(z_erofs_bind_cache)
<the same folio is found..>
..
..folio_attach_private (2)
filemap_add_folio (3) again
Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO.
Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1].
This only impacts unaligned data compression (-E48bit with zstd, for example).
[1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well.
--- fs/erofs/zdata.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
fs/erofs/zdata.c +8 -7
@@ -1511,8 +1511,15 @@ static void z_erofs_fill_bio_vec(struct bio_vec *bvec,DBG_BUGON (z_erofs_is_shortlived_page (bvec->bv_page)); folio =page_folio (zbv.page); -/* For preallocated managed folios, add them to page cache here */ +/* +* Preallocated folios are added to the managed cache here rather than +* in z_erofs_bind_cache() in order to keep these folios locked in +* increasing (physical) address order. +* Clear folio->private before these folios become visible to others in +* the managed cache to avoid duplicate additions for unaligned extents. +*/ if (folio->private ==Z_EROFS_PREALLOCATED_FOLIO ) { + folio->private =NULL ; tocache = true; goto out_tocache; }
@@ -1548,14 +1555,8 @@ static void z_erofs_fill_bio_vec(struct bio_vec *bvec, }return ; } -/* -* Already linked with another pcluster, which only appears in -* crafted images by fuzzers for now. But handle this anyway. -*/ - tocache = false;/* use temporary short-lived pages */ }else {DBG_BUGON (1 );/* referenced managed folios can't be truncated */ - tocache = true; }folio_unlock (folio);folio_put (folio);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 410/461 erofs: harden h_shared_count in erofs_init_inode_xattrs()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Utkal Singh <[email protected]>
[ Upstream commit 6a01f5478d208544c8ba5ddbd674ea660f1b7047 ]
u8 h_shared_count indicates the shared xattr count of an inode. It is read from the on-disk xattr ibody header, which should be corrupted if the size of the shared xattr array exceeds the space available in xattr_isize.
It does not cause harmful consequence (e.g. crashes), since the image is already considered corrupted, it indeed results in the silent processing of garbage metadata.
Let's harden it to report -EFSCORRUPTED earlier.
Stable-dep-of: 79b09c54c656 ("erofs: fix metabuf leak in inode xattr initialization")
--- fs/erofs/xattr.c | 8 ++++++++ 1 file changed, 8 insertions(+)
fs/erofs/xattr.c +8 -0
@@ -85,6 +85,14 @@ static int erofs_init_inode_xattrs(struct inode *inode) } vi->xattr_name_filter =le32_to_cpu (ih->h_name_filter); vi->xattr_shared_count = ih->h_shared_count; +if ((u32 )vi->xattr_shared_count *sizeof (__le32) > + vi->xattr_isize -sizeof (struct erofs_xattr_ibody_header )) { +erofs_err (sb,"invalid h_shared_count %u @ nid %llu" , + vi->xattr_shared_count, vi->nid); +erofs_put_metabuf (&buf); + ret = -EFSCORRUPTED ; + goto out_unlock; + } vi->xattr_shared_xattrs =kmalloc_objs (uint, vi->xattr_shared_count);if (!vi->xattr_shared_xattrs) {erofs_put_metabuf (&buf);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 411/461 erofs: fix metabuf leak in inode xattr initialization
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jia Zhu <[email protected]>
[ Upstream commit 79b09c54c6563df9846ca3094bcfd72082c3e1d7 ]
commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofs_buf instances. erofs_init_inode_xattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array.
Some error paths after erofs_read_metabuf() leave through out_unlock without dropping the metabuf, so the folio reference can leak.
Consolidate the cleanup at out_unlock. erofs_put_metabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFS_I_BL_XATTR_BIT covered by a single cleanup site.
--- fs/erofs/xattr.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
fs/erofs/xattr.c +1 -3
@@ -89,13 +89,11 @@ static int erofs_init_inode_xattrs(struct inode *inode) vi->xattr_isize - sizeof(struct erofs_xattr_ibody_header)) {erofs_err (sb,"invalid h_shared_count %u @ nid %llu" , vi->xattr_shared_count, vi->nid); -erofs_put_metabuf (&buf); ret = -EFSCORRUPTED ; goto out_unlock; } vi->xattr_shared_xattrs =kmalloc_objs (uint, vi->xattr_shared_count);if (!vi->xattr_shared_xattrs) { -erofs_put_metabuf (&buf); ret = -ENOMEM ; goto out_unlock; }
@@ -112,12 +110,12 @@ static int erofs_init_inode_xattrs(struct inode *inode) } vi->xattr_shared_xattrs[i] =le32_to_cpu (*xattr_id); } -erofs_put_metabuf (&buf);/* paired with smp_mb() at the beginning of the function. */ smp_mb ();set_bit (EROFS_I_EA_INITED_BIT , &vi->flags); out_unlock: +erofs_put_metabuf (&buf);clear_and_wake_up_bit (EROFS_I_BL_XATTR_BIT , &vi->flags);return ret; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 412/461 wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandru Hossu <[email protected]>
[ Upstream commit f718506edd2d9c6a308ded9d13c632bf7b7d5a2c ]
IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID is 0x000f, so link_id extracted from a PRIO_ACCESS ML element PER_STA_PROFILE subelement can be 0..15. sdata->link[] has IEEE80211_MLD_MAX_NUM_LINKS (15) entries (indices 0..14), making index 15 out-of-bounds.
A connected WiFi 7 AP can trigger this by sending an EPCS Enable Response action frame with a PER_STA_PROFILE subelement where link_id = 15. The unsolicited-notification path (dialog_token = 0) is reachable any time EPCS is already enabled, without any prior client request.
sdata->link[15] reads into the first word of sdata->activate_links_work (a wiphy_work whose embedded list_head is non-NULL after INIT_LIST_HEAD), so the NULL check on the result does not catch the invalid access. The garbage pointer is then passed to ieee80211_sta_wmm_params(), which dereferences link->sdata and crashes the kernel.
The same class of bug was fixed for ieee80211_ml_reconfiguration() by commit 162d331d833d ("wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfiguration").
--- net/mac80211/mlme.c | 3 +++ 1 file changed, 3 insertions(+)
net/mac80211/mlme.c +3 -0
@@ -11137,6 +11137,9 @@ static void ieee80211_ml_epcs(struct ieee80211_sub_if_data *sdata, control =get_unaligned_le16 (pos); link_id = control &IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID ; +if (link_id >=IEEE80211_MLD_MAX_NUM_LINKS ) +continue ; + link =sdata_dereference (sdata->link[link_id], sdata);if (!link)continue ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 413/461 wifi: mac80211: fix MLE defragmentation
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ Upstream commit a74e893f30db64cdce0fc7a96d3baa417bcd55f5 ]
If either reconf or EPCS multi-link element (MLE) is contained in a non-transmitted profile, the defragmentation routine is called with a pointer to the defragmented copy, but the original elements.
This is incorrect for two reasons:
- if the original defragmentation was needed, it will not find the correct data
- if the original frame is at a higher address, the parsing will potentially overrun the heap data (though given the layout of the buffers, only into the new defragmentation buffer, and then it has to stop and fail once that's filled with copied data.
Fix it by tracking the container along with the pointer and in doing so also unify the two almost identical defragmentation routines.
--- net/mac80211/parse.c | 71 +++++++++++++++++++------------------------- 1 file changed, 31 insertions(+), 40 deletions(-)
net/mac80211/parse.c +31 -40
@@ -34,6 +34,13 @@#include "led.h" #include "wep.h" +struct ieee80211_elem_defrag { +const struct element *elem; +/* container start/len */ +const u8 *start; +size_t len; +}; +struct ieee80211_elems_parse {/* must be first for kfree to work */ struct ieee802_11_elems elems;
@@ -41,11 +48,7 @@ struct ieee80211_elems_parse {/* The basic Multi-Link element in the original elements */ const struct element *ml_basic_elem; -/* The reconfiguration Multi-Link element in the original elements */ -const struct element *ml_reconf_elem; - -/* The EPCS Multi-Link element in the original elements */ -const struct element *ml_epcs_elem; +struct ieee80211_elem_defrag ml_reconf, ml_epcs;bool multi_link_inner;bool skip_vendor;
@@ -162,10 +165,14 @@ ieee80211_parse_extension_element(u32 *crc, }break ;case IEEE80211_ML_CONTROL_TYPE_RECONF : - elems_parse->ml_reconf_elem = elem; + elems_parse->ml_reconf.elem = elem; + elems_parse->ml_reconf.start = params->start; + elems_parse->ml_reconf.len = params->len;break ;case IEEE80211_ML_CONTROL_TYPE_PRIO_ACCESS : - elems_parse->ml_epcs_elem = elem; + elems_parse->ml_epcs.elem = elem; + elems_parse->ml_epcs.start = params->start; + elems_parse->ml_epcs.len = params->len;break ;default :break ;
@@ -990,46 +997,27 @@ ieee80211_prep_mle_link_parse(struct ieee80211_elems_parse *elems_parse, sub->start, sub->len); } -static void -ieee80211_mle_defrag_reconf (struct ieee80211_elems_parse *elems_parse) -{ -struct ieee802_11_elems *elems = &elems_parse->elems; -ssize_t ml_len; - - ml_len =cfg80211_defragment_element (elems_parse->ml_reconf_elem, - elems->ie_start, - elems->total_len, - elems_parse->scratch_pos, - elems_parse->scratch + - elems_parse->scratch_len - - elems_parse->scratch_pos, -WLAN_EID_FRAGMENT ); -if (ml_len <0 ) -return ; - elems->ml_reconf = (void *)elems_parse->scratch_pos; - elems->ml_reconf_len = ml_len; - elems_parse->scratch_pos += ml_len; -} - -static void -ieee80211_mle_defrag_epcs (struct ieee80211_elems_parse *elems_parse) +static const void * +ieee80211_mle_defrag (struct ieee80211_elems_parse *elems_parse, +struct ieee80211_elem_defrag *defrag, +size_t *out_len) { -struct ieee802_11_elems *elems = &elems_parse->elems; +const void *ret;ssize_t ml_len; - ml_len =cfg80211_defragment_element (elems_parse->ml_epcs_elem, - elems->ie_start, - elems->total_len, + ml_len =cfg80211_defragment_element (defrag->elem, + defrag->start, defrag->len, elems_parse->scratch_pos, elems_parse->scratch + elems_parse->scratch_len - elems_parse->scratch_pos,WLAN_EID_FRAGMENT );if (ml_len <0 ) -return ; - elems->ml_epcs = (void *)elems_parse->scratch_pos; - elems->ml_epcs_len = ml_len; +return NULL ; + ret = elems_parse->scratch_pos; + *out_len = ml_len; elems_parse->scratch_pos += ml_len; +return ret; } struct ieee802_11_elems *
@@ -1109,9 +1097,12 @@ ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params)_ieee802_11_parse_elems_full (&sub, elems_parse,NULL ); } -ieee80211_mle_defrag_reconf (elems_parse); - -ieee80211_mle_defrag_epcs (elems_parse); + elems->ml_reconf =ieee80211_mle_defrag (elems_parse, + &elems_parse->ml_reconf, + &elems->ml_reconf_len); + elems->ml_epcs =ieee80211_mle_defrag (elems_parse, + &elems_parse->ml_epcs, + &elems->ml_epcs_len);if (elems->tim && !elems->parse_error) {const struct ieee80211_tim_ie *tim_ie = elems->tim;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 414/461 wifi: mac80211: fix multi-link element inheritance
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ Upstream commit fe2d61a5d2849ee75dd4deeb2fe35f78d80721f8 ]
When parsing a beacon, mac80211 erroneously inherits any reconfiguration or EPCS multi-link elements from the outer elements into the multi-BSSID profile that's requested, if connected to a non-transmitted BSS, unless that profile has a non-inheritance element.
This also happens if parsing a multi-BSSID profile that doesn't have a non-inheritance element.
Fix this by having an empty non-inheritance element so cfg80211_is_element_inherited() is invoked in these cases and causes the parser to skip the elements that should never be inherited.
--- net/mac80211/parse.c | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-)
net/mac80211/parse.c +33 -3
@@ -34,6 +34,15 @@#include "led.h" #include "wep.h" +static const u8 empty_non_inheritance[] = { +WLAN_EID_EXTENSION ,1 ,WLAN_EID_EXT_NON_INHERITANCE , +/* +* cfg80211_is_element_inherited() hardcodes elements that +* cannot be inherited, so we just need an empty one to be +* calling it at all. +*/ +}; +struct ieee80211_elem_defrag {const struct element *elem;/* container start/len */
@@ -923,7 +932,7 @@ ieee80211_prep_mle_link_parse(struct ieee80211_elems_parse *elems_parse, {struct ieee802_11_elems *elems = &elems_parse->elems;struct ieee80211_mle_per_sta_profile *prof; -const struct element *tmp; +const struct element *tmp, *ret;ssize_t ml_len;const u8 *end;
@@ -993,8 +1002,17 @@ ieee80211_prep_mle_link_parse(struct ieee80211_elems_parse *elems_parse, sub->from_ap = params->from_ap; sub->link_id =-1 ; -return cfg80211_find_ext_elem (WLAN_EID_EXT_NON_INHERITANCE , - sub->start, sub->len); + ret =cfg80211_find_ext_elem (WLAN_EID_EXT_NON_INHERITANCE , + sub->start, sub->len); +if (ret) +return ret; + +/* +* Since we know we want and found a profile, apply an empty +* non-inheritance if the profile didn't have one, so that any +* element that shouldn't be inherited by spec isn't. +*/ +return (const void *)empty_non_inheritance; } static const void *
@@ -1030,6 +1048,7 @@ ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params)size_t scratch_len =3 * params->len;bool multi_link_inner = false; +BUILD_BUG_ON (sizeof (empty_non_inheritance) != empty_non_inheritance[1 ] +2 ); BUILD_BUG_ON(offsetof(typeof(*elems_parse), elems) != 0);/* cannot parse for both a specific link and non-transmitted BSS */
@@ -1077,6 +1096,17 @@ ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params) non_inherit =cfg80211_find_ext_elem (WLAN_EID_EXT_NON_INHERITANCE , sub.start, nontx_len); +/* +* If it's a non-transmitted BSS, we shouldn't pick +* any elements in the outer parsing that shouldn't +* be inherited. If the profile has a non-inheritance +* element this automatically happens, but if not then +* provide an empty one so that the hard-coded elements +* in cfg80211_is_element_inherited() are ignored, but +* it must be called. +*/ +if (params->bss->transmitted_bss && !non_inherit) + non_inherit = (const void *)empty_non_inheritance; }else {/* must always parse to get elems_parse->ml_basic_elem */ non_inherit = ieee80211_prep_mle_link_parse(elems_parse, params,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 415/461 wifi: wilc1000: fix dma_buffer leak on bus acquire failure
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shitalkumar Gandhi <[email protected]>
[ Upstream commit dd7b6a8671939708cc4b7a46786d8c11297e8f69 ]
wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at the top of the function and uses a 'fail:' label to free it via kfree(dma_buffer) on error.
All later error paths correctly use 'goto fail' to route through this cleanup. However, the early failure path after the first acquire_bus() call uses a bare 'return ret;', which leaks dma_buffer whenever the bus acquire fails.
Replace the early return with goto fail so the existing cleanup path runs.
Found via a custom Coccinelle semantic patch hunting for kmalloc'd locals leaked on early-return error paths in driver firmware-download code.
--- drivers/net/wireless/microchip/wilc1000/wlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/microchip/wilc1000/wlan.c +1 -1
@@ -1265,7 +1265,7 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const u8 *buffer, ret =acquire_bus (wilc,WILC_BUS_ACQUIRE_AND_WAKEUP );if (ret) -return ret; + goto fail; wilc->hif_func->hif_read_reg (wilc,WILC_GLB_RESET_0 , ®); reg &= ~BIT (10 );
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 416/461 ALSA: seq: Serialize UMP output teardown with event_input
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Cen <[email protected]>
[ Upstream commit 60a1969fae6209644698fca91c185d153674f631 ]
seq_ump_process_event() borrows client->out_rfile.output without synchronizing with the first-open and last-close transition in seq_ump_client_open() and seq_ump_client_close().
The last output unuse can therefore drop opened[STR_OUT] to zero and release the rawmidi file while an in-flight event_input callback is still inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream runtime exposed to teardown before the write path has taken its own buffer reference.
Add a per-client rwlock for the event_input-visible output file. Publish a newly opened output file under the write side, and hold the read side from the output lookup through snd_rawmidi_kernel_write(). The last output close copies and clears the visible output file under the write side, then drops the lock and releases the saved rawmidi file. Use IRQ-safe rwlock guards because event_input can also be reached from atomic sequencer delivery.
The buggy scenario involves two paths, with each column showing the order within that path:
path A label: event_input path path B label: last unuse path
1. seq_ump_process_event() reads 1. seq_ump_client_close()
client->out_rfile.output. drops opened[STR_OUT] to zero.
2. snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release()
has not yet pinned runtime. closes the output file.
3. The writer continues using 3. close_substream() frees
the borrowed substream. substream->runtime.
This keeps the output substream and runtime alive for the full event_input write while keeping rawmidi release outside the rwlock.
KASAN reproduced this as a slab-use-after-free in snd_rawmidi_kernel_write1(), with allocation through seq_ump_use()/snd_seq_port_connect() and free through seq_ump_unuse()/snd_seq_port_disconnect().
Validation reproduced this kernel report:
KASAN slab-use-after-free in snd_rawmidi_kernel_write1+0x9d/0x400
RIP: 0033:0x7f5528af837f Read of size 8 Call trace: dump_stack_lvl+0x73/0xb0 (?:?) print_report+0xd1/0x650 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x1a7/0x340 (?:?) kasan_complete_mode_report_info+0x64/0x200 (?:?) kasan_report+0xf7/0x130 (?:?) snd_rawmidi_kernel_write1+0x9d/0x400 (?:?) __asan_load8+0x82/0xb0 (?:?) update_stack_state+0x1ef/0x2d0 (?:?) snd_rawmidi_kernel_write+0x1a/0x20 (?:?) seq_ump_process_event+0xd4/0x120 (sound/core/seq/seq_ump_client.c:82) __snd_seq_deliver_single_event+0x8a/0xe0 (?:?) snd_seq_deliver_from_ump+0x2b2/0xd60 (?:?) lock_acquire+0x14e/0x2e0 (?:?) find_held_lock+0x31/0x90 (?:?) snd_seq_port_use_ptr+0xa6/0xe0 (?:?) __kasan_check_write+0x18/0x20 (?:?) do_raw_read_unlock+0x32/0xa0 (?:?) _raw_read_unlock+0x26/0x50 (?:?) snd_seq_deliver_single_event+0x45c/0x4b0 (?:?) snd_seq_deliver_event+0x10d/0x1b0 (?:?) snd_seq_client_enqueue_event+0x192/0x240 (?:?) snd_seq_write+0x2cd/0x450 (?:?) apparmor_file_permission+0x20/0x30 (?:?) security_file_permission+0x51/0x60 (?:?) vfs_write+0x1ce/0x850 (?:?) __fget_files+0x12b/0x220 (?:?) lock_release+0xc8/0x2a0 (?:?) __rcu_read_unlock+0x74/0x2d0 (?:?) __fget_files+0x135/0x220 (?:?) ksys_write+0x15a/0x180 (?:?) rcu_is_watching+0x24/0x60 (?:?) __x64_sys_write+0x46/0x60 (?:?) x64_sys_call+0x7d/0x20d0 (?:?) do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)
--- sound/core/seq/seq_ump_client.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-)
sound/core/seq/seq_ump_client.c +18 -4
@@ -37,6 +37,7 @@ struct seq_ump_client {struct snd_ump_endpoint *ump;/* assigned endpoint */ int seq_client;/* sequencer client id */ int opened[2 ];/* current opens for each direction */ +rwlock_t output_lock;/* protects out_rfile output access */ struct snd_rawmidi_file out_rfile;/* rawmidi for output */ struct seq_ump_input_buffer input;/* input parser context */ void *ump_info[SNDRV_UMP_MAX_BLOCKS +1 ];/* shadow of seq client ump_info */
@@ -88,6 +89,7 @@ static int seq_ump_process_event(struct snd_seq_event *ev, int direct,unsigned char type;int len; +guard (read_lock_irqsave)(&client->output_lock); substream = client->out_rfile.output;if (!substream)return -ENODEV ;
@@ -106,6 +108,7 @@ static int seq_ump_process_event(struct snd_seq_event *ev, int direct,static int seq_ump_client_open (struct seq_ump_client *client,int dir) {struct snd_ump_endpoint *ump = client->ump; +struct snd_rawmidi_file rfile = {};int err;guard (mutex)(&ump->open_mutex);
@@ -113,9 +116,11 @@ static int seq_ump_client_open(struct seq_ump_client *client, int dir) err =snd_rawmidi_kernel_open (&ump->core,0 ,SNDRV_RAWMIDI_LFLG_OUTPUT |SNDRV_RAWMIDI_LFLG_APPEND , - &client->out_rfile); + &rfile);if (err <0 )return err; +scoped_guard (write_lock_irqsave, &client->output_lock) + client->out_rfile = rfile; } client->opened[dir]++;return 0 ;
@@ -125,11 +130,19 @@ static int seq_ump_client_open(struct seq_ump_client *client, int dir)static int seq_ump_client_close (struct seq_ump_client *client,int dir) {struct snd_ump_endpoint *ump = client->ump; +struct snd_rawmidi_file rfile = {};guard (mutex)(&ump->open_mutex); -if (!--client->opened[dir]) -if (dir ==STR_OUT ) -snd_rawmidi_kernel_release (&client->out_rfile); +if (!--client->opened[dir]) { +if (dir ==STR_OUT ) { + scoped_guard(write_lock_irqsave, &client->output_lock) { + rfile = client->out_rfile; + client->out_rfile = (struct snd_rawmidi_file ){}; + } +if (rfile.rmidi) +snd_rawmidi_kernel_release (&rfile); + } + }return 0 ; }
@@ -467,6 +480,7 @@ static int snd_seq_ump_probe(struct snd_seq_device *dev)INIT_WORK (&client->group_notify_work, handle_group_notify); client->ump = ump; +rwlock_init (&client->output_lock); client->seq_client = snd_seq_create_kernel_client(card, ump->core.device,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 417/461 cgroup: rstat: relax NMI guard after switch to try_cmpxchg
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cunlong Li <[email protected]>
[ Upstream commit 22572dbcd3486e6c4dced877125bbf50e4e24edf ]
Commit 36df6e3dbd7e ("cgroup: make css_rstat_updated nmi safe") used this_cpu_cmpxchg() for the lockless insertion, and therefore required both ARCH_HAVE_NMI_SAFE_CMPXCHG and ARCH_HAS_NMI_SAFE_THIS_CPU_OPS in the NMI guard: on archs without the latter, this_cpu_cmpxchg() falls back to "local_irq_save() + plain cmpxchg", and local_irq_save() cannot mask NMIs.
Commit 3309b63a2281 ("cgroup: rstat: use LOCK CMPXCHG in css_rstat_updated") later replaced this_cpu_cmpxchg() with plain try_cmpxchg() to fix cross-CPU lockless-list corruption, but left the NMI guard untouched. After that switch, css_rstat_updated() no longer performs any this_cpu_*() RMW operations and only relies on the arch having NMI-safe cmpxchg, so ARCH_HAS_NMI_SAFE_THIS_CPU_OPS is no longer required in the guard.
Relax the guard accordingly so that archs which have HAVE_NMI and ARCH_HAVE_NMI_SAFE_CMPXCHG but not ARCH_HAS_NMI_SAFE_THIS_CPU_OPS (e.g. sparc, powerpc on PPC64/BOOK3S) can benefit from the existing CONFIG_MEMCG_NMI_SAFETY_REQUIRES_ATOMIC path. Without this, the css is never queued in NMI on those archs, and the atomics staged by account_{slab,kmem}_nmi_safe() are not drained by flush_nmi_stats().
--- kernel/cgroup/rstat.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
kernel/cgroup/rstat.c +3 -4
@@ -81,11 +81,10 @@ void __css_rstat_updated(struct cgroup_subsys_state *css, int cpu)lockdep_assert_preemption_disabled ();/* -* For archs withnot nmi safe cmpxchg or percpu ops support, ignore -* the requests from nmi context. +* The lockless insertion below relies on NMI-safe cmpxchg; +* bail out in NMI on archs that don't provide it. */ -if ((!IS_ENABLED (CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG ) || - !IS_ENABLED (CONFIG_ARCH_HAS_NMI_SAFE_THIS_CPU_OPS )) &&in_nmi ()) +if (!IS_ENABLED (CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG ) &&in_nmi ())return ; rstatc =css_rstat_cpu (css, cpu);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 418/461 tracing: Avoid NULL return from hist_field_name() on truncation
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Carlier <[email protected]>
[ Upstream commit 576ec047d20b368b43c4d5db98c4f2e0f3c101ec ]
hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL:strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it.
system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path.
Keep the length check but leave field_name as "" on overflow.
--- kernel/trace/trace_events_hist.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
kernel/trace/trace_events_hist.c +2 -4
@@ -1366,10 +1366,8 @@ static const char *hist_field_name(struct hist_field *field, len =snprintf (full_name,sizeof (full_name),"%s.%s.%s" , field->system, field->event_name, field->name); -if (len >=sizeof (full_name)) -return NULL ; - - field_name = full_name; +if (len <sizeof (full_name)) + field_name = full_name; }else field_name = field->name; }else if (field->flags &HIST_FIELD_FL_TIMESTAMP )
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 419/461 Bluetooth: hci_sync: Fix not setting mask for HCI_EVT_LE_ALL_REMOTE_FEATURES_COMPLETE
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit 23d528d817a485fe9800a66c9411bd9e3d8a6f63 ]
This fixes not setting the bit for HCI_EVT_LE_ALL_REMOTE_FEATURES_COMPLETE when extended features bit is set otherwise the controller may not generate HCI_EVT_LE_ALL_REMOTE_FEATURES_COMPLETE causing hci_le_read_all_remote_features_sync to timeout waiting for it.
Also remove dead code.
--- net/bluetooth/hci_sync.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
net/bluetooth/hci_sync.c +3 -3
@@ -4438,6 +4438,9 @@ static int hci_le_set_event_mask_sync(struct hci_dev *hdev) events[4 ] |=0x02 ;/* LE BIG Info Advertising Report */ } +if (ll_ext_feature_capable (hdev)) + events[5 ] |=BIT (2 ); +if (le_cs_capable (hdev)) {/* Channel Sounding events */ events[5 ] |=0x08 ;/* LE CS Read Remote Supported Cap Complete event */
@@ -7413,9 +7416,6 @@ static int hci_le_read_all_remote_features_sync(struct hci_dev *hdev,sizeof (cp), &cp,HCI_EVT_LE_ALL_REMOTE_FEATURES_COMPLETE , HCI_CMD_TIMEOUT, NULL); - -return __hci_cmd_sync_status (hdev,HCI_OP_LE_READ_ALL_REMOTE_FEATURES , -sizeof (cp), &cp,HCI_CMD_TIMEOUT ); }static int hci_le_read_remote_features_sync (struct hci_dev *hdev,void *data)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 420/461 Bluetooth: btintel_pcie: Fix incorrect MAC access programming
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kiran K <[email protected]>
[ Upstream commit 88365d04fdc821dc4e9eb0cc00fdf6905430d172 ]
btintel_pcie_get_mac_access() and btintel_pcie_release_mac_access() were programming STOP_MAC_ACCESS_DIS and XTAL_CLK_REQ in addition to the MAC_ACCESS_REQ handshake. These bits are not part of the host MAC-access handshake on the supported parts; the driver was programming them incorrectly. Drop the writes so the register update contains only the bits the controller actually consumes.
--- drivers/bluetooth/btintel_pcie.c | 20 ++++++-------------- drivers/bluetooth/btintel_pcie.h | 3 --- 2 files changed, 6 insertions(+), 17 deletions(-)
drivers/bluetooth/btintel_pcie.c +6 -14
@@ -568,12 +568,10 @@ static int btintel_pcie_get_mac_access(struct btintel_pcie_data *data) reg =btintel_pcie_rd_reg32 (data,BTINTEL_PCIE_CSR_FUNC_CTRL_REG ); - reg |=BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS ; - reg |=BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ ; -if ((reg &BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_STS ) ==0 ) +if (!(reg &BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ )) { reg |=BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ ; - -btintel_pcie_wr_reg32 (data,BTINTEL_PCIE_CSR_FUNC_CTRL_REG , reg); +btintel_pcie_wr_reg32 (data,BTINTEL_PCIE_CSR_FUNC_CTRL_REG , reg); + } do { reg = btintel_pcie_rd_reg32(data, BTINTEL_PCIE_CSR_FUNC_CTRL_REG);
@@ -593,16 +591,10 @@ static void btintel_pcie_release_mac_access(struct btintel_pcie_data *data) reg =btintel_pcie_rd_reg32 (data,BTINTEL_PCIE_CSR_FUNC_CTRL_REG ); -if (reg &BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ ) +if (reg &BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ ) { reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ ; - -if (reg &BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS ) - reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS ; - -if (reg &BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ ) - reg &= ~BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ ; - -btintel_pcie_wr_reg32 (data,BTINTEL_PCIE_CSR_FUNC_CTRL_REG , reg); +btintel_pcie_wr_reg32 (data,BTINTEL_PCIE_CSR_FUNC_CTRL_REG , reg); + } } static void *btintel_pcie_copy_tlv(void *dest, enum btintel_pcie_tlv_type type,
drivers/bluetooth/btintel_pcie.h +0 -3
@@ -34,9 +34,6 @@#define BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_STS (BIT(20))#define BTINTEL_PCIE_CSR_FUNC_CTRL_MAC_ACCESS_REQ (BIT(21)) -/* Stop MAC Access disconnection request */ -#define BTINTEL_PCIE_CSR_FUNC_CTRL_STOP_MAC_ACCESS_DIS (BIT(22)) -#define BTINTEL_PCIE_CSR_FUNC_CTRL_XTAL_CLK_REQ (BIT(23))#define BTINTEL_PCIE_CSR_FUNC_CTRL_BUS_MASTER_STS (BIT(28))#define BTINTEL_PCIE_CSR_FUNC_CTRL_BUS_MASTER_DISCON (BIT(29))
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 421/461 Bluetooth: btmtk: fix urb->setup_packet leak in error paths
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiajia Liu <[email protected]>
[ Upstream commit dd1dda6b8d6e1f4376a5b3055a04f0ecbdb4d6bd ]
The setup_packet of control urb is not freed if usb_submit_urb fails or the submitted urb is killed. Add free in these two paths.
--- drivers/bluetooth/btmtk.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/bluetooth/btmtk.c +2 -0
@@ -496,6 +496,7 @@ static void btmtk_usb_wmt_recv(struct urb *urb)return ; }else if (urb->status == -ENOENT ) {/* Avoid suspend failed when usb_kill_urb */ +kfree (urb->setup_packet);return ; }
@@ -569,6 +570,7 @@ static int btmtk_usb_submit_wmt_recv_urb(struct hci_dev *hdev)if (err != -EPERM && err != -ENODEV )bt_dev_err (hdev,"urb %p submission failed (%d)" , urb, -err); +kfree (dr);usb_unanchor_urb (urb); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 422/461 udp: gso: Fix handling checksum in __udp_gso_segment
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alice Mikityanska <[email protected]>
[ Upstream commit 5f17ae0f595aeb560155ce98edbe44d3eacc7e40 ]
The cited commit started using msslen for uh->len, but still uses newlen to adjust uh->check. Although the checksum is ignored in most cases due to the hardware offload, __udp_gso_segment attempts to maintain the correct one. Fix uh->check and adjust it by the right value.
Additionally, after the fix, newlen becomes assigned and unused before the loop. The code can be simplified a bit if mss adjustment is dropped, so that newlen becomes equal to msslen before the loop, and msslen can be also dropped, saving a few lines of code.
This brings us back to one variable, drops an unneeded arithmetic for mss, and fixes the UDP checksum.
--- net/ipv4/udp_offload.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-)
net/ipv4/udp_offload.c +2 -11
@@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,struct sock *sk = gso_skb->sk;unsigned int sum_truesize =0 ;struct sk_buff *segs, *seg; -__be16 newlen, msslen;struct udphdr *uh;unsigned int mss;bool copy_dtor;__sum16 check; +__be16 newlen;int ret =0 ; mss =skb_shinfo (gso_skb)->gso_size;
@@ -556,15 +556,6 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,return segs; } - msslen =htons (sizeof (*uh) + mss); - -/* GSO partial and frag_list segmentation only requires splitting -* the frame into an MSS multiple and possibly a remainder, both -* cases return a GSO skb. So update the mss now. -*/ -if (skb_is_gso (segs)) - mss *=skb_shinfo (segs)->gso_segs; - seg = segs; uh =udp_hdr (seg);
@@ -587,7 +578,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,if (!seg->next)break ; - uh->len = msslen; + uh->len = newlen; uh->check = check;if (seg->ip_summed ==CHECKSUM_PARTIAL )
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 423/461 udp: Fix UDP length on last GSO_PARTIAL segment
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gal Pressman <[email protected]>
[ Upstream commit 78effd896eee11ac9db9bcbb53e7bbcad96073d7 ]
Following the cited commit, __udp_gso_segment() writes single MSS length in the UDP header.
The cited patch doesn't account for the fact that the last segment could be a GSO skb by itself. This could happen when the size of the packet is a multiple of MSS, hence the first segment is also the last one (there is no need for a remainder skb).
When the post-loop segment is a GSO skb, assign the single MSS length in the UDP header.
--- net/ipv4/udp_offload.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
net/ipv4/udp_offload.c +6 -3
@@ -591,9 +591,12 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb, uh =udp_hdr (seg); } -/* last packet can be partial gso_size, account for that in checksum */ - newlen =htons (skb_tail_pointer (seg) -skb_transport_header (seg) + - seg->data_len); +/* Unless skb fits perfectly as GSO_PARTIAL, the trailing +* segment may not be full MSS, account for that in the checksum +*/ +if (!skb_is_gso (seg)) + newlen =htons (skb_tail_pointer (seg) - +skb_transport_header (seg) + seg->data_len); check =csum16_add (csum16_sub (uh->check, uh->len), newlen); uh->len = newlen;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 424/461 net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prathamesh Deshpande <[email protected]>
[ Upstream commit abe003b33223ff33552f291644bf35d9c2f992fb ]
mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating software state and skipping hardware offload setup.
That path jumps to the common success label before taking the eswitch mode block. After tunnel-mode validation was moved earlier, the common success label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs, this decrements esw->offloads.num_block_mode without a matching increment.
Return directly after installing the acquire SA offload handle, so only the paths that successfully called mlx5_eswitch_block_mode() call the matching unblock.
--- drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c +4 -3
@@ -793,8 +793,10 @@ static int mlx5e_xfrm_add_state(struct net_device *dev, sa_entry->dev = dev; sa_entry->ipsec = ipsec;/* Check if this SA is originated from acquire flow temporary SA */ -if (x->xso.flags &XFRM_DEV_OFFLOAD_FLAG_ACQ ) - goto out; +if (x->xso.flags &XFRM_DEV_OFFLOAD_FLAG_ACQ ) { + x->xso.offload_handle = (unsigned long )sa_entry; +return 0 ; + } err =mlx5e_xfrm_validate_state (priv->mdev, x, extack);if (err)
@@ -871,7 +873,6 @@ static int mlx5e_xfrm_add_state(struct net_device *dev,xa_unlock_bh (&ipsec->sadb); } -out: x->xso.offload_handle = (unsigned long )sa_entry;if (allow_tunnel_mode)mlx5_eswitch_unblock_encap (priv->mdev);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 425/461 net: shaper: annotate the data races
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit a3442936dd0523277e20aaf86207c574e755c634 ]
As previously discussed we don't care about making the shaper state fully RCU-compliant because the hierarchy itself can't be dumped in one go over Netlink. Let's annotate the reads and writes to make that clear.
The field-by-field assignments will also be useful for the next commit which adds explicit "valid" field (which we don't want to override with the current full struct assignment).
Stable-dep-of: b8d7519352ba ("net: shaper: rework the VALID marking (again)")
--- net/shaper/shaper.c | 53 ++++++++++++++++++++++++++++++++------------- 1 file changed, 38 insertions(+), 15 deletions(-)
net/shaper/shaper.c +38 -15
@@ -138,35 +138,58 @@ static int net_shaper_fill_handle(struct sk_buff *msg,return -EMSGSIZE ; } +static void net_shaper_copy (struct net_shaper *dst, +const struct net_shaper *src) +{ +WRITE_ONCE (dst->parent.scope,READ_ONCE (src->parent.scope)); +WRITE_ONCE (dst->parent.id,READ_ONCE (src->parent.id)); +WRITE_ONCE (dst->handle.scope,READ_ONCE (src->handle.scope)); +WRITE_ONCE (dst->handle.id,READ_ONCE (src->handle.id)); + +WRITE_ONCE (dst->metric,READ_ONCE (src->metric)); +WRITE_ONCE (dst->bw_min,READ_ONCE (src->bw_min)); +WRITE_ONCE (dst->bw_max,READ_ONCE (src->bw_max)); +WRITE_ONCE (dst->burst,READ_ONCE (src->burst)); +WRITE_ONCE (dst->priority,READ_ONCE (src->priority)); +WRITE_ONCE (dst->weight,READ_ONCE (src->weight)); + +/* private fields are only used on the write path under the lock */ +data_race (dst->leaves = src->leaves); +} +static int net_shaper_fill_one (struct sk_buff *msg,const struct net_shaper_binding *binding,const struct net_shaper *shaper,const struct genl_info *info) { +struct net_shaper cur;void *hdr; hdr =genlmsg_iput (msg, info);if (!hdr)return -EMSGSIZE ; +/* Make a copy to avoid data races */ +net_shaper_copy (&cur, shaper); +if (net_shaper_fill_binding (msg, binding,NET_SHAPER_A_IFINDEX ) || -net_shaper_fill_handle (msg, &shaper->parent, +net_shaper_fill_handle (msg, &cur.parent,NET_SHAPER_A_PARENT ) || -net_shaper_fill_handle (msg, &shaper->handle, +net_shaper_fill_handle (msg, &cur.handle,NET_SHAPER_A_HANDLE ) || - ((shaper->bw_min || shaper->bw_max || shaper->burst) && -nla_put_u32 (msg,NET_SHAPER_A_METRIC , shaper->metric)) || - (shaper->bw_min && -nla_put_uint (msg,NET_SHAPER_A_BW_MIN , shaper->bw_min)) || - (shaper->bw_max && -nla_put_uint (msg,NET_SHAPER_A_BW_MAX , shaper->bw_max)) || - (shaper->burst && -nla_put_uint (msg,NET_SHAPER_A_BURST , shaper->burst)) || - (shaper->priority && -nla_put_u32 (msg,NET_SHAPER_A_PRIORITY , shaper->priority)) || - (shaper->weight && -nla_put_u32 (msg,NET_SHAPER_A_WEIGHT , shaper->weight))) + ((cur.bw_min || cur.bw_max || cur.burst) && +nla_put_u32 (msg,NET_SHAPER_A_METRIC , cur.metric)) || + (cur.bw_min && +nla_put_uint (msg,NET_SHAPER_A_BW_MIN , cur.bw_min)) || + (cur.bw_max && +nla_put_uint (msg,NET_SHAPER_A_BW_MAX , cur.bw_max)) || + (cur.burst && +nla_put_uint (msg,NET_SHAPER_A_BURST , cur.burst)) || + (cur.priority && +nla_put_u32 (msg,NET_SHAPER_A_PRIORITY , cur.priority)) || + (cur.weight && +nla_put_u32 (msg,NET_SHAPER_A_WEIGHT , cur.weight))) goto nla_put_failure;genlmsg_end (msg, hdr);
@@ -424,7 +447,7 @@ static void net_shaper_commit(struct net_shaper_binding *binding,/* Successful update: drop the tentative mark * and update the hierarchy container. */ - *cur = shapers[i]; +net_shaper_copy (cur, &shapers[i]);smp_wmb ();__xa_set_mark (&hierarchy->shapers, index,NET_SHAPER_VALID ); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 426/461 net: shaper: rework the VALID marking (again)
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit b8d7519352ba8c6df83259295d4a3bad093cae90 ]
Recent commit changed the semantics from NOT_VALID to VALID. I didn't realize that the flags are not stored atomically with the entry in XArray. There's still a race of reader observing a VALID mark for a slot, getting interrupted, writer replacing the entry with a different one, reader continuing, fetching the entry which is now a different pointer than the pointer for which VALID was meant.
The biggest consequence of this is that we may see a UAF since net_shaper_rollback() assumed that entries without VALID can be freed without observing RCU.
Looks like the XArray marks are buying us nothing at this point. Let's convert the code to an explicit valid field. The smp_load_acquire() / smp_store_release() barriers are marginally cleaner.
--- include/net/net_shaper.h | 1 + net/shaper/shaper.c | 45 ++++++++++++++++------------------------ 2 files changed, 19 insertions(+), 27 deletions(-)
include/net/net_shaper.h +1 -0
@@ -53,6 +53,7 @@ struct net_shaper {/* private: */ u32 leaves;/* accounted only for NODE scope */ +bool valid;struct rcu_head rcu; };
net/shaper/shaper.c +18 -27
83 lines not on this page · raw message
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 427/461 crypto/krb5, rxrpc: Fix lack of pre-decrypt/pre-verify length checks
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 2b50aceafe6606ea52ed42aadd1b4d44a188aade ]
Change the krb5 crypto library to provide facilities to precheck the length of the message about to be decrypted or verified.
Fix AF_RXRPC to make use of this to validate DATA packets secured with RxGK.
--- Documentation/crypto/krb5.rst | 17 ++++++++--- crypto/krb5/krb5_api.c | 54 +++++++++++++++++++++++++++++++---- include/crypto/krb5.h | 9 ++++-- include/trace/events/rxrpc.h | 1 + net/rxrpc/rxgk.c | 15 ++++++++-- 5 files changed, 81 insertions(+), 15 deletions(-)
Documentation/crypto/krb5.rst +13 -4
@@ -158,13 +158,22 @@ returned. When a message has been received, the location and size of the data with the message can be determined by calling:: - void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5, - enum krb5_crypto_mode mode, - size_t *_offset, size_t *_len); + int crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5, + enum krb5_crypto_mode mode, + size_t *_offset, size_t *_len); The caller provides the offset and length of the message to the function, which then alters those values to indicate the region containing the data (plus any -padding). It is up to the caller to determine how much padding there is. +padding). It is up to the caller to determine how much padding there is. The +function returns an error if the length is too small or if the mode is +unsupported. An additional function:: + + int crypto_krb5_check_data_len(const struct krb5_enctype *krb5, + enum krb5_crypto_mode mode, + size_t len, size_t min_content); + +is provided to just do a basic check that the decrypted/verified message would +have a sufficient minimum payload. Preparation Functions ---------------------
crypto/krb5/krb5_api.c +48 -6
75 lines not on this page · raw message
include/crypto/krb5.h +6 -3
@@ -121,9 +121,12 @@ size_t crypto_krb5_how_much_buffer(const struct krb5_enctype *krb5,size_t crypto_krb5_how_much_data (const struct krb5_enctype *krb5,enum krb5_crypto_mode mode,size_t *_buffer_size,size_t *_offset); -void crypto_krb5_where_is_the_data (const struct krb5_enctype *krb5, -enum krb5_crypto_mode mode, -size_t *_offset,size_t *_len); +int crypto_krb5_where_is_the_data (const struct krb5_enctype *krb5, +enum krb5_crypto_mode mode, +size_t *_offset,size_t *_len); +int crypto_krb5_check_data_len (const struct krb5_enctype *krb5, +enum krb5_crypto_mode mode, +size_t len,size_t min_content);struct crypto_aead *crypto_krb5_prepare_encryption (const struct krb5_enctype *krb5,const struct krb5_buffer *TK ,u32 usage,gfp_t gfp);
include/trace/events/rxrpc.h +1 -0
@@ -71,6 +71,7 @@ EM(rxkad_abort_resp_unknown_tkt, "rxkad-resp-unknown-tkt") \EM (rxkad_abort_resp_version,"rxkad-resp-version" ) \ /* RxGK security errors */ \ + EM(rxgk_abort_1_short_header, "rxgk1-short-hdr") \ EM(rxgk_abort_1_verify_mic_eproto, "rxgk1-vfy-mic-eproto") \ EM(rxgk_abort_2_decrypt_eproto, "rxgk2-dec-eproto") \EM (rxgk_abort_2_short_data,"rxgk2-short-data" ) \
net/rxrpc/rxgk.c +13 -2
@@ -480,8 +480,12 @@ static int rxgk_verify_packet_integrity(struct rxrpc_call *call,_enter ("" ); -crypto_krb5_where_is_the_data (gk->krb5,KRB5_CHECKSUM_MODE , - &data_offset, &data_len); +if (crypto_krb5_where_is_the_data (gk->krb5,KRB5_CHECKSUM_MODE , + &data_offset, &data_len) <0 ) { + ret =rxrpc_abort_eproto (call, skb,RXGK_PACKETSHORT , + rxgk_abort_1_short_header); + goto put_gk; + } hdr =kzalloc_obj (*hdr,GFP_NOFS );if (!hdr)
@@ -529,6 +533,13 @@ static int rxgk_verify_packet_encrypted(struct rxrpc_call *call,_enter ("" ); +if (crypto_krb5_check_data_len (gk->krb5,KRB5_ENCRYPT_MODE , + len,sizeof (hdr)) <0 ) { + ret =rxrpc_abort_eproto (call, skb,RXGK_PACKETSHORT , + rxgk_abort_2_short_header); + goto error; + } + ret =rxgk_decrypt_skb (gk->krb5, gk->rx_enc, skb, &offset, &len, &ac);if (ret <0 ) {if (ret != -ENOMEM )
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 428/461 rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit d2bc90cf6c75cb96d2ce549be6c35efa3099d25b ]
This improves the fix for CVE-2026-43500.
Fix the pagecache corruption from in-place decryption of a DATA packet transmitted locally by splice() by getting rid of the packet sharing in the I/O thread and unconditionally extracting the packet content into a bounce buffer in which the buffer is decrypted. recvmsg() (or the kernel equivalent) then copies the data from the bounce buffer to the destination buffer. The sk_buff then remains unmodified.
This has an additional advantage in that the packet is then arranged in the buffer with the correct alignment required for the crypto algorithms to process directly. The performance of the crypto does seem to be a little faster and, surprisingly, the unencrypted performance doesn't seem to change much - possibly due to removing complexity from the I/O thread.
Yet another advantage is that the I/O thread doesn't have to copy packets which would slow down packet distribution, ACK generation, etc..
The buffer belongs to the call and is allocated initially at 2K, sufficiently large to hold a whole jumbo subpacket, but the buffer will be increased in size if needed. However, to take this work, MSG_PEEK may cause a later packet to be decrypted into the buffer, in which case the earlier one will need re-decrypting for a subsequent recvmsg().
Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so switch to using USHRT_MAX to indicate an invalid offset.
Note also that I would generally prefer to replace the buffers of the current sk_buff with a new kmalloc'd buffer of the right size, ditching the old data and frags as this makes the handling of MSG_PEEK easier and removes the re-decryption issue, but this looks like quite a complicated thing to achieve. skb_morph() looks half way to what I want, but I don't want to have to allocate a new sk_buff.
--- net/rxrpc/ar-internal.h | 7 +++- net/rxrpc/call_event.c | 22 +---------- net/rxrpc/call_object.c | 2 + net/rxrpc/insecure.c | 3 -- net/rxrpc/recvmsg.c | 68 +++++++++++++++++++++++++------- net/rxrpc/rxgk.c | 51 ++++++++++++------------ net/rxrpc/rxgk_common.h | 82 +++++++++++++++++++++++++++++++++++++++ net/rxrpc/rxkad.c | 86 +++++++++++++++-------------------------- 8 files changed, 201 insertions(+), 120 deletions(-)
net/rxrpc/ar-internal.h +5 -2
@@ -213,8 +213,6 @@ struct rxrpc_skb_priv {struct {u16 offset;/* Offset of data */ u16 len;/* Length of data */ -u8 flags; -#define RXRPC_RX_VERIFIED 0x01 };struct {rxrpc_seq_t first_ack;/* First packet in acks table */
@@ -774,6 +772,11 @@ struct rxrpc_call {struct sk_buff_head recvmsg_queue;/* Queue of packets ready for recvmsg() */ struct sk_buff_head rx_queue;/* Queue of packets for this call to receive */ struct sk_buff_head rx_oos_queue;/* Queue of out of sequence packets */ +void *rx_dec_buffer;/* Decryption buffer */ +unsigned short rx_dec_bsize;/* rx_dec_buffer size */ +unsigned short rx_dec_offset;/* Decrypted packet data offset */ +unsigned short rx_dec_len;/* Decrypted packet data len */ +rxrpc_seq_t rx_dec_seq;/* Packet in decryption buffer */ rxrpc_seq_t rx_highest_seq;/* Higest sequence number received */ rxrpc_seq_t rx_consumed;/* Highest packet consumed */
net/rxrpc/call_event.c +1 -21
@@ -332,27 +332,7 @@ bool rxrpc_input_call_event(struct rxrpc_call *call) saw_ack |= sp->hdr.type ==RXRPC_PACKET_TYPE_ACK ; -if (sp->hdr.type ==RXRPC_PACKET_TYPE_DATA && - sp->hdr.securityIndex !=0 && - (skb_cloned (skb) || -skb_has_frag_list (skb) || -skb_has_shared_frag (skb))) { -/* Unshare the packet so that it can be -* modified by in-place decryption. -*/ -struct sk_buff *nskb =skb_copy (skb,GFP_ATOMIC ); - -if (nskb) { -rxrpc_new_skb (nskb, rxrpc_skb_new_unshared); -rxrpc_input_call_packet (call, nskb); -rxrpc_free_skb (nskb, rxrpc_skb_put_call_rx); - }else { -/* OOM - Drop the packet. */ -rxrpc_see_skb (skb, rxrpc_skb_see_unshare_nomem); - } - }else { -rxrpc_input_call_packet (call, skb); - } +rxrpc_input_call_packet (call, skb);rxrpc_free_skb (skb, rxrpc_skb_put_call_rx); did_receive = true; }
net/rxrpc/call_object.c +2 -0
@@ -152,6 +152,7 @@ struct rxrpc_call *rxrpc_alloc_call(struct rxrpc_sock *rx, gfp_t gfp,spin_lock_init (&call->notify_lock);refcount_set (&call->ref,1 ); call->debug_id = debug_id; + call->rx_pkt_offset =USHRT_MAX ; call->tx_total_len =-1 ; call->tx_jumbo_max =1 ; call->next_rx_timo =20 *HZ ;
@@ -553,6 +554,7 @@ static void rxrpc_cleanup_rx_buffers(struct rxrpc_call *call)rxrpc_purge_queue (&call->recvmsg_queue);rxrpc_purge_queue (&call->rx_queue);rxrpc_purge_queue (&call->rx_oos_queue); +kfree (call->rx_dec_buffer); }/*
net/rxrpc/insecure.c +0 -3
@@ -32,9 +32,6 @@ static int none_secure_packet(struct rxrpc_call *call, struct rxrpc_txbuf *txb)static int none_verify_packet (struct rxrpc_call *call,struct sk_buff *skb) { -struct rxrpc_skb_priv *sp =rxrpc_skb (skb); - - sp->flags |=RXRPC_RX_VERIFIED ;return 0 ; }
net/rxrpc/recvmsg.c +55 -13
103 lines not on this page · raw message
net/rxrpc/rxgk.c +24 -27
104 lines not on this page · raw message
net/rxrpc/rxgk_common.h +82 -0
91 lines not on this page · raw message
net/rxrpc/rxkad.c +32 -54
166 lines not on this page · raw message
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 429/461 net: ag71xx: check error for platform_get_irq
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rosen Penev <[email protected]>
[ Upstream commit e7c70bf97e90d974cd575e4c90f8f9b07d056da3 ]
Complete error handling for a failed platform_get_irq() call
--- drivers/net/ethernet/atheros/ag71xx.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/atheros/ag71xx.c +3 -0
@@ -1856,6 +1856,9 @@ static int ag71xx_probe(struct platform_device *pdev)ag71xx_int_disable (ag,AG71XX_INT_POLL ); ndev->irq =platform_get_irq (pdev,0 ); +if (ndev->irq <0 ) +return ndev->irq; + err =devm_request_irq (&pdev->dev, ndev->irq, ag71xx_interrupt,0x0 ,dev_name (&pdev->dev), ndev);if (err) {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 430/461 bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xingwang Xiang <[email protected]>
[ Upstream commit ddf8029623a1af20e984c040e89ff918158397ab ]
sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls").
sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival:
tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready
-> saved_data_ready() = sk_psock_verdict_data_ready()
-> tcp_read_skb() drains sk_receive_queue via __skb_unlink()
without calling tcp_eat_skb(), so copied_seq is not advanced.tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks thatfrag_list: use-after-free.
Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().
--- net/core/skmsg.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
net/core/skmsg.c +7 -2
@@ -1268,12 +1268,19 @@ static int sk_psock_verdict_recv(struct sock *sk, struct sk_buff *skb)static void sk_psock_verdict_data_ready (struct sock *sk) {const struct proto_ops *ops =NULL ; +struct sk_psock *psock;struct socket *sock;int copied;trace_sk_data_ready (sk);rcu_read_lock (); + psock =sk_psock (sk); +if (psock &&tls_sw_has_ctx_rx (sk)) { + psock->saved_data_ready (sk); +rcu_read_unlock (); +return ; + } sock =READ_ONCE (sk->sk_socket);if (likely (sock)) ops =READ_ONCE (sock->ops);
@@ -1283,8 +1290,6 @@ static void sk_psock_verdict_data_ready(struct sock *sk) copied = ops->read_skb (sk, sk_psock_verdict_recv);if (copied >=0 ) { -struct sk_psock *psock; -rcu_read_lock (); psock =sk_psock (sk);if (psock)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 431/461 tcp: fix stale per-CPU tcp_tw_isn leak enabling ISN prediction
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 1bbf0ced1d9db73ac7893c2187f3459288603e0d ]
Blamed commit moved the TIME_WAIT-derived ISN from the skb control block to a per-CPU variable, assuming the value would always be consumed by tcp_conn_request() for the same packet that wrote it. That assumption is violated by multiple drop paths between the producer (__this_cpu_write(tcp_tw_isn, isn) in tcp_v{4,6}_rcv()) and the consumer (tcp_conn_request()):
- min_ttl / min_hopcount check
- xfrm policy check
- tcp_inbound_hash() MD5/AO mismatch
- tcp_filter() eBPF/SO_ATTACH_FILTER drop
- th->syn && th->fin discard in tcp_rcv_state_process() TCP_LISTEN
- psp_sk_rx_policy_check() in tcp_v{4,6}_do_rcv()
- tcp_checksum_complete() in tcp_v{4,6}_do_rcv()
- tcp_v{4,6}_cookie_check() returning NULL
When a packet is dropped on any of these paths, tcp_tw_isn is left set.
The next SYN processed on the same CPU then consumes the non zero value in tcp_conn_request(), receiving a potentially predictable ISN.
This patch moves back tcp_tw_isn to skb->cb[], getting rid of the per-cpu variable.
Note that tcp_v{4,6}_fill_cb() do not set it.
Very litle impact on overall code size/complexity:
$ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7) Function old new delta tcp_v6_rcv 3038 3042 +4 tcp_v4_rcv 3035 3039 +4 tcp_conn_request 2938 2923 -15 Total: Before=24436060, After=24436053, chg -0.00%
--- include/net/tcp.h | 7 ++++--- net/ipv4/tcp.c | 3 --- net/ipv4/tcp_input.c | 15 ++++++--------- net/ipv4/tcp_ipv4.c | 3 ++- net/ipv6/tcp_ipv6.c | 3 ++- 5 files changed, 14 insertions(+), 17 deletions(-)
include/net/tcp.h +4 -3
@@ -65,8 +65,6 @@ static inline void tcp_orphan_count_dec(void)this_cpu_dec (tcp_orphan_count); } -DECLARE_PER_CPU (u32, tcp_tw_isn); -void tcp_time_wait (struct sock *sk,int state,int timeo);#define MAX_TCP_HEADER L1_CACHE_ALIGN(128 + MAX_HEADER)
@@ -1060,10 +1058,13 @@ struct tcp_skb_cb {__u32 seq;/* Starting sequence number */ __u32 end_seq;/* SEQ + FIN + SYN + datalen */ union { -/* Note : +/* Notes : +* tcp_tw_isn is used in input path only +* (isn chosen by tcp_timewait_state_process()) * tcp_gso_segs/size are used in write queue only, * cf tcp_skb_pcount()/tcp_skb_mss() */ +u32 tcp_tw_isn;struct {u16 tcp_gso_segs;u16 tcp_gso_size;
net/ipv4/tcp.c +0 -3
@@ -299,9 +299,6 @@ enum { DEFINE_PER_CPU(unsigned int, tcp_orphan_count);EXPORT_PER_CPU_SYMBOL_GPL (tcp_orphan_count); -DEFINE_PER_CPU (u32, tcp_tw_isn); -EXPORT_PER_CPU_SYMBOL_GPL (tcp_tw_isn); -long sysctl_tcp_mem[3 ]__read_mostly ;EXPORT_IPV6_MOD (sysctl_tcp_mem);
net/ipv4/tcp_input.c +6 -9
@@ -7648,6 +7648,7 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops, struct sock *sk, struct sk_buff *skb) { struct tcp_fastopen_cookie foc = { .len = -1 }; +u32 isn =TCP_SKB_CB (skb)->tcp_tw_isn;struct tcp_options_received tmp_opt;const struct tcp_sock *tp =tcp_sk (sk);struct net *net =sock_net (sk);
@@ -7658,20 +7659,16 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops,struct dst_entry *dst;struct flowi fl;u8 syncookies; -u32 isn;#ifdef CONFIG_TCP_AO const struct tcp_ao_hdr *aoh;#endif - isn =__this_cpu_read (tcp_tw_isn); -if (isn) { -/* TW buckets are converted to open requests without -* limitations, they conserve resources and peer is -* evidently real one. -*/ -__this_cpu_write (tcp_tw_isn,0 ); - }else { +/* If isn is non-zero, this SYN originally matched a TIME_WAIT socket. +* TW sockets are converted to open requests without limitations, +* we skip the queue limits and syncookie checks in the block below. +*/ +if (!isn) { syncookies =READ_ONCE (net->ipv4.sysctl_tcp_syncookies);if (syncookies ==2 ||inet_csk_reqsk_queue_is_full (sk)) {
net/ipv4/tcp_ipv4.c +2 -1
@@ -2274,6 +2274,7 @@ int tcp_v4_rcv(struct sk_buff *skb) } } + isn =0 ; process:if (static_branch_unlikely (&ip4_min_ttl)) {/* min_ttl can be changed concurrently from do_ip_setsockopt() */
@@ -2302,6 +2303,7 @@ int tcp_v4_rcv(struct sk_buff *skb) th = (const struct tcphdr *)skb->data; iph =ip_hdr (skb);tcp_v4_fill_cb (skb, iph, th); +TCP_SKB_CB (skb)->tcp_tw_isn = isn; skb->dev =NULL ;
@@ -2387,7 +2389,6 @@ int tcp_v4_rcv(struct sk_buff *skb) sk = sk2;tcp_v4_restore_cb (skb); refcounted = false; -__this_cpu_write (tcp_tw_isn, isn); goto process; }
net/ipv6/tcp_ipv6.c +2 -1
@@ -1818,6 +1818,7 @@ INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb) } } + isn =0 ; process:if (static_branch_unlikely (&ip6_min_hopcount)) {/* min_hopcount can be changed concurrently from do_ipv6_setsockopt() */
@@ -1846,6 +1847,7 @@ INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb) th = (const struct tcphdr *)skb->data; hdr =ipv6_hdr (skb);tcp_v6_fill_cb (skb, hdr, th); +TCP_SKB_CB (skb)->tcp_tw_isn = isn; skb->dev =NULL ;
@@ -1933,7 +1935,6 @@ INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb) sk = sk2;tcp_v6_restore_cb (skb); refcounted = false; -__this_cpu_write (tcp_tw_isn, isn); goto process; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 432/461 net: stmmac: eswin: fix HSP CSR init ordering after clock enable
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhi Li <[email protected]>
[ Upstream commit 23386defe949c0db4f746bed7098fc5e06746083 ]
Fix the initialization ordering of the HSP CSR configuration in the EIC7700 DWMAC glue driver.
The HSP CSR registers control MAC-side RGMII delay behavior and must only be accessed after the corresponding clocks are enabled. The previous implementation could trigger register access before clock enablement, leading to undefined behavior depending on boot state.
Move the HSP CSR configuration into the post-clock-enable initialization path to ensure all register accesses occur under valid clock domains.
This change ensures deterministic initialization and prevents clock-dependent register access failures during probe or resume.
--- .../ethernet/stmicro/stmmac/dwmac-eic7700.c | 73 +++++++++++-------- 1 file changed, 41 insertions(+), 32 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c +41 -32
@@ -42,6 +42,11 @@ static const char * const eic7700_clk_names[] = {struct eic7700_qos_priv {struct plat_stmmacenet_data *plat_dat; +struct regmap *eic7700_hsp_regmap; +u32 eth_axi_lp_ctrl_offset; +u32 eth_phy_ctrl_offset; +u32 eth_clk_offset; +u32 eth_clk_dly_param; };static int eic7700_clks_config (void *priv,bool enabled)
@@ -61,8 +66,28 @@ static int eic7700_clks_config(void *priv, bool enabled)static int eic7700_dwmac_init (struct device *dev,void *priv) {struct eic7700_qos_priv *dwc = priv; +int ret; + + ret =eic7700_clks_config (dwc, true); +if (ret) +return ret; + + ret =regmap_set_bits (dwc->eic7700_hsp_regmap, + dwc->eth_phy_ctrl_offset, +EIC7700_ETH_TX_CLK_SEL | +EIC7700_ETH_PHY_INTF_SELI ); +if (ret) { +eic7700_clks_config (dwc, false); +return ret; + } + +regmap_write (dwc->eic7700_hsp_regmap, dwc->eth_axi_lp_ctrl_offset, +EIC7700_ETH_CSYSREQ_VAL ); -return eic7700_clks_config (dwc, true); +regmap_write (dwc->eic7700_hsp_regmap, dwc->eth_clk_offset, + dwc->eth_clk_dly_param); + +return 0 ; }static void eic7700_dwmac_exit (struct device *dev,void *priv)
@@ -93,12 +118,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)struct plat_stmmacenet_data *plat_dat;struct stmmac_resources stmmac_res;struct eic7700_qos_priv *dwc_priv; -struct regmap *eic7700_hsp_regmap; -u32 eth_axi_lp_ctrl_offset; -u32 eth_phy_ctrl_offset; -u32 eth_phy_ctrl_regset; -u32 eth_rxd_dly_offset; -u32 eth_dly_param =0 ;u32 delay_ps;int i, ret;
@@ -121,8 +140,9 @@ static int eic7700_dwmac_probe(struct platform_device *pdev) "rx-internal-delay-ps", &delay_ps)) { u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT); - eth_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY; - eth_dly_param |= FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val); + dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY; + dwc_priv->eth_clk_dly_param |= + FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val); } else {return dev_err_probe (&pdev->dev, -EINVAL ,"missing required property rx-internal-delay-ps\n" );
@@ -133,53 +153,42 @@ static int eic7700_dwmac_probe(struct platform_device *pdev) "tx-internal-delay-ps", &delay_ps)) { u32 val = min(delay_ps / 100, EIC7700_MAX_DELAY_UNIT); - eth_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY; - eth_dly_param |= FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val); + dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY; + dwc_priv->eth_clk_dly_param |= + FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val); } else {return dev_err_probe (&pdev->dev, -EINVAL ,"missing required property tx-internal-delay-ps\n" ); } - eic7700_hsp_regmap =syscon_regmap_lookup_by_phandle (pdev->dev.of_node, -"eswin,hsp-sp-csr" ); -if (IS_ERR (eic7700_hsp_regmap)) + dwc_priv->eic7700_hsp_regmap = +syscon_regmap_lookup_by_phandle (pdev->dev.of_node, +"eswin,hsp-sp-csr" ); +if (IS_ERR (dwc_priv->eic7700_hsp_regmap))return dev_err_probe (&pdev->dev, -PTR_ERR (eic7700_hsp_regmap), +PTR_ERR (dwc_priv->eic7700_hsp_regmap),"Failed to get hsp-sp-csr regmap\n" ); ret =of_property_read_u32_index (pdev->dev.of_node,"eswin,hsp-sp-csr" , -1 , ð_phy_ctrl_offset); +1 , &dwc_priv->eth_phy_ctrl_offset);if (ret)return dev_err_probe (&pdev->dev, ret,"can't get eth_phy_ctrl_offset\n" ); -regmap_read (eic7700_hsp_regmap, eth_phy_ctrl_offset, - ð_phy_ctrl_regset); - eth_phy_ctrl_regset |= - (EIC7700_ETH_TX_CLK_SEL |EIC7700_ETH_PHY_INTF_SELI ); -regmap_write (eic7700_hsp_regmap, eth_phy_ctrl_offset, - eth_phy_ctrl_regset); - ret =of_property_read_u32_index (pdev->dev.of_node,"eswin,hsp-sp-csr" , -2 , ð_axi_lp_ctrl_offset); +2 , &dwc_priv->eth_axi_lp_ctrl_offset);if (ret)return dev_err_probe (&pdev->dev, ret,"can't get eth_axi_lp_ctrl_offset\n" ); -regmap_write (eic7700_hsp_regmap, eth_axi_lp_ctrl_offset, -EIC7700_ETH_CSYSREQ_VAL ); - ret =of_property_read_u32_index (pdev->dev.of_node,"eswin,hsp-sp-csr" , -3 , ð_rxd_dly_offset); +3 , &dwc_priv->eth_clk_offset);if (ret)return dev_err_probe (&pdev->dev, ret, -"can't get eth_rxd_dly_offset\n" ); - -regmap_write (eic7700_hsp_regmap, eth_rxd_dly_offset, - eth_dly_param); +"can't get eth_clk_offset\n" ); plat_dat->num_clks =ARRAY_SIZE (eic7700_clk_names); plat_dat->clks = devm_kcalloc(&pdev->dev,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 433/461 net: stmmac: eswin: clear TXD and RXD delay registers during initialization
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhi Li <[email protected]>
[ Upstream commit 6872fb088edc1a3c36792b301f8e4a1c35dd7c35 ]
Clear the TXD and RXD delay control registers during EIC7700 DWMAC initialization.
These registers may retain values programmed by the bootloader. If left unchanged, residual delays can alter the effective RGMII timing seen by the MAC and override the configuration described by the device tree.
This may violate the expected RGMII timing model and can cause link instability or prevent the Ethernet controller from operating correctly.
Explicitly clearing these registers ensures that the MAC delay settings are determined solely by the kernel configuration.
The corresponding register offsets are optional, and the registers are only cleared when the offsets are provided in the device tree.
--- .../ethernet/stmicro/stmmac/dwmac-eic7700.c | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+)
drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c +22 -0
@@ -46,7 +46,11 @@ struct eic7700_qos_priv {u32 eth_axi_lp_ctrl_offset;u32 eth_phy_ctrl_offset;u32 eth_clk_offset; +u32 eth_txd_offset; +u32 eth_rxd_offset;u32 eth_clk_dly_param; +bool has_txd_offset; +bool has_rxd_offset; };static int eic7700_clks_config (void *priv,bool enabled)
@@ -84,6 +88,12 @@ static int eic7700_dwmac_init(struct device *dev, void *priv)regmap_write (dwc->eic7700_hsp_regmap, dwc->eth_axi_lp_ctrl_offset,EIC7700_ETH_CSYSREQ_VAL ); +if (dwc->has_txd_offset) +regmap_write (dwc->eic7700_hsp_regmap, dwc->eth_txd_offset,0 ); + +if (dwc->has_rxd_offset) +regmap_write (dwc->eic7700_hsp_regmap, dwc->eth_rxd_offset,0 ); +regmap_write (dwc->eic7700_hsp_regmap, dwc->eth_clk_offset, dwc->eth_clk_dly_param);
@@ -190,6 +200,18 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)return dev_err_probe (&pdev->dev, ret,"can't get eth_clk_offset\n" ); + ret =of_property_read_u32_index (pdev->dev.of_node, +"eswin,hsp-sp-csr" , +4 , &dwc_priv->eth_txd_offset); +if (!ret) + dwc_priv->has_txd_offset = true; + + ret =of_property_read_u32_index (pdev->dev.of_node, +"eswin,hsp-sp-csr" , +5 , &dwc_priv->eth_rxd_offset); +if (!ret) + dwc_priv->has_rxd_offset = true; + plat_dat->num_clks =ARRAY_SIZE (eic7700_clk_names); plat_dat->clks = devm_kcalloc(&pdev->dev, plat_dat->num_clks,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 434/461 net: stmmac: eswin: correct RGMII delay granularity to 20 ps
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhi Li <[email protected]>
[ Upstream commit 6ffcef9bc1fc2ad8110777decd6d026e3cb468ce ]
The EIC7700 MAC implements programmable RGMII delay adjustment with a granularity of 20 ps per hardware step.
The driver previously converted rx-internal-delay-ps and tx-internal-delay-ps values using a 100 ps step size, resulting in incorrect delay programming.
Update the conversion to use the correct 20 ps granularity so the programmed delay matches the values described in the device tree.
--- drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c +4 -4
@@ -28,8 +28,8 @@/* * TX/RX Clock Delay Bit Masks: -* - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.1ns per bit) -* - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.1ns per bit) +* - TX Delay: bits [14:8] — TX_CLK delay (unit: 0.02ns per bit) +* - RX Delay: bits [30:24] — RX_CLK delay (unit: 0.02ns per bit) */ #define EIC7700_ETH_TX_ADJ_DELAY GENMASK(14, 8)#define EIC7700_ETH_RX_ADJ_DELAY GENMASK(30, 24)
@@ -148,7 +148,7 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)/* Read rx-internal-delay-ps and update rx_clk delay */ if (!of_property_read_u32 (pdev->dev.of_node,"rx-internal-delay-ps" , &delay_ps)) { -u32 val =min (delay_ps /100 ,EIC7700_MAX_DELAY_UNIT ); +u32 val =min (delay_ps /20 ,EIC7700_MAX_DELAY_UNIT ); dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY ; dwc_priv->eth_clk_dly_param |=
@@ -161,7 +161,7 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)/* Read tx-internal-delay-ps and update tx_clk delay */ if (!of_property_read_u32 (pdev->dev.of_node,"tx-internal-delay-ps" , &delay_ps)) { -u32 val =min (delay_ps /100 ,EIC7700_MAX_DELAY_UNIT ); +u32 val =min (delay_ps /20 ,EIC7700_MAX_DELAY_UNIT ); dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY ; dwc_priv->eth_clk_dly_param |=
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 435/461 net: stmmac: eswin: validate RGMII delay values
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhi Li <[email protected]>
[ Upstream commit c2e152f7ce3208b9333d212d41a87637ec1dd170 ]
Validate rx-internal-delay-ps and tx-internal-delay-ps against the hardware capabilities of the EIC7700 MAC.
The programmable RGMII delay supports 20 ps steps and a maximum value of 2540 ps. The driver previously accepted arbitrary values and silently truncated unsupported settings when converting them to hardware units.
As a result, invalid device tree values could lead to unexpected delay programming and incorrect RGMII timing.
Reject delay values that are not multiples of 20 ps or exceed the supported hardware range.
--- .../ethernet/stmicro/stmmac/dwmac-eic7700.c | 29 ++++++++++++++++--- 1 file changed, 25 insertions(+), 4 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c +25 -4
@@ -34,7 +34,10 @@#define EIC7700_ETH_TX_ADJ_DELAY GENMASK(14, 8)#define EIC7700_ETH_RX_ADJ_DELAY GENMASK(30, 24) -#define EIC7700_MAX_DELAY_UNIT 0x7F +#define EIC7700_MAX_DELAY_STEPS 0x7F +#define EIC7700_DELAY_STEP_PS 20 +#define EIC7700_MAX_DELAY_PS \ + (EIC7700_MAX_DELAY_STEPS * EIC7700_DELAY_STEP_PS)static const char *const eic7700_clk_names[] = {"tx" ,"axi" ,"cfg" ,
@@ -128,7 +131,7 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)struct plat_stmmacenet_data *plat_dat;struct stmmac_resources stmmac_res;struct eic7700_qos_priv *dwc_priv; -u32 delay_ps; +u32 delay_ps, val;int i, ret; ret =stmmac_get_platform_resources (pdev, &stmmac_res);
@@ -148,7 +151,16 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)/* Read rx-internal-delay-ps and update rx_clk delay */ if (!of_property_read_u32 (pdev->dev.of_node,"rx-internal-delay-ps" , &delay_ps)) { -u32 val =min (delay_ps /20 ,EIC7700_MAX_DELAY_UNIT ); +if (delay_ps %EIC7700_DELAY_STEP_PS ) +return dev_err_probe (&pdev->dev, -EINVAL , +"rx delay must be multiple of %dps\n" , +EIC7700_DELAY_STEP_PS ); + +if (delay_ps >EIC7700_MAX_DELAY_PS ) +return dev_err_probe (&pdev->dev, -EINVAL , +"rx delay out of range\n" ); + + val = delay_ps /EIC7700_DELAY_STEP_PS ; dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY ; dwc_priv->eth_clk_dly_param |=
@@ -161,7 +173,16 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)/* Read tx-internal-delay-ps and update tx_clk delay */ if (!of_property_read_u32 (pdev->dev.of_node,"tx-internal-delay-ps" , &delay_ps)) { -u32 val =min (delay_ps /20 ,EIC7700_MAX_DELAY_UNIT ); +if (delay_ps %EIC7700_DELAY_STEP_PS ) +return dev_err_probe (&pdev->dev, -EINVAL , +"tx delay must be multiple of %dps\n" , +EIC7700_DELAY_STEP_PS ); + +if (delay_ps >EIC7700_MAX_DELAY_PS ) +return dev_err_probe (&pdev->dev, -EINVAL , +"tx delay out of range\n" ); + + val = delay_ps /EIC7700_DELAY_STEP_PS ; dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY ; dwc_priv->eth_clk_dly_param |=
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 436/461 gpio: cdev: check if uAPI v2 config attributes are correctly zeroed
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit 3e6ccd790ed69bedd3d9626d01dd35cf9821c121 ]
We check the padding of other uAPI v2 structures but not that of line config attributes. For used attributes: check if their padding is zeroed, for unused: check if the entire structure is zeroed.
--- drivers/gpio/gpiolib-cdev.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/gpio/gpiolib-cdev.c +13 -0
@@ -1184,6 +1184,7 @@ static int gpio_v2_line_flags_validate(u64 flags)static int gpio_v2_line_config_validate (struct gpio_v2_line_config *lc,unsigned int num_lines) { +size_t unused_attrs;unsigned int i;u64 flags;int ret;
@@ -1191,9 +1192,21 @@ static int gpio_v2_line_config_validate(struct gpio_v2_line_config *lc,if (lc->num_attrs >GPIO_V2_LINE_NUM_ATTRS_MAX )return -EINVAL ; + unused_attrs =GPIO_V2_LINE_NUM_ATTRS_MAX - lc->num_attrs; +if (!mem_is_zero (lc->padding,sizeof (lc->padding)))return -EINVAL ; +for (i =0 ; i < lc->num_attrs; i++) { +if (lc->attrs[i].attr.padding !=0 ) +return -EINVAL ; + } + +if (unused_attrs) { +if (!mem_is_zero (&lc->attrs[lc->num_attrs], unused_attrs *sizeof (*lc->attrs))) +return -EINVAL ; + } +for (i =0 ; i < num_lines; i++) { flags =gpio_v2_line_config_flags (lc, i); ret =gpio_v2_line_flags_validate (flags);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 437/461 gpio: aggregator: fix a potential use-after-free
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit 30c073cab97afb31901f94de9605177b6b84367e ]
On error we free aggr->lookups->dev_id before removing the entry from the lookup table. If a concurrent thread calls gpiod_find() before we remove the entry, it could iterate over the list and call gpiod_match_lookup_table() which unconditionally dereferences dev_id when calling strcmp(). Reverse the order of cleanup.
--- drivers/gpio/gpio-aggregator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-aggregator.c +1 -1
@@ -969,8 +969,8 @@ static int gpio_aggregator_activate(struct gpio_aggregator *aggr)return 0 ; err_remove_lookup_table: -kfree (aggr->lookups->dev_id);gpiod_remove_lookup_table (aggr->lookups); +kfree (aggr->lookups->dev_id); err_remove_swnode:fwnode_remove_software_node (swnode); err_remove_lookups:
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 438/461 gpio: aggregator: stop using dev-sync-probe
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit 3a27f40b457053e6112a63d14590e4a3ff553b44 ]
dev-err-probe is an overengineered solution to a simple problem. Use a combination of wait_for_probe() and device_is_bound() to synchronously wait for the platform device to probe.
Stable-dep-of: 61fef83f239e ("gpio: aggregator: remove the software node when deactivating the aggregator")
--- drivers/gpio/Kconfig | 1 - drivers/gpio/gpio-aggregator.c | 38 +++++++++++++++++++--------------- 2 files changed, 21 insertions(+), 18 deletions(-)
drivers/gpio/Kconfig +0 -1
@@ -1986,7 +1986,6 @@ menu "Virtual GPIO drivers" config GPIO_AGGREGATOR tristate "GPIO Aggregator" select CONFIGFS_FS - select DEV_SYNC_PROBE help Say yes here to enable the GPIO Aggregator, which provides a way to aggregate existing GPIO lines into a new virtual GPIO chip.
drivers/gpio/gpio-aggregator.c +21 -17
@@ -32,8 +32,6 @@#include <linux/gpio/forwarder.h> #include <linux/gpio/machine.h> -#include "dev-sync-probe.h" -#define AGGREGATOR_MAX_GPIOS 512#define AGGREGATOR_LEGACY_PREFIX "_sysfs"
@@ -42,7 +40,7 @@*/ struct gpio_aggregator { -struct dev_sync_probe_data probe_data; +struct platform_device *pdev;struct config_group group;struct gpiod_lookup_table *lookups;struct mutex lock;
@@ -135,7 +133,7 @@ static bool gpio_aggregator_is_active(struct gpio_aggregator *aggr) {lockdep_assert_held (&aggr->lock); -return aggr->probe_data.pdev &&platform_get_drvdata (aggr->probe_data.pdev); +return aggr->pdev &&platform_get_drvdata (aggr->pdev); }/* Only aggregators created via legacy sysfs can be "activating". */
@@ -143,7 +141,7 @@ static bool gpio_aggregator_is_activating(struct gpio_aggregator *aggr) {lockdep_assert_held (&aggr->lock); -return aggr->probe_data.pdev && !platform_get_drvdata (aggr->probe_data.pdev); +return aggr->pdev && !platform_get_drvdata (aggr->pdev); }static size_t gpio_aggregator_count_lines (struct gpio_aggregator *aggr)
@@ -909,6 +907,7 @@ static int gpio_aggregator_activate(struct gpio_aggregator *aggr) {struct platform_device_info pdevinfo;struct gpio_aggregator_line *line; +struct platform_device *pdev;struct fwnode_handle *swnode;unsigned int n =0 ;int ret =0 ;
@@ -962,12 +961,23 @@ static int gpio_aggregator_activate(struct gpio_aggregator *aggr)gpiod_add_lookup_table (aggr->lookups); - ret =dev_sync_probe_register (&aggr->probe_data, &pdevinfo); -if (ret) + pdev =platform_device_register_full (&pdevinfo); +if (IS_ERR (pdev)) { + ret =PTR_ERR (pdev); goto err_remove_lookup_table; + } +wait_for_device_probe (); +if (!device_is_bound (&pdev->dev)) { + ret = -ENXIO ; + goto err_unregister_pdev; + } + + aggr->pdev = pdev;return 0 ; +err_unregister_pdev: +platform_device_unregister (pdev); err_remove_lookup_table:gpiod_remove_lookup_table (aggr->lookups);kfree (aggr->lookups->dev_id);
@@ -981,7 +991,8 @@ static int gpio_aggregator_activate(struct gpio_aggregator *aggr)static void gpio_aggregator_deactivate (struct gpio_aggregator *aggr) { -dev_sync_probe_unregister (&aggr->probe_data); +platform_device_unregister (aggr->pdev); + aggr->pdev =NULL ;gpiod_remove_lookup_table (aggr->lookups);kfree (aggr->lookups->dev_id);kfree (aggr->lookups);
@@ -1145,7 +1156,7 @@ gpio_aggregator_device_dev_name_show(struct config_item *item, char *page)guard (mutex)(&aggr->lock); - pdev = aggr->probe_data.pdev; + pdev = aggr->pdev;if (pdev)return sysfs_emit (page,"%s\n" ,dev_name (&pdev->dev));
@@ -1322,7 +1333,6 @@ gpio_aggregator_make_group(struct config_group *group, const char *name)return ERR_PTR (ret);config_group_init_type_name (&aggr->group, name, &gpio_aggregator_device_type); -dev_sync_probe_init (&aggr->probe_data);return &aggr->group; }
@@ -1471,12 +1481,6 @@ static ssize_t gpio_aggregator_new_device_store(struct device_driver *driver,scnprintf (name,sizeof (name),"%s.%d" ,AGGREGATOR_LEGACY_PREFIX , aggr->id);config_group_init_type_name (&aggr->group, name, &gpio_aggregator_device_type); -/* -* Since the device created by sysfs might be toggled via configfs -* 'live' attribute later, this initialization is needed. -*/ -dev_sync_probe_init (&aggr->probe_data); -/* Expose to configfs */ res =configfs_register_group (&gpio_aggregator_subsys.su_group, &aggr->group);
@@ -1495,7 +1499,7 @@ static ssize_t gpio_aggregator_new_device_store(struct device_driver *driver, goto remove_table; } - aggr->probe_data.pdev = pdev; + aggr->pdev = pdev;module_put (THIS_MODULE );return count;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 439/461 gpio: aggregator: remove the software node when deactivating the aggregator
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit 61fef83f239ecace1cce716135762a2d9b7b1fc6 ]
The dynamic software node we create for the aggregator platform device when using configfs is leaked when the device is deactivated. Destroy it as the last step in the tear-down path.
--- drivers/gpio/gpio-aggregator.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpio/gpio-aggregator.c +4 -0
@@ -991,11 +991,15 @@ static int gpio_aggregator_activate(struct gpio_aggregator *aggr)static void gpio_aggregator_deactivate (struct gpio_aggregator *aggr) { +struct fwnode_handle *swnode; + + swnode =dev_fwnode (&aggr->pdev->dev);platform_device_unregister (aggr->pdev); aggr->pdev =NULL ;gpiod_remove_lookup_table (aggr->lookups);kfree (aggr->lookups->dev_id);kfree (aggr->lookups); +fwnode_remove_software_node (swnode); } static void gpio_aggregator_lockup_configfs(struct gpio_aggregator *aggr,
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 440/461 gpio: aggregator: lock device when calling device_is_bound()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit 598a2b3e2e0e6aa2e9f7843c96c45b5ea11e0411 ]
The kerneldoc for device_is_bound() says it must be called with the device lock taken. Add missing synchronization to this driver.
--- drivers/gpio/gpio-aggregator.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/gpio/gpio-aggregator.c +6 -3
@@ -968,9 +968,12 @@ static int gpio_aggregator_activate(struct gpio_aggregator *aggr) }wait_for_device_probe (); -if (!device_is_bound (&pdev->dev)) { - ret = -ENXIO ; - goto err_unregister_pdev; + + scoped_guard(device, &pdev->dev) { +if (!device_is_bound (&pdev->dev)) { + ret = -ENXIO ; + goto err_unregister_pdev; + } } aggr->pdev = pdev;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 441/461 ASoC: cs35l56: Fix flushing of IRQ work in cs35l56_sdw_remove()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit 18e7bd9f2446664053f8c34b72abd4606d22d858 ]
Use flush_work() instead of cancel_work_sync() to terminate pending IRQ work in cs35l56_sdw_remove(). And flush_work() again after masking the interrupts to flush any queueing that was racing with the masking. This is the same sequence as cs35l56_sdw_system_suspend().
cs35l56_sdw_interrupt() takes the pm_runtime to prevent the bus powering- down before the interrupt status can be read and handled. The work releases this pm_runtime. So cancelling it, instead of flushing, could leave an unbalanced pm_runtime.
--- sound/soc/codecs/cs35l56-sdw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/soc/codecs/cs35l56-sdw.c +2 -1
@@ -560,10 +560,11 @@ static void cs35l56_sdw_remove(struct sdw_slave *peripheral)/* Disable SoundWire interrupts */ cs35l56->sdw_irq_no_unmask = true; -cancel_work_sync (&cs35l56->sdw_irq_work); +flush_work (&cs35l56->sdw_irq_work);sdw_write_no_pm (peripheral,CS35L56_SDW_GEN_INT_MASK_1 ,0 );sdw_read_no_pm (peripheral,CS35L56_SDW_GEN_INT_STAT_1 );sdw_write_no_pm (peripheral,CS35L56_SDW_GEN_INT_STAT_1 ,0xFF ); +flush_work (&cs35l56->sdw_irq_work);cs35l56_remove (cs35l56); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 442/461 drm/xe/oa: Fix exec_queue leak on width check in stream open
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuicheng Lin <[email protected]>
[ Upstream commit 4d25342543c01310fc4e0cba7cb17c775e2421e2 ]
In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked.
The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely.
Jump to err_exec_q instead of returning directly so the reference is released.
--- drivers/gpu/drm/xe/xe_oa.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/xe_oa.c +4 -2
@@ -2048,8 +2048,10 @@ int xe_oa_stream_open_ioctl(struct drm_device *dev, u64 data, struct drm_file *fif (XE_IOCTL_DBG (oa->xe, !param.exec_q))return -ENOENT ; -if (XE_IOCTL_DBG (oa->xe, param.exec_q->width >1 )) -return -EOPNOTSUPP ; +if (XE_IOCTL_DBG (oa->xe, param.exec_q->width >1 )) { + ret = -EOPNOTSUPP ; + goto err_exec_q; + } }/*
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 443/461 ASoC: cs-amp-lib: Fix wrong sizeof() in _cs_amp_set_efi_calibration_data()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit 67a52d3ebb5a0ae0c0e23ffa99470d9463179c9f ]
When calculating data->count replace the incorrect sizeof(data) with use of struct_offset().
The faulty sizeof(data) was incorrectly calculating the size of the pointer instead of the size of the struct pointed to. As it happens, both values are 8 on a 64-bit CPU. In the unlikely event of using this code on a 32-bit CPU the number of available bytes would be calculated 4 larger than is actually available.
Instead of changing to sizeof(*data) it has been replaced by struct_offset() because it has better chance of detecting these sorts of typos. Also the offset of the data[] array is actually what we want to know here anyway.
--- sound/soc/codecs/cs-amp-lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/cs-amp-lib.c +1 -1
@@ -500,7 +500,7 @@ static int _cs_amp_set_efi_calibration_data(struct device *dev, int amp_index, i* must be set. */ if (data->count ==0 ) - data->count = (data->size -sizeof (data)) /sizeof (data->data[0 ]); + data->count = (data->size -struct_offset (data, data)) /sizeof (data->data[0 ]);if (amp_index <0 ) {/* Is there already a slot for this target? */
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 444/461 ASoC: cs-amp-lib: Fix missing dput() after debugfs_lookup()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit ba28a07a9a0b53a538c809e04e517e1ce1f1bee3 ]
Rewrite cs_amp_create_debugfs() so that dput() will be called on a valid dentry returned from debugfs_lookup().
The pointer returned from debugfs_lookup() must be released by dput(). The pointer returned from debugfs_create_dir() does not need to be passed to dput().
--- sound/soc/codecs/cs-amp-lib.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
sound/soc/codecs/cs-amp-lib.c +10 -3
@@ -831,11 +831,18 @@ EXPORT_SYMBOL_NS_GPL(cs_amp_devm_get_vendor_specific_variant_id, "SND_SOC_CS_AMP*/ struct dentry *cs_amp_create_debugfs (struct device *dev) { -struct dentry *dir; +struct dentry *dir, *created; +/* debugfs_lookup() can return NULL or ERR_PTR on error */ dir =debugfs_lookup ("cirrus_logic" ,NULL ); -if (!dir) - dir =debugfs_create_dir ("cirrus_logic" ,NULL ); +if (!IS_ERR_OR_NULL (dir)) { + created =debugfs_create_dir (dev_name (dev), dir); +dput (dir); + +return created; + } + + dir =debugfs_create_dir ("cirrus_logic" ,NULL );return debugfs_create_dir (dev_name (dev), dir); }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 445/461 selftests: net: Fix checksums in xdp_native
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nimrod Oren <[email protected]>
[ Upstream commit dfc077043351a81887d1e4c9ac244e9243f3cbf2 ]
Data adjustment cases failed with "Data exchange failed" when using IPv4 because the program did not update the IP and UDP checksums in the IPv4 branch. The issue was masked when both IPv4 and IPv6 were configured, since the test harness prefers IPv6.
While here, generalize csum_fold_helper() to fold twice so it works for any 32-bit input.
--- .../selftests/net/lib/xdp_native.bpf.c | 55 ++++++++++--------- 1 file changed, 30 insertions(+), 25 deletions(-)
tools/testing/selftests/net/lib/xdp_native.bpf.c +30 -25
@@ -268,6 +268,17 @@ static int xdp_mode_tx_handler(struct xdp_md *ctx, __u16 port)return XDP_PASS ; } +static __always_inline __u16 csum_fold_helper(__u32 csum) +{ + csum = (csum &0xffff ) + (csum >>16 ); +return ~((csum &0xffff ) + (csum >>16 )); +} + +static __always_inline __u16 csum_fold_udp_helper(__u32 csum) +{ +return csum_fold_helper (csum) ? :0xffff ; +} +static void *update_pkt (struct xdp_md *ctx,__s16 offset,__u32 *udp_csum) {void *data_end = (void *)(long )ctx->data_end;
@@ -281,21 +292,22 @@ static void *update_pkt(struct xdp_md *ctx, __s16 offset, __u32 *udp_csum)if (eth->h_proto ==bpf_htons (ETH_P_IP )) {struct iphdr *iph = data +sizeof (*eth); -__u16 total_len;if (iph +1 > (struct iphdr *)data_end)return NULL ; - iph->tot_len =bpf_htons (bpf_ntohs (iph->tot_len) + offset); - udph = (void *)eth +sizeof (*iph) +sizeof (*eth);if (!udph || udph +1 > (struct udphdr *)data_end)return NULL ; - len_new =bpf_htons (bpf_ntohs (udph->len) + offset); + len = iph->tot_len; + len_new =bpf_htons (bpf_ntohs (len) + offset); + iph->tot_len = len_new; + iph->check =csum_fold_helper ( +bpf_csum_diff (&len,sizeof (len), &len_new, +sizeof (len_new), ~((__u32 )iph->check))); }else if (eth->h_proto ==bpf_htons (ETH_P_IPV6 )) {struct ipv6hdr *ipv6h = data +sizeof (*eth); -__u16 payload_len;if (ipv6h +1 > (struct ipv6hdr *)data_end)return NULL ;
@@ -304,33 +316,27 @@ static void *update_pkt(struct xdp_md *ctx, __s16 offset, __u32 *udp_csum)if (!udph || udph +1 > (struct udphdr *)data_end)return NULL ; - *udp_csum = ~((__u32 )udph->check); - len = ipv6h->payload_len; len_new =bpf_htons (bpf_ntohs (len) + offset); ipv6h->payload_len = len_new; - - *udp_csum =bpf_csum_diff (&len,sizeof (len), &len_new, -sizeof (len_new), *udp_csum); - - len = udph->len; - len_new =bpf_htons (bpf_ntohs (udph->len) + offset); - *udp_csum =bpf_csum_diff (&len,sizeof (len), &len_new, -sizeof (len_new), *udp_csum); }else {return NULL ; } + len = udph->len; + len_new =bpf_htons (bpf_ntohs (len) + offset); + + *udp_csum = ~((__u32 )udph->check); + *udp_csum =bpf_csum_diff (&len,sizeof (len), &len_new, +sizeof (len_new), *udp_csum); + *udp_csum =bpf_csum_diff (&len,sizeof (len), &len_new, +sizeof (len_new), *udp_csum); + udph->len = len_new;return udph; } -static __u16 csum_fold_helper (__u32 csum) -{ -return ~((csum &0xffff ) + (csum >>16 )) ? :0xffff ; -} -static int xdp_adjst_tail_shrnk_data (struct xdp_md *ctx,__u16 offset,unsigned long hdr_len) {
@@ -359,7 +365,7 @@ static int xdp_adjst_tail_shrnk_data(struct xdp_md *ctx, __u16 offset,return -1 ; udp_csum =bpf_csum_diff ((__be32 *)tmp_buff, offset,0 ,0 , udp_csum); - udph->check = (__u16 )csum_fold_helper (udp_csum); + udph->check = (__u16 )csum_fold_udp_helper (udp_csum);if (bpf_xdp_adjust_tail (ctx,0 - offset) <0 )return -1 ;
@@ -403,7 +409,7 @@ static int xdp_adjst_tail_grow_data(struct xdp_md *ctx, __u16 offset)return -1 ; udp_csum =bpf_csum_diff (0 ,0 , (__be32 *)tmp_buff, offset, udp_csum); - udph->check = (__u16 )csum_fold_helper (udp_csum); + udph->check = (__u16 )csum_fold_udp_helper (udp_csum); buff_len =bpf_xdp_get_buff_len (ctx);
@@ -484,8 +490,7 @@ static int xdp_adjst_head_shrnk_data(struct xdp_md *ctx, __u64 hdr_len,return -1 ; udp_csum =bpf_csum_diff ((__be32 *)tmp_buff, offset,0 ,0 , udp_csum); - - udph->check = (__u16 )csum_fold_helper (udp_csum); + udph->check = (__u16 )csum_fold_udp_helper (udp_csum);if (bpf_xdp_load_bytes (ctx,0 , tmp_buff,MAX_ADJST_OFFSET ) <0 )return -1 ;
@@ -542,7 +547,7 @@ static int xdp_adjst_head_grow_data(struct xdp_md *ctx, __u64 hdr_len,return -1 ; udp_csum =bpf_csum_diff (0 ,0 , (__be32 *)data_buff, offset, udp_csum); - udph->check = (__u16 )csum_fold_helper (udp_csum); + udph->check = (__u16 )csum_fold_udp_helper (udp_csum);if (hdr_len >MAX_ADJST_OFFSET || hdr_len ==0 )return -1 ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 446/461 nvme-pci: fix dma_vecs leak on p2p memory
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Keith Busch <[email protected]>
[ Upstream commit 85686c72966c5ee637893f124ddb31a1cace7bee ]
We don't unmap P2P memory, so we don't need to track it. The dma_vec allocation was getting leaked on the completion.
--- drivers/nvme/host/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/nvme/host/pci.c +2 -1
@@ -966,7 +966,8 @@ static bool nvme_pci_prp_save_mapping(struct request *req, {struct nvme_iod *iod =blk_mq_rq_to_pdu (req); -if (dma_use_iova (&iod->dma_state) || !dma_need_unmap (dma_dev)) +if (dma_use_iova (&iod->dma_state) || !dma_need_unmap (dma_dev) || + (iod->flags &IOD_DATA_P2P ))return true;if (!iod->nr_dma_vecs) {
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 447/461 nvme-pci: fix dma mapping leak on data setup error
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Keith Busch <[email protected]>
[ Upstream commit 1bf86336e4b6cf40873fda47a7fe191446864937 ]
We're leaking the initial DMA mapping during iteration if we fail to allocate the tracking descriptor for both PRP and SGL. Unmap the iterator directly; we can't use the existing unmap helper because it depends on the tracking descriptor being successfully allocated, so a new one for an in-use iterator is provided.
The mappings were also leaking when the driver detects an invalid bio_vec when mapping PRPs, so fix that too.
--- drivers/nvme/host/pci.c | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-)
drivers/nvme/host/pci.c +28 -3
@@ -997,6 +997,23 @@ static bool nvme_pci_prp_iter_next(struct request *req, struct device *dma_dev,return nvme_pci_prp_save_mapping (req, dma_dev, iter); } +static void nvme_unmap_iter (struct request *req,struct blk_dma_iter *iter, +struct dma_iova_state *state) +{ +struct nvme_queue *nvmeq = req->mq_hctx->driver_data; +struct device *dev = nvmeq->dev->dev; + +if (!blk_rq_dma_unmap (req, dev, state, iter->len, iter->p2pdma.map)) { +unsigned int attrs =0 ; + +if (iter->p2pdma.map ==PCI_P2PDMA_MAP_THRU_HOST_BRIDGE ) + attrs |=DMA_ATTR_MMIO ; + +dma_unmap_phys (dev, iter->addr, iter->len,rq_dma_dir (req), + attrs); + } +} +static blk_status_t nvme_pci_setup_data_prp (struct request *req,struct blk_dma_iter *iter) {
@@ -1007,8 +1024,10 @@ static blk_status_t nvme_pci_setup_data_prp(struct request *req,unsigned int prp_len, i;__le64 *prp_list; -if (!nvme_pci_prp_save_mapping (req, nvmeq->dev->dev, iter)) +if (!nvme_pci_prp_save_mapping (req, nvmeq->dev->dev, iter)) { +nvme_unmap_iter (req, iter, &iod->dma_state);return iter->status; + }/* * PRP1 always points to the start of the DMA transfers.
@@ -1113,6 +1132,7 @@ static blk_status_t nvme_pci_setup_data_prp(struct request *req,dev_err_once (nvmeq->dev->dev,"Incorrectly formed request for payload:%d nents:%d\n" ,blk_rq_payload_bytes (req),blk_rq_nr_phys_segments (req)); +nvme_unmap_data (req);return BLK_STS_IOERR ; }
@@ -1156,8 +1176,11 @@ static blk_status_t nvme_pci_setup_data_sgl(struct request *req, sg_list =dma_pool_alloc (nvme_dma_pool (nvmeq, iod),GFP_ATOMIC , &sgl_dma); -if (!sg_list) +if (!sg_list) { +nvme_unmap_iter (req, iter, &iod->dma_state);return BLK_STS_RESOURCE ; + } + iod->descriptors[iod->nr_descriptors++] = sg_list; do {
@@ -1314,8 +1337,10 @@ static blk_status_t nvme_pci_setup_meta_iter(struct request *req) sg_list =dma_pool_alloc (nvmeq->descriptor_pools.small,GFP_ATOMIC , &sgl_dma); -if (!sg_list) +if (!sg_list) { +nvme_unmap_iter (req, &iter, &iod->meta_dma_state);return BLK_STS_RESOURCE ; + } iod->meta_descriptor = sg_list; iod->meta_dma = sgl_dma;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 448/461 octeontx2-af: npc: Fix allmulticast skip logic for LBK and SDP VFs
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ratheesh Kannoth <[email protected]>
[ Upstream commit 9eddc819f00b5b74bb4ac91396f80bd35f5f3561 ]
When installing the allmulticast NPC rule, rvu_npc_install_allmulti_entry() should skip LBK and SDP VFs (only CGX PF/VF may add the entry). The code combined is_lbk_vf() and is_sdp_vf() with logical AND, which is never true for a single pcifunc, so the intended early return never ran.
Use logical OR instead.
--- drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c +1 -1
@@ -837,7 +837,7 @@ void rvu_npc_install_allmulti_entry(struct rvu *rvu, u16 pcifunc, int nixlf,u16 vf_func;/* Only CGX PF/VF can add allmulticast entry */ -if (is_lbk_vf (rvu, pcifunc) &&is_sdp_vf (rvu, pcifunc)) +if (is_lbk_vf (rvu, pcifunc) ||is_sdp_vf (rvu, pcifunc))return ; blkaddr =rvu_get_blkaddr (rvu,BLKTYPE_NPC ,0 );
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 449/461 net: mana: validate rx_req_idx to prevent out-of-bounds array access
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aditya Garg <[email protected]>
[ Upstream commit b809d0409991b75a6cff846a5ac27c3062953f84 ]
In mana_hwc_rx_event_handler(), rx_req_idx is derived from sge->address in DMA-coherent memory. In Confidential VMs (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify WQE contents at any time. No bounds check exists on rx_req_idx, which can lead to an out-of-bounds access into reqs[].
Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before using it to index the reqs[] array.
--- drivers/net/ethernet/microsoft/mana/hw_channel.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/ethernet/microsoft/mana/hw_channel.c +6 -0
@@ -265,6 +265,12 @@ static void mana_hwc_rx_event_handler(void *ctx, u32 gdma_rxq_id, rq_base_addr = hwc_rxq->msg_buf->mem_info.dma_handle; rx_req_idx = (sge->address - rq_base_addr) / hwc->max_req_msg_size; +if (rx_req_idx >= hwc_rxq->msg_buf->num_reqs) { +dev_err (hwc->dev,"HWC RX: wrong rx_req_idx=%llu, num_reqs=%u\n" , + rx_req_idx, hwc_rxq->msg_buf->num_reqs); +return ; + } + rx_req = &hwc_rxq->msg_buf->reqs[rx_req_idx]; resp = (struct gdma_resp_hdr *)rx_req->buf_va;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 450/461 tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Weiming Shi <[email protected]>
[ Upstream commit bddc09212c24934643bd44fc794748d2bbb3b6cd ]
In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an uninitialised on-stack struct sockaddr_storage to userspace via ifr_hwaddr, but netif_get_mac_address() only writes sa_family and dev->addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised.
Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a macvtap chardev returns kernel .text and direct-map pointers, defeating KASLR.
Initialise ss at declaration.
--- drivers/net/tap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/tap.c +1 -1
@@ -919,11 +919,11 @@ static long tap_ioctl(struct file *file, unsigned int cmd,struct tap_queue *q = file->private_data;struct tap_dev *tap;void __user *argp = (void __user *)arg; +struct sockaddr_storage ss = {};struct ifreq __user *ifr = argp;unsigned int __user *up = argp;unsigned short u;int __user *sp = argp; -struct sockaddr_storage ss;int s;int ret;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 451/461 net: airoha: Disable GDM2 forwarding before configuring GDM2 loopback
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Bianconi <[email protected]>
[ Upstream commit 985d4a55e64e43bd86eeb896b81ceba453301989 ]
Hw design requires to disable GDM2 forwarding before configuring GDM2 loopback in airoha_set_gdm2_loopback routine.
--- drivers/net/ethernet/airoha/airoha_eth.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/ethernet/airoha/airoha_eth.c +6 -4
@@ -1781,11 +1781,8 @@ static int airhoha_set_gdm2_loopback(struct airoha_gdm_port *port)u32 val, pse_port, chan;int src_port; -/* Forward the traffic to the proper GDM port */ - pse_port = port->id ==AIROHA_GDM3_IDX ?FE_PSE_PORT_GDM3 - :FE_PSE_PORT_GDM4 ;airoha_set_gdm_port_fwd_cfg (eth,REG_GDM_FWD_CFG (AIROHA_GDM2_IDX ), - pse_port); +FE_PSE_PORT_DROP );airoha_fe_clear (eth,REG_GDM_FWD_CFG (AIROHA_GDM2_IDX ),GDM_STRIP_CRC_MASK );
@@ -1803,6 +1800,11 @@ static int airhoha_set_gdm2_loopback(struct airoha_gdm_port *port)GDM_SHORT_LEN_MASK |GDM_LONG_LEN_MASK ,FIELD_PREP (GDM_SHORT_LEN_MASK ,60 ) | FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_MTU)); +/* Forward the traffic to the proper GDM port */ + pse_port = port->id ==AIROHA_GDM3_IDX ?FE_PSE_PORT_GDM3 + :FE_PSE_PORT_GDM4 ; +airoha_set_gdm_port_fwd_cfg (eth,REG_GDM_FWD_CFG (AIROHA_GDM2_IDX ), + pse_port);/* Disable VIP and IFC for GDM2 */ airoha_fe_clear (eth,REG_FE_VIP_PORT_EN ,BIT (AIROHA_GDM2_IDX ));
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 452/461 pds_core: ensure null-termination for firmware version strings
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikhil P. Rao <[email protected]>
[ Upstream commit 3d4432d34c1992701289cbe12df9fd024f315998 ]
The driver passes fw_version directly to devlink_info_version_stored_put() without ensuring null-termination. While current firmware null-terminates these strings, the driver should not rely on this behavior. Add explicit null-termination to prevent potential issues if firmware behavior changes.
--- drivers/net/ethernet/amd/pds_core/devlink.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/amd/pds_core/devlink.c +4 -2
@@ -122,12 +122,14 @@ int pdsc_dl_info_get(struct devlink *dl, struct devlink_info_req *req, listlen =min (fw_list.num_fw_slots,ARRAY_SIZE (fw_list.fw_names));for (i =0 ; i < listlen; i++) { +char *fw_ver = fw_list.fw_names[i].fw_version; +if (i <ARRAY_SIZE (fw_slotnames))strscpy (buf, fw_slotnames[i],sizeof (buf));else snprintf (buf,sizeof (buf),"fw.slot_%d" , i); - err =devlink_info_version_stored_put (req, buf, - fw_list.fw_names[i].fw_version); + fw_ver[sizeof (fw_list.fw_names[i].fw_version) -1 ] ='\0' ; + err =devlink_info_version_stored_put (req, buf, fw_ver);if (err)return err; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 453/461 net: gro: dont merge zcopy skbs
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
[ Upstream commit 4db79a322db8c97f7b73b8a347395ef4d685eb40 ]
skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag.
When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.
When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.
--- net/core/gro.c | 3 +++ 1 file changed, 3 insertions(+)
net/core/gro.c +3 -0
@@ -109,6 +109,9 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)if (p->pp_recycle != skb->pp_recycle)return -ETOOMANYREFS ; +if (skb_zcopy (p) ||skb_zcopy (skb)) +return -ETOOMANYREFS ; +if (unlikely (p->len + len >=netif_get_gro_max_size (p->dev, p) ||NAPI_GRO_CB (skb)->flush))return -E2BIG ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 454/461 net: enetc: fix missing error code when pf->vf_state allocation fails
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
[ Upstream commit 5027266dea471e140f93dd534845c9c4f43219a3 ]
In enetc_pf_probe(), when the memory allocation for pf->vf_state fails, the code jumps to the error handling label but the variable 'err' is not assigned an appropriate error code beforehand. This causes the function to return 0 (success) on an allocation failure path, misleading the caller into thinking the probe succeeded. So set err to -ENOMEM before jumping to the error handling label when the allocation for pf->vf_state returns NULL.
--- drivers/net/ethernet/freescale/enetc/enetc_pf.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/freescale/enetc/enetc_pf.c +3 -1
@@ -960,8 +960,10 @@ static int enetc_pf_probe(struct pci_dev *pdev,if (pf->total_vfs) { pf->vf_state = kzalloc_objs(struct enetc_vf_state, pf->total_vfs); -if (!pf->vf_state) +if (!pf->vf_state) { + err = -ENOMEM ; goto err_alloc_vf_state; + } } err =enetc_setup_mac_addresses (node, pf);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 455/461 io_uring/nop: pass all errors to userspace
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander A. Klimov <[email protected]>
[ Upstream commit e97ff8b62d4690c69297f0f6de874f0564cc01a4 ]
This fixes an inconsistency where io_nop() called req_set_fail() based on ret, but passed just nop->result to userspace. Originally, ret is a even copy of nop->result, but is set to an error when such happens subsequently. Now that's also passed to userspace.
--- io_uring/nop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
io_uring/nop.c +2 -2
@@ -79,9 +79,9 @@ int io_nop(struct io_kiocb *req, unsigned int issue_flags)if (ret <0 )req_set_fail (req);if (nop->flags &IORING_NOP_CQE32 ) -io_req_set_res32 (req, nop->result,0 , nop->extra1, nop->extra2); +io_req_set_res32 (req, ret,0 , nop->extra1, nop->extra2);else -io_req_set_res (req, nop->result,0 ); +io_req_set_res (req, ret,0 );if (nop->flags &IORING_NOP_TW ) { req->io_task_work.func = io_req_task_complete;io_req_task_work_add (req);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 456/461 blk-mq: pop cached request if it is usable
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Keith Busch <[email protected]>
[ Upstream commit dc278e9bf2b9513a763353e6b9cc21e0f532954e ]
When submitting a bio to blk-mq, if the task should sleep after peeking a cached request, but before it pops it, the plug flushes and calls blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a use-after-free bug. Fix this by popping the cached request before any possible blocking calls if it is suitable for use.
Popping this request first holds a queue reference, so avoid any serialization races with queue freezes and can safely proceed with dispatching that request to the driver. This potentially increases a timing window from when a driver wants to freeze its queue to when requests stop being dispatched. That scenario is off the fast path though, and drivers need to appropriately handle requests during a freeze request anyway.
The downside is the popped element needs to be individually freed when we performed a bio plug merge. The cached request would have had to be freed later anyway, but this patch does it inline with building the plug list instead of after flushing it.
--- block/blk-mq.c | 34 +++++++++------------------------- 1 file changed, 9 insertions(+), 25 deletions(-)
block/blk-mq.c +9 -25
@@ -3077,7 +3077,7 @@ static struct request *blk_mq_get_new_requests(struct request_queue *q,/* * Check if there is a suitable cached request and return it. */ -static struct request *blk_mq_peek_cached_request (struct blk_plug *plug, +static struct request *blk_mq_get_cached_request (struct blk_plug *plug,struct request_queue *q,blk_opf_t opf) {enum hctx_type type =blk_mq_get_hctx_type (opf);
@@ -3093,27 +3093,10 @@ static struct request *blk_mq_peek_cached_request(struct blk_plug *plug,return NULL ;if (op_is_flush (rq->cmd_flags) !=op_is_flush (opf))return NULL ; +rq_list_pop (&plug->cached_rqs);return rq; } -static void blk_mq_use_cached_rq (struct request *rq,struct blk_plug *plug, -struct bio *bio) -{ -if (rq_list_pop (&plug->cached_rqs) != rq) -WARN_ON_ONCE (1 ); - -/* -* If any qos ->throttle() end up blocking, we will have flushed the -* plug and hence killed the cached_rq list as well. Pop this entry -* before we throttle. -*/ -rq_qos_throttle (rq->q, bio); - -blk_mq_rq_time_init (rq,blk_time_get_ns ()); - rq->cmd_flags = bio->bi_opf; -INIT_LIST_HEAD (&rq->queuelist); -} -static bool bio_unaligned (const struct bio *bio,struct request_queue *q) {unsigned int bs_mask =queue_logical_block_size (q) -1 ;
@@ -3151,7 +3134,7 @@ void blk_mq_submit_bio(struct bio *bio)/* * If the plug has a cached request for this queue, try to use it. */ - rq =blk_mq_peek_cached_request (plug, q, bio->bi_opf); + rq =blk_mq_get_cached_request (plug, q, bio->bi_opf);/* * A BIO that was released from a zone write plug has already been
@@ -3209,7 +3192,10 @@ void blk_mq_submit_bio(struct bio *bio) new_request:if (rq) { -blk_mq_use_cached_rq (rq, plug, bio); +rq_qos_throttle (rq->q, bio); +blk_mq_rq_time_init (rq,blk_time_get_ns ()); + rq->cmd_flags = bio->bi_opf; +INIT_LIST_HEAD (&rq->queuelist); }else { rq =blk_mq_get_new_requests (q, plug, bio);if (unlikely (!rq)) {
@@ -3255,12 +3241,10 @@ void blk_mq_submit_bio(struct bio *bio)return ; queue_exit: -/* -* Don't drop the queue reference if we were trying to use a cached -* request and thus didn't acquire one. -*/ if (!rq)blk_queue_exit (q); +else +blk_mq_free_request (rq); }#ifdef CONFIG_BLK_MQ_STACKING
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 457/461 ksmbd: fix durable reconnect error path file lifetime
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junyi Liu <[email protected]>
[ Upstream commit 3515503322f4819277091839eed46b695096aca5 ]
After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes the same ksmbd_file into the session volatile-id table. If smb2_open() then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp) and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp).
In this case fp and dh_info.fp are the same object. The first put drops the reconnect lookup reference, but the final durable put can run __ksmbd_close_fd(NULL, fp). Because the final close is not session-aware, it can free the file object without removing the volatile-id entry that was just published into the session table.
Use the session-aware put for the final reconnect drop when the reconnect had already succeeded and the error path is cleaning up the republished file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep using the durable-only put path.
--- fs/smb/server/smb2pdu.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
fs/smb/server/smb2pdu.c +13 -2
@@ -3803,8 +3803,19 @@ int smb2_open(struct ksmbd_work *work)ksmbd_debug (SMB ,"Error response: %x\n" , rsp->hdr.Status); } -if (dh_info.reconnected) -ksmbd_put_durable_fd (dh_info.fp); +if (dh_info.reconnected) { +/* +* If reconnect succeeded, fp was republished in the +* session file table. On a later error, ksmbd_fd_put() +* above drops the session reference; drop the durable +* lookup reference through the same session-aware path so +* final close removes the volatile id before freeing fp. +*/ +if (rc && fp == dh_info.fp) +ksmbd_fd_put (work, dh_info.fp); +else +ksmbd_put_durable_fd (dh_info.fp); + }kfree (name);kfree (lc);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 458/461 LoongArch: kprobes: Fix handling of fatal unrecoverable recursions
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tiezhu Yang <[email protected]>
[ Upstream commit 1c856e158fd34ef2c4475a81c1dc386329989938 ]
KPROBE_HIT_SS and KPROBE_REENTER are two types of fatal recursions that can not be safely recovered in kprobes.
KPROBE_HIT_SS means that a kprobe is hit during single-stepping. At this point, the architecture-specific single-step context is already active. Nested single-stepping would corrupt the state, as the kprobe control block (kcb) and hardware registers cannot safely store multiple levels of stepping state.
KPROBE_REENTER means that a third-level recursion occurs when a probe is hit while the system is already handling a nested probe (second- level). The kcb only provides a single slot (prev_kprobe) to backup the state. When a third probe is hit, there is no more space to save the state without corrupting the first-level backup.
Kprobes work by replacing instructions with breakpoints. In order to execute the original instruction and continue, it must be moved to a temporary "single-step" slot. Since there is no backup space left to set up this slot safely, the CPU would be forced to return to the same original breakpoint address, triggering an endless loop.
Currently, the code only prints a warning and returns. This leads to an infinite re-entry loop as the CPU repeatedly hits the same trap and a "stuck" CPU core because preemption was disabled at the start of the handler and never re-enabled in this early return path.
Fix the logic by:
1. Merging KPROBE_HIT_SS and KPROBE_REENTER cases, as both represent fatal recursions that cannot be safely recovered.
2. Replacing WARN_ON_ONCE() with BUG() to terminate the system. This aligns LoongArch with other architectures (x86, arm64, riscv) and prevents stack overflow while providing diagnostic information.
--- arch/loongarch/kernel/kprobes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/loongarch/kernel/kprobes.c +2 -2
@@ -186,16 +186,16 @@ static bool reenter_kprobe(struct kprobe *p, struct pt_regs *regs, struct kprobe_ctlblk *kcb) {switch (kcb->kprobe_status) { -case KPROBE_HIT_SS :case KPROBE_HIT_SSDONE :case KPROBE_HIT_ACTIVE :kprobes_inc_nmissed_count (p);setup_singlestep (p, regs, kcb,1 );break ; +case KPROBE_HIT_SS :case KPROBE_REENTER :pr_warn ("Failed to recover from reentered kprobes.\n" );dump_kprobe (p); -WARN_ON_ONCE (1 ); +BUG ();break ;default :WARN_ON (1 );
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 459/461 block: avoid use-after-free in disk_free_zone_resources()
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
[ Upstream commit f6982769910ecddabdb5b8b9afdab0bb8b6668ac ]
The function disk_update_zone_resources() may call disk_free_zone_resources() in case of error, and following this, blk_revalidate_disk_zones() will again calls disk_free_zone_resources() if disk_update_zone_resources() failed. If a zone worker thread is being used (which is the default for a rotational media zoned device), disk_free_zone_resources() will try to stop the zone worker thread twice because disk->zone_wplugs_worker is not reset to NULL when the worker thread is stopped the first time.
In disk_free_zone_resources(), fix this by correctly clearing disk->zone_wplugs_worker to NULL when the worker thread is stopped.
And while at it, since disk_free_zone_resources() is always called after a failed call to disk_update_zone_resources(), remove the unnecessary call to disk_free_zone_resources() in disk_update_zone_resources().
--- block/blk-zoned.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
block/blk-zoned.c +3 -4
@@ -2016,8 +2016,10 @@ static void disk_set_zones_cond_array(struct gendisk *disk, u8 *zones_cond)void disk_free_zone_resources (struct gendisk *disk) { -if (disk->zone_wplugs_worker) +if (disk->zone_wplugs_worker) {kthread_stop (disk->zone_wplugs_worker); + disk->zone_wplugs_worker =NULL ; + }WARN_ON_ONCE (!list_empty (&disk->zone_wplugs_list));if (disk->zone_wplugs_wq) {
@@ -2150,9 +2152,6 @@ static int disk_update_zone_resources(struct gendisk *disk, ret =queue_limits_commit_update (q, &lim); unfreeze: -if (ret) -disk_free_zone_resources (disk); -blk_mq_unfreeze_queue (q, memflags);return ret;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 460/461 Documentation: laptops: Update documentation for uniwill laptops
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Werner Sembach <[email protected]>
[ Upstream commit 9ec6bf62cf98e30c7126a0f51ee7cdf2e8d458b6 ]
Adds short description for two new sysfs entries, ctgp_offset and usb_c_power_priority, to the documentation of uniwill laptops.
Stable-dep-of: 26cbe119f99c ("platform/x86: uniwill-laptop: Do not enable the charging limit even when forced")
--- .../ABI/testing/sysfs-driver-uniwill-laptop | 27 +++++++++++++++++++ .../admin-guide/laptops/uniwill-laptop.rst | 12 +++++++++ 2 files changed, 39 insertions(+)
Documentation/ABI/testing/sysfs-driver-uniwill-laptop +27 -0
@@ -51,3 +51,30 @@ Description: Reading this file returns the current status of the breathing animation functionality. + +What: /sys/bus/platform/devices/INOU0000:XX/ctgp_offset +Date: January 2026 +KernelVersion: 7.0 +Contact: Werner Sembach <[email protected]> +Description: + Allows userspace applications to set the configurable TGP offset on top of the base + TGP. Base TGP and max TGP and therefore the max cTGP offset are device specific. + Note that setting the maximum cTGP leaves no window open for Dynamic Boost as + Dynamic Boost also can not go over max TGP. Setting the cTGP to maximum is + effectively disabling Dynamic Boost and telling the device to always prioritize the + GPU over the CPU. + + Reading this file returns the current configurable TGP offset. + +What: /sys/bus/platform/devices/INOU0000:XX/usb_c_power_priority +Date: February 2026 +KernelVersion: 7.1 +Contact: Werner Sembach <[email protected]> +Description: + Allows userspace applications to choose the USB-C power distribution profile between + one that offers a bigger share of the power to the battery and one that offers more + of it to the CPU. Writing "charging"/"performance" into this file selects the + respective profile. + + Reading this file returns the profile names with the currently active one in + brackets.
Documentation/admin-guide/laptops/uniwill-laptop.rst +12 -0
@@ -50,6 +50,10 @@ between 1 and 100 percent are supported. Additionally the driver signals the presence of battery charging issues through the standard ``health`` power supply sysfs attribute. +It also lets you set whether a USB-C power source should prioritise charging the battery or +delivering immediate power to the cpu. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for +details. + Lightbar --------
@@ -58,3 +62,11 @@ LED class device. The default name of this LED class device is ``uniwill:multico See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various animation modes of the lightbar. + +Configurable TGP +---------------- + +The ``uniwill-laptop`` driver allows to set the configurable TGP for devices with NVIDIA GPUs that +allow it. + +See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 461/461 platform/x86: uniwill-laptop: Do not enable the charging limit even when forced
In reply to Greg Kroah-Hartman7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
[ Upstream commit 26cbe119f99c86dcb4a0136d2bc73c0c716d80e4 ]
It seems that on some older models (~2020) the battery charging limit can permanently damage the battery. Prevent users from enabling this feature thru the "force" module parameter to avoid causing permanent hardware damage on such devices.
--- Documentation/admin-guide/laptops/uniwill-laptop.rst | 10 ++++++++++ drivers/platform/x86/uniwill/uniwill-acpi.c | 4 ++-- 2 files changed, 12 insertions(+), 2 deletions(-)
Documentation/admin-guide/laptops/uniwill-laptop.rst +10 -0
@@ -43,6 +43,11 @@ Support for changing the platform performance mode is currently not implemented. Battery Charging Control ------------------------ +.. warning:: Some devices do not properly implement the charging threshold interface. Forcing + the driver to enable access to said interface on such devices might damage the + battery [1]_. Because of this the driver will not enable said feature even when + using the ``force`` module parameter. + The ``uniwill-laptop`` driver supports controlling the battery charge limit. This happens over the standard ``charge_control_end_threshold`` power supply sysfs attribute. All values between 1 and 100 percent are supported.
@@ -70,3 +75,8 @@ The ``uniwill-laptop`` driver allows to set the configurable TGP for devices wit allow it. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details. + +References +========== + +.. [1] https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/
drivers/platform/x86/uniwill/uniwill-acpi.c +2 -2
@@ -2207,8 +2207,8 @@ static int __init uniwill_init(void) }if (force) { -/* Assume that the device supports all features */ - device_descriptor.features =UINT_MAX ; +/* Assume that the device supports all features except the charge limit */ + device_descriptor.features =UINT_MAX & ~UNIWILL_FEATURE_BATTERY ;pr_warn ("Enabling potentially unsupported features\n" ); }
Signature · 1 line
2.53.0
Hi
kernel build / boot test on x86_64.
No regressions here.
Thanks
Quoted 1 line · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release.
Working fine on a variety of Intel & AMD based server/desktop systems; no regressions in dmesg or behaviour.
Thanks!
Holger
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +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/v7.x/stable-review/patch-7.0.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-7.0.y
and the diffstat can be found below.thanks,
greg k-h
Linux version 7.0.11-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 7.0.11-rc1rv-g547c0212c36f
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 16.1.1 20260430, GNU ld (GNU Binutils) 2.46.0) #1 SMP PREEMPT_DYNAMIC Fri May 29 08:35:15 JST 2026
Thanks
Luna Jernberg
Tested-byAMD Ryzen 5 5600 6-Core Processor:
https://www.inet.se/produkt/5304697/amd-ryzen-5-5600-3-5-ghz-35mb on a
https://www.gigabyte.com/Motherboard/B550-AORUS-ELITE-V2-rev-12
https://www.inet.se/produkt/1903406/gigabyte-b550-aorus-elite-v2
motherboard :)
and a Dell Micro 3050 with: Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz
running Arch Linux with the testing repos enabled:
https://archlinux.org/ https://archboot.com/
https://wiki.archlinux.org/title/Arch_Testing_Team
Den fre 29 maj 2026 kl 02:11 skrev Takeshi Ogasawara <[email protected]>:
Quoted 43 lines
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +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/v7.x/stable-review/patch-7.0.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-7.0.y
and the diffstat can be found below.thanks,
greg k-h
Linux version 7.0.11-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.Lenovo ThinkPad X1 Carbon
Gen10(Intel i7-1260P(x86_64) arch linux)[ 0.000000] Linux version 7.0.11-rc1rv-g547c0212c36f(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 16.1.1 20260430, GNU ld (GNU Binutils) 2.46.0) #1 SMP
PREEMPT_DYNAMICFri May 29 08:35:15 JST 2026Thanks
Tested-by Takeshi Ogasawara <[email protected]>
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +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/v7.x/stable-review/patch-7.0.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-7.0.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 8 lines · On Thu, 28 May 2026 21:42:09 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
For arm64 and arm, I am seeing:
drivers/gpu/drm/msm/msm_gem_shrinker.c:105:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions]
105 | purge(struct drm_gem_object *obj, struct ww_acquire_ctx *)
| ^
drivers/gpu/drm/msm/msm_gem_shrinker.c:117:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions]
117 | evict(struct drm_gem_object *obj, struct ww_acquire_ctx *)
|
This looks like it was fixed for mainline:
53676e4d44d6 ("drm/msm: Restore second parameter name in purge() and evict()")
and was queued for stable but maybe not picked yet.
Thanks!
Cheers,
Miguel
Sasha Levin
maintainerQuoted 4 lines · Miguel Ojeda
For arm64 and arm, I am seeing:
drivers/gpu/drm/msm/msm_gem_shrinker.c:105:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions]
105 |purge(struct drm_gem_object *obj, struct ww_acquire_ctx *)
Thanks Miguel!
Quoted 5 lines
This looks like it was fixed for mainline:
53676e4d44d6("drm/msm: Restore second parameter name inpurge()andevict()")and was queued for stable but maybe not picked yet.
Right. Rather than dropping the deadlock fix, I'm queuing the upstream follow-up 53676e4d44d6 ("drm/msm: Restore second parameter name in purge() and evict()" for both 7.0 and 6.18.
--
Thanks,
Sasha
Quoted 2 lines · Sasha Levin
Thanks Miguel!
You're welcome, happy it helped! :)
Quoted 3 lines
Right. Rather than dropping the deadlock fix, I'm queuing the upstream follow-up
53676e4d44d6("drm/msm: Restore second parameter name inpurge()andevict()" for both 7.0 and 6.18.
Sounds good, thanks.
Cheers,
Miguel
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 7.0.11-rc1-g547c0212c36f #1 SMP PREEMPT_DYNAMIC Fri May 29 06:18:58 -00 2026 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 7.0.11 release. There are 461 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-7.0.y
Best regards,
Pavel
hello,
Compiled and booted 7.0.11-rc1+
No new typical dmesg regressions
.
--
software engineer
rajagiri school of engineering and technology
Am 28.05.2026 um 21:42 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 7.0.11 release. There are 461 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Tested kernel 7.0.11‑rc1 on the following setups:
1. QEMU VM, Arch Linux x86_64
Booted successfully. No regressions, panics or oops observed.
2. Raspberry Pi 4B (4 GB), Raspberry Pi OS Lite 64‑bit Booted successfully. Observed a null‑pointer dereference oops in journalctl, which also occurs in the previous stable kernel (v7.0.10). So no regressions observed.
Details:
$ uname -a Linux testrpi 7.0.11-rc1-v8+ #1 SMP PREEMPT Fri May 29 13:18:21 BST 2026 aarch64 GNU/Linux
$ sudo journalctl -b | grep -iE "error|warn|fail|oops|panic" May 29 11:35:10 testrpi rpi-resize-swap-file[369]: mkswap: /var/swap: warning: wiping old swap signature. May 29 11:35:11 testrpi kernel: Internal error: Oops: 0000000096000005 [#1] SMP May 29 11:35:22 testrpi bluetoothd[542]: Failed to set mode: Failed (0x03) May 29 11:35:25 testrpi NetworkManager[561]: <info> [1780050925.4153] failed to open /run/network/ifstate May 29 11:35:31 testrpi cloud-init[525]: 2026-05-29 10:35:31,802 - modules.py[WARNING]: Could not find module named cc_netplan_nm_patch (searched ['cc_netplan_nm_patch', 'cloudinit.config.cc_netplan_nm_patch'])
Best regards
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +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/v7.x/stable-review/patch-7.0.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-7.0.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 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +0000. Anything received after that time might be too late.
Hi Greg
7.0.11-rc1 compiles on x86_64 (Xeon E5-1620 v2, Slackware64-15.0), with custom .config
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +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/v7.x/stable-review/patch-7.0.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-7.0.y
and the diffstat can be found below.thanks,
greg k-h
Tested on 2 amd64 systems. Working well, no regressions observed.
Signature · 1 line
-Barry K. Nathan <[email protected]>
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 7.0.11 release. There are 461 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 Sat, 30 May 2026 19:45:49 +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/v7.x/stable-review/patch-7.0.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-7.0.y
and the diffstat can be found below.thanks,
greg k-h
Successfully built and tested 7.0.11-rc1 on Arch Linux.
CPU: AMD Ryzen 7 5700X
GPU: NVIDIA GeForce RTX 3080 (using nvidia-open-dkms)
Sound, video and Wi-Fi normal.
No performance drops running Warframe through Proton.
No regressions or stability issues observed.