6.15.8-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 141/187 net/mlx5: Correctly set gso_size when LRO is used
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Paasch <[email protected]>
[ Upstream commit 531d0d32de3e1b6b77a87bd37de0c2c6e17b496a ]
gso_size is expected by the networking stack to be the size of the payload (thus, not including ethernet/IP/TCP-headers). However, cqe_bcnt is the full sized frame (including the headers). Dividing cqe_bcnt by lro_num_seg will then give incorrect results.
For example, running a bpftrace higher up in the TCP-stack (tcp_event_data_recv), we commonly have gso_size set to 1450 or 1451 even though in reality the payload was only 1448 bytes.
This can have unintended consequences:
- In tcp_measure_rcv_mss() len will be for example 1450, but. rcv_mss will be 1448 (because tp->advmss is 1448). Thus, we will always recompute scaling_ratio each time an LRO-packet is received.
- In tcp_gro_receive(), it will interfere with the decision whether or not to flush and thus potentially result in less gro'ed packets.
So, we need to discount the protocol headers from cqe_bcnt so we can actually divide the payload by lro_num_seg to get the real gso_size.
v2:
- Use "(unsigned char *)tcp + tcp->doff * 4 - skb->data)" to compute header-len (Tariq Toukan <[email protected]>)
- Improve commit-message (Gal Pressman <[email protected]>)
--- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +8 -4
@@ -1154,8 +1154,9 @@ static void mlx5e_lro_update_tcp_hdr(struct mlx5_cqe64 *cqe, struct tcphdr *tcp) } } -static void mlx5e_lro_update_hdr (struct sk_buff *skb,struct mlx5_cqe64 *cqe, -u32 cqe_bcnt) +static unsigned int mlx5e_lro_update_hdr (struct sk_buff *skb, +struct mlx5_cqe64 *cqe, +u32 cqe_bcnt) {struct ethhdr *eth = (struct ethhdr *)(skb->data);struct tcphdr *tcp;
@@ -1205,6 +1206,8 @@ static void mlx5e_lro_update_hdr(struct sk_buff *skb, struct mlx5_cqe64 *cqe, tcp->check =tcp_v6_check (payload_len, &ipv6->saddr, &ipv6->daddr, check); } + +return (unsigned int )((unsigned char *)tcp + tcp->doff *4 - skb->data); }static void *mlx5e_shampo_get_packet_hd (struct mlx5e_rq *rq,u16 header_index)
@@ -1561,8 +1564,9 @@ static inline void mlx5e_build_rx_skb(struct mlx5_cqe64 *cqe,mlx5e_macsec_offload_handle_rx_skb (netdev, skb, cqe);if (lro_num_seg >1 ) { -mlx5e_lro_update_hdr (skb, cqe, cqe_bcnt); -skb_shinfo (skb)->gso_size =DIV_ROUND_UP (cqe_bcnt, lro_num_seg); +unsigned int hdrlen =mlx5e_lro_update_hdr (skb, cqe, cqe_bcnt); + +skb_shinfo (skb)->gso_size =DIV_ROUND_UP (cqe_bcnt - hdrlen, lro_num_seg);/* Subtract one since we already counted this as one * "regular" packet in mlx5e_complete_rx_cqe() */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 142/187 net: airoha: fix potential use-after-free in airoha_npu_get()
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alok Tiwari <[email protected]>
[ Upstream commit 3cd582e7d0787506990ef0180405eb6224fa90a6 ]
np->name was being used after calling of_node_put(np), which releases the node and can lead to a use-after-free bug. Previously, of_node_put(np) was called unconditionally after of_find_device_by_node(np), which could result in a use-after-free if pdev is NULL.
This patch moves of_node_put(np) after the error check to ensure the node is only released after both the error and success cases are handled appropriately, preventing potential resource issues.
--- drivers/net/ethernet/airoha/airoha_npu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/airoha/airoha_npu.c +2 -1
@@ -344,12 +344,13 @@ struct airoha_npu *airoha_npu_get(struct device *dev)return ERR_PTR (-ENODEV ); pdev =of_find_device_by_node (np); -of_node_put (np);if (!pdev) {dev_err (dev,"cannot find device node %s\n" , np->name); +of_node_put (np);return ERR_PTR (-ENODEV ); } +of_node_put (np);if (!try_module_get (THIS_MODULE )) {dev_err (dev,"failed to get the device driver module\n" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 143/187 ipv6: mcast: Delay put pmc->idev in mld_del_delrec()
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yue Haibing <[email protected]>
[ Upstream commit ae3264a25a4635531264728859dbe9c659fad554 ]
pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return.
--- net/ipv6/mcast.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/mcast.c +1 -1
@@ -807,8 +807,8 @@ static void mld_del_delrec(struct inet6_dev *idev, struct ifmcaddr6 *im) }else { im->mca_crcount = idev->mc_qrv; } -in6_dev_put (pmc->idev);ip6_mc_clear_src (pmc); +in6_dev_put (pmc->idev);kfree_rcu (pmc, rcu); } }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 144/187 net: fix segmentation after TCP/UDP fraglist GRO
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
[ Upstream commit 9f735b6f8a77d7be7f8b0765dc93587774832cb1 ]
Since "net: gro: use cb instead of skb->network_header", the skb network header is no longer set in the GRO path.
This breaks fraglist segmentation, which relies on ip_hdr()/tcp_hdr() to check for address/port changes.
Fix this regression by selectively setting the network header for merged segment skbs.
--- net/ipv4/tcp_offload.c | 1 + net/ipv4/udp_offload.c | 1 + 2 files changed, 2 insertions(+)
net/ipv4/tcp_offload.c +1 -0
@@ -359,6 +359,7 @@ struct sk_buff *tcp_gro_receive(struct list_head *head, struct sk_buff *skb, flush |= skb->ip_summed != p->ip_summed; flush |= skb->csum_level != p->csum_level; flush |=NAPI_GRO_CB (p)->count >=64 ; +skb_set_network_header (skb,skb_gro_receive_network_offset (skb));if (flush ||skb_gro_receive_list (p, skb)) mss =1 ;
net/ipv4/udp_offload.c +1 -0
@@ -604,6 +604,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,NAPI_GRO_CB (skb)->flush =1 ;return NULL ; } +skb_set_network_header (skb,skb_gro_receive_network_offset (skb)); ret =skb_gro_receive_list (p, skb); }else { skb_gro_postpull_rcsum(skb, uh,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 145/187 netfilter: nf_conntrack: fix crash due to removal of uninitialised entry
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
[ Upstream commit 2d72afb340657f03f7261e9243b44457a9228ac7 ]
A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list:
[exception RIP: __nf_ct_delete_from_lists+172]
[..]
#7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]
#8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]
#9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]
[..]The nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state:
ct hlist pointer is garbage; looks like the ct hash value (hence crash).
ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected.
Everything else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash:
- ct hlist pointers are overloaded and store/cache the raw tuple hash
- ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value.
If it were not for the presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry.
Theory is that we did hit following race:
cpu x cpu y cpu z
found entry E found entry E
E is expired <preemption>
nf_ct_delete()
return E to rcu slab
init_conntrack
E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value.
cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit.
->refcnt set to 1 E now owned by skb ->timeout set to 30000
If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit.
nf_conntrack_confirm gets called
sets: ct->status |= CONFIRMED This is wrong: E is not yet added to hashtable.
cpu y resumes, it observes E as expired but CONFIRMED:
<resumes> nf_ct_expired() -> yes (ct->timeout is 30s) confirmed bit set.
cpu y will try to delete E from the hashtable:
nf_ct_delete() -> set DYING bit __nf_ct_delete_from_lists
Even this scenario doesn't guarantee a crash:
cpu z still holds the table bucket lock(s) so y blocks:
wait for spinlock held by z
CONFIRMED is set but there is no guarantee ct will be added to hash:
"chaintoolong" or "clash resolution" logic both skip the insert step. reply hnnode.pprev still stores the hash value.
unlocks spinlock return NF_DROP
<unblocks, then
crashes on hlist_nulls_del_rcu pprev>
In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs.
Without 'cpu y' race, 'garbage' hlist is of no consequence:
ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy.
To resolve this, move the IPS_CONFIRMED assignment after the table insertion but before the unlock.
Pablo points out that the confirm-bit-store could be reordered to happen before hlist add resp. the timeout fixup, so switch to set_bit and before_atomic memory barrier to prevent this.
It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit was set:
Such event cannot be distinguished from above "E is the old incarnation"
case: the entry will be skipped.
Also change nf_ct_should_gc() to first check the confirmed bit.
The gc sequence is:
1. Check if entry has expired, if not skip to next entry
2. Obtain a reference to the expired entry.
3. Call nf_ct_should_gc() to double-check step 1.
nf_ct_should_gc() is thus called only for entries that already failed an expiry check. After this patch, once the confirmed bit check passes ct->timeout has been altered to reflect the absolute 'best before' date instead of a relative time. Step 3 will therefore not remove the entry.
Without this change to nf_ct_should_gc() we could still get this sequence:
1. Check if entry has expired.
2. Obtain a reference.
3. Call nf_ct_should_gc() to double-check step 1:
4 - entry is still observed as expired
5 - meanwhile, ct->timeout is corrected to absolute value on other CPU
and confirm bit gets set
6 - confirm bit is seen
7 - valid entry is removed again
First do check 6), then 4) so the gc expiry check always picks up either confirmed bit unset (entry gets skipped) or expiry re-check failure for re-inited conntrack objects.
This change cannot be backported to releases before 5.19. Without commit 8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list") |= IPS_CONFIRMED line cannot be moved without further changes.
--- include/net/netfilter/nf_conntrack.h | 15 +++++++++++++-- net/netfilter/nf_conntrack_core.c | 26 ++++++++++++++++++++------ 2 files changed, 33 insertions(+), 8 deletions(-)
include/net/netfilter/nf_conntrack.h +13 -2
@@ -306,8 +306,19 @@ static inline bool nf_ct_is_expired(const struct nf_conn *ct)/* use after obtaining a reference count */ static inline bool nf_ct_should_gc (const struct nf_conn *ct) { -return nf_ct_is_expired (ct) &&nf_ct_is_confirmed (ct) && - !nf_ct_is_dying (ct); +if (!nf_ct_is_confirmed (ct)) +return false; + +/* load ct->timeout after is_confirmed() test. +* Pairs with __nf_conntrack_confirm() which: +* 1. Increases ct->timeout value +* 2. Inserts ct into rcu hlist +* 3. Sets the confirmed bit +* 4. Unlocks the hlist lock +*/ +smp_acquire__after_ctrl_dep (); + +return nf_ct_is_expired (ct) && !nf_ct_is_dying (ct); }#define NF_CT_DAY (86400 * HZ)
net/netfilter/nf_conntrack_core.c +20 -6
@@ -1121,6 +1121,12 @@ static int nf_ct_resolve_clash_harder(struct sk_buff *skb, u32 repl_idx)hlist_nulls_add_head_rcu (&loser_ct->tuplehash[IP_CT_DIR_REPLY ].hnnode, &nf_conntrack_hash[repl_idx]); +/* confirmed bit must be set after hlist add, not before: +* loser_ct can still be visible to other cpu due to +* SLAB_TYPESAFE_BY_RCU. +*/ +smp_mb__before_atomic (); +set_bit (IPS_CONFIRMED_BIT , &loser_ct->status);NF_CT_STAT_INC (net, clash_resolve);return NF_ACCEPT ;
@@ -1257,8 +1263,6 @@ __nf_conntrack_confirm(struct sk_buff *skb)* user context, else we insert an already 'dead' hash, blocking * further use of that particular connection -JM. */ - ct->status |=IPS_CONFIRMED ; -if (unlikely (nf_ct_is_dying (ct))) {NF_CT_STAT_INC (net, insert_failed); goto dying;
@@ -1290,7 +1294,7 @@ __nf_conntrack_confirm(struct sk_buff *skb) } } -/* Timer relative to confirmation time, not original +/* Timeout is relative to confirmation time, not original setting time, otherwise we'd get timer wrap in weird delay cases. */ ct->timeout += nfct_time_stamp;
@@ -1298,11 +1302,21 @@ __nf_conntrack_confirm(struct sk_buff *skb)__nf_conntrack_insert_prepare (ct);/* Since the lookup is lockless, hash insertion must be done after -* starting the timer and setting the CONFIRMED bit. The RCU barriers -* guarantee that no other CPU can find the conntrack before the above -* stores are visible. +* setting ct->timeout. The RCU barriers guarantee that no other CPU +* can find the conntrack before the above stores are visible. */ __nf_conntrack_hash_insert (ct, hash, reply_hash); + +/* IPS_CONFIRMED unset means 'ct not (yet) in hash', conntrack lookups +* skip entries that lack this bit. This happens when a CPU is looking +* at a stale entry that is being recycled due to SLAB_TYPESAFE_BY_RCU +* or when another CPU encounters this entry right after the insertion +* but before the set-confirm-bit below. This bit must not be set until +* after __nf_conntrack_hash_insert(). +*/ +smp_mb__before_atomic (); +set_bit (IPS_CONFIRMED_BIT , &ct->status); +nf_conntrack_double_unlock (hash, reply_hash);local_bh_enable ();
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 146/187 drm/xe: Dont skip TLB invalidations on VF
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejas Upadhyay <[email protected]>
[ Upstream commit fd25fa90edcfd4db5bf69c11621021a7cfd11d53 ]
Skipping TLB invalidations on VF causing unrecoverable faults. Probable reason for skipping TLB invalidations on SRIOV could be lack of support for instruction MI_FLUSH_DW_STORE_INDEX. Add back TLB flush with some additional handling.
Helps in resolving,
[ 704.913454] xe 0000:00:02.1: [drm:pf_queue_work_func [xe]]
ASID: 0
VFID: 0
PDATA: 0x0d92
Faulted Address: 0x0000000002fa0000
FaultType: 0
AccessType: 1
FaultLevel: 0
EngineClass: 3 bcs
EngineInstance: 8
[ 704.913551] xe 0000:00:02.1: [drm:pf_queue_work_func [xe]] Fault response: Unsuccessful -22V2:
- Use Xmas tree (MichalW)
--- drivers/gpu/drm/xe/xe_ring_ops.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-)
drivers/gpu/drm/xe/xe_ring_ops.c +10 -12
@@ -110,13 +110,14 @@ static int emit_bb_start(u64 batch_addr, u32 ppgtt_flag, u32 *dw, int i)return i; } -static int emit_flush_invalidate (u32 *dw,int i) +static int emit_flush_invalidate (u32 addr,u32 val,u32 *dw,int i) { dw[i++] =MI_FLUSH_DW |MI_INVALIDATE_TLB |MI_FLUSH_DW_OP_STOREDW | -MI_FLUSH_IMM_DW |MI_FLUSH_DW_STORE_INDEX ; - dw[i++] =LRC_PPHWSP_FLUSH_INVAL_SCRATCH_ADDR ; - dw[i++] =0 ; +MI_FLUSH_IMM_DW ; + + dw[i++] = addr |MI_FLUSH_DW_USE_GTT ; dw[i++] =0 ; + dw[i++] = val;return i; }
@@ -397,23 +398,20 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job,static void emit_migration_job_gen12 (struct xe_sched_job *job,struct xe_lrc *lrc,u32 seqno) { +u32 saddr =xe_lrc_start_seqno_ggtt_addr (lrc);u32 dw[MAX_JOB_SIZE_DW ], i =0 ; i =emit_copy_timestamp (lrc, dw, i); - i =emit_store_imm_ggtt (xe_lrc_start_seqno_ggtt_addr (lrc), - seqno, dw, i); + i =emit_store_imm_ggtt (saddr, seqno, dw, i); dw[i++] =MI_ARB_ON_OFF |MI_ARB_DISABLE ;/* Enabled again below */ i =emit_bb_start (job->ptrs[0 ].batch_addr,BIT (8 ), dw, i); -if (!IS_SRIOV_VF (gt_to_xe (job->q->gt))) { -/* XXX: Do we need this? Leaving for now. */ - dw[i++] =preparser_disable (true); - i =emit_flush_invalidate (dw, i); - dw[i++] =preparser_disable (false); - } + dw[i++] =preparser_disable (true); + i =emit_flush_invalidate (saddr, seqno, dw, i); + dw[i++] =preparser_disable (false); i =emit_bb_start (job->ptrs[1 ].batch_addr,BIT (8 ), dw, i);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 147/187 drm/xe/pf: Prepare to stop SR-IOV support prior GT reset
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Wajdeczko <[email protected]>
[ Upstream commit 81dccec448d204e448ae83e1fe60e8aaeaadadb8 ]
As part of the resume or GT reset, the PF driver schedules work which is then used to complete restarting of the SR-IOV support, including resending to the GuC configurations of provisioned VFs.
However, in case of short delay between those two actions, which could be seen by triggering a GT reset on the suspened device:
$ echo 1 > /sys/kernel/debug/dri/0000:00:02.0/gt0/force_reset
this PF worker might be still busy, which lead to errors due to just stopped or disabled GuC CTB communication:
[ ] xe 0000:00:02.0: [drm:xe_gt_resume [xe]] GT0: resumed
[ ] xe 0000:00:02.0: [drm] GT0: trying reset from force_reset_show [xe]
[ ] xe 0000:00:02.0: [drm] GT0: reset queued
[ ] xe 0000:00:02.0: [drm] GT0: reset started
[ ] xe 0000:00:02.0: [drm:guc_ct_change_state [xe]] GT0: GuC CT communication channel stopped [ ] xe 0000:00:02.0: [drm:guc_ct_send_recv [xe]] GT0: H2G request 0x5503 canceled! [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 12 config KLVs (-ECANCELED) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 configuration (-ECANCELED) [ ] xe 0000:00:02.0: [drm:guc_ct_change_state [xe]] GT0: GuC CT communication channel disabled [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF2 12 config KLVs (-ENODEV) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF2 configuration (-ENODEV) [ ] xe 0000:00:02.0: [drm] GT0: PF: Failed to push 2 of 2 VFs configurations
[ ] xe 0000:00:02.0: [drm:pf_worker_restart_func [xe]] GT0: PF: restart completed
While this VFs reprovisioning will be successful during next spin of the worker, to avoid those errors, make sure to cancel restart worker if we are about to trigger next reset.
--- drivers/gpu/drm/xe/xe_gt.c | 3 +++ drivers/gpu/drm/xe/xe_gt_sriov_pf.c | 19 +++++++++++++++++++ drivers/gpu/drm/xe/xe_gt_sriov_pf.h | 5 +++++ 3 files changed, 27 insertions(+)
drivers/gpu/drm/xe/xe_gt.c +3 -0
@@ -797,6 +797,9 @@ static int gt_reset(struct xe_gt *gt) goto err_out; } +if (IS_SRIOV_PF (gt_to_xe (gt))) +xe_gt_sriov_pf_stop_prepare (gt); +xe_uc_gucrc_disable (>->uc);xe_uc_stop_prepare (>->uc);xe_gt_pagefault_reset (gt);
drivers/gpu/drm/xe/xe_gt_sriov_pf.c +19 -0
@@ -172,6 +172,25 @@ void xe_gt_sriov_pf_sanitize_hw(struct xe_gt *gt, unsigned int vfid)pf_clear_vf_scratch_regs (gt, vfid); } +static void pf_cancel_restart (struct xe_gt *gt) +{ +xe_gt_assert (gt,IS_SRIOV_PF (gt_to_xe (gt))); + +if (cancel_work_sync (>->sriov.pf.workers.restart)) +xe_gt_sriov_dbg_verbose (gt,"pending restart canceled!\n" ); +} + +/** +* xe_gt_sriov_pf_stop_prepare() - Prepare to stop SR-IOV support. +* @gt: the &xe_gt +* +* This function can only be called on the PF. +*/ +void xe_gt_sriov_pf_stop_prepare (struct xe_gt *gt) +{ +pf_cancel_restart (gt); +} +static void pf_restart (struct xe_gt *gt) {struct xe_device *xe =gt_to_xe (gt);
drivers/gpu/drm/xe/xe_gt_sriov_pf.h +5 -0
@@ -13,6 +13,7 @@ int xe_gt_sriov_pf_init_early(struct xe_gt *gt);int xe_gt_sriov_pf_init (struct xe_gt *gt);void xe_gt_sriov_pf_init_hw (struct xe_gt *gt);void xe_gt_sriov_pf_sanitize_hw (struct xe_gt *gt,unsigned int vfid); +void xe_gt_sriov_pf_stop_prepare (struct xe_gt *gt);void xe_gt_sriov_pf_restart (struct xe_gt *gt);#else static inline int xe_gt_sriov_pf_init_early (struct xe_gt *gt)
@@ -29,6 +30,10 @@ static inline void xe_gt_sriov_pf_init_hw(struct xe_gt *gt) { } +static inline void xe_gt_sriov_pf_stop_prepare (struct xe_gt *gt) +{ +} +static inline void xe_gt_sriov_pf_restart (struct xe_gt *gt) { }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 148/187 drm/xe/pf: Resend PF provisioning after GT reset
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Wajdeczko <[email protected]>
[ Upstream commit 5c244eeca57ff4e47e1f60310d059346d1b86b9b ]
If we reload the GuC due to suspend/resume or GT reset then we have to resend not only any VFs provisioning data, but also PF configuration, like scheduling parameters (EQ, PT), as otherwise GuC will continue to use default values.
--- drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+)
drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c +27 -0
@@ -2356,6 +2356,21 @@ int xe_gt_sriov_pf_config_restore(struct xe_gt *gt, unsigned int vfid,return err; } +static int pf_push_self_config (struct xe_gt *gt) +{ +int err; + + err =pf_push_full_vf_config (gt,PFID ); +if (err) { +xe_gt_sriov_err (gt,"Failed to push self configuration (%pe)\n" , +ERR_PTR (err)); +return err; + } + +xe_gt_sriov_dbg_verbose (gt,"self configuration completed\n" ); +return 0 ; +} +static void fini_config (void *arg) {struct xe_gt *gt = arg;
@@ -2379,9 +2394,17 @@ static void fini_config(void *arg)int xe_gt_sriov_pf_config_init (struct xe_gt *gt) {struct xe_device *xe =gt_to_xe (gt); +int err;xe_gt_assert (gt,IS_SRIOV_PF (xe)); +mutex_lock (xe_gt_sriov_pf_master_mutex (gt)); + err =pf_push_self_config (gt); +mutex_unlock (xe_gt_sriov_pf_master_mutex (gt)); + +if (err) +return err; +return devm_add_action_or_reset (xe->drm.dev, fini_config, gt); }
@@ -2399,6 +2422,10 @@ void xe_gt_sriov_pf_config_restart(struct xe_gt *gt)unsigned int n, total_vfs =xe_sriov_pf_get_totalvfs (gt_to_xe (gt));unsigned int fail =0 , skip =0 ; +mutex_lock (xe_gt_sriov_pf_master_mutex (gt)); +pf_push_self_config (gt); +mutex_unlock (xe_gt_sriov_pf_master_mutex (gt)); +for (n =1 ; n <= total_vfs; n++) {if (xe_gt_sriov_pf_config_is_empty (gt, n)) skip++;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 149/187 Bluetooth: L2CAP: Fix attempting to adjust outgoing MTU
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit d24e4a7fedae121d33fb32ad785b87046527eedb ]
Configuration request only configure the incoming direction of the peer initiating the request, so using the MTU is the other direction shall not be used, that said the spec allows the peer responding to adjust:
Bluetooth Core 6.1, Vol 3, Part A, Section 4.5
'Each configuration parameter value (if any is present) in an L2CAP_CONFIGURATION_RSP packet reflects an ‘adjustment’ to a configuration parameter value that has been sent (or, in case of default values, implied) in the corresponding L2CAP_CONFIGURATION_REQ packet.'
That said adjusting the MTU in the response shall be limited to ERTM channels only as for older modes the remote stack may not be able to detect the adjustment causing it to silently drop packets.
--- net/bluetooth/l2cap_core.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-)
net/bluetooth/l2cap_core.c +21 -5
@@ -3520,12 +3520,28 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data/* Configure output options and let the other side know * which ones we don't like. */ -/* If MTU is not provided in configure request, use the most recently -* explicitly or implicitly accepted value for the other direction, -* or the default value. +/* If MTU is not provided in configure request, try adjusting it +* to the current output MTU if it has been set +* +* Bluetooth Core 6.1, Vol 3, Part A, Section 4.5 +* +* Each configuration parameter value (if any is present) in an +* L2CAP_CONFIGURATION_RSP packet reflects an ‘adjustment’ to a +* configuration parameter value that has been sent (or, in case +* of default values, implied) in the corresponding +* L2CAP_CONFIGURATION_REQ packet. */ -if (mtu ==0 ) - mtu = chan->imtu ? chan->imtu :L2CAP_DEFAULT_MTU ; +if (!mtu) { +/* Only adjust for ERTM channels as for older modes the +* remote stack may not be able to detect that the +* adjustment causing it to silently drop packets. +*/ +if (chan->mode ==L2CAP_MODE_ERTM && + chan->omtu && chan->omtu !=L2CAP_DEFAULT_MTU ) + mtu = chan->omtu; +else + mtu =L2CAP_DEFAULT_MTU ; + }if (mtu <L2CAP_DEFAULT_MIN_MTU ) result =L2CAP_CONF_UNACCEPT ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 150/187 hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to prevent IPv6 addrconf
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Tian <[email protected]>
[ Upstream commit d7501e076d859d2f381d57bd984ff6db13172727 ]
Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
Commit under Fixes added a new flag change that was not made to hv_netvsc resulting in the VF being assinged an IPv6.
--- drivers/net/hyperv/netvsc_drv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/hyperv/netvsc_drv.c +4 -1
@@ -2317,8 +2317,11 @@ static int netvsc_prepare_bonding(struct net_device *vf_netdev)if (!ndev)return NOTIFY_DONE ; -/* set slave flag before open to prevent IPv6 addrconf */ +/* Set slave flag and no addrconf flag before open +* to prevent IPv6 addrconf. +*/ vf_netdev->flags |=IFF_SLAVE ; + vf_netdev->priv_flags |=IFF_NO_ADDRCONF ;return NOTIFY_DONE ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 151/187 virtio-net: fix recursived rtnl_lock() during probe()
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zigit Zo <[email protected]>
[ Upstream commit be5dcaed694e4255dc02dd0acfe036708c535def ]
The deadlock appears in a stack trace like:
virtnet_probe()
rtnl_lock()
virtio_config_changed_work()
netdev_notify_peers()
rtnl_lock()It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing.
The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable().
--- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/virtio_net.c +1 -1
@@ -7074,7 +7074,7 @@ static int virtnet_probe(struct virtio_device *vdev)otherwise get link status from config. */ netif_carrier_off (dev);if (virtio_has_feature (vi->vdev,VIRTIO_NET_F_STATUS )) { -virtnet_config_changed_work (&vi->config_work); +virtio_config_changed (vi->vdev); }else { vi->status =VIRTIO_NET_S_LINK_UP ;virtnet_update_settings (vi);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 152/187 tls: always refresh the queue when reading sock
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit 4ab26bce3969f8fd925fe6f6f551e4d1a508c68b ]
After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry.
BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]
(net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)
Read of size 4 at addr ffff888013085750 by task tls/13529
CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme
Call Trace:
kasan_report+0xca/0x100
tls_strp_check_rcv+0x898/0x9a0 [tls]
tls_rx_rec_wait+0x2c9/0x8d0 [tls]
tls_sw_recvmsg+0x40f/0x1aa0 [tls]
inet_recvmsg+0x1c3/0x1f0Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len").
--- net/tls/tls_strp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
net/tls/tls_strp.c +1 -2
@@ -512,9 +512,8 @@ static int tls_strp_read_sock(struct tls_strparser *strp)if (inq < strp->stm.full_len)return tls_strp_read_copy (strp, true); +tls_strp_load_anchor_with_queue (strp, inq);if (!strp->stm.full_len) { -tls_strp_load_anchor_with_queue (strp, inq); - sz =tls_rx_msg_size (strp, strp->anchor);if (sz <0 ) {tls_strp_abort_strp (strp, sz);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 153/187 net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dong Chenchen <[email protected]>
[ Upstream commit 579d4f9ca9a9a605184a9b162355f6ba131f678d ]
Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme.
The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running:
# ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1
When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1].
Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime:
$ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0
Root cause is as below:
step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev
vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1
step2: disable vlan filter feature and enable real_dev
step3: change filter from 0 to 1vlan_device_event
vlan_filter_push_vids
ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0
step4: real_dev downvlan_device_event
vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0
vlan_info_rcu_free //free vlan0
step5: delete vlan0unregister_vlan_dev
BUG_ON(!vlan_info); //vlan_info is null
Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature.
[1]
unreferenced object 0xffff8880068e3100 (size 256):
comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes):
00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 81ce31fa):
__kmalloc_cache_noprof+0x2b5/0x340
vlan_vid_add+0x434/0x940
vlan_device_event.cold+0x75/0xa8
notifier_call_chain+0xca/0x150
__dev_notify_flags+0xe3/0x250
rtnl_configure_link+0x193/0x260
rtnl_newlink_create+0x383/0x8e0
__rtnl_newlink+0x22c/0xa40
rtnl_newlink+0x627/0xb00
rtnetlink_rcv_msg+0x6fb/0xb70
netlink_rcv_skb+0x11f/0x350
netlink_unicast+0x426/0x710
netlink_sendmsg+0x75a/0xc20
__sock_sendmsg+0xc1/0x150
____sys_sendmsg+0x5aa/0x7b0
___sys_sendmsg+0xfc/0x180[2]
kernel BUG at net/8021q/vlan.c:99!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK> rtnl_dellink (net/core/rtnetlink.c:3511 net/core/rtnetlink.c:3553)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6945)netlink_rcv_skb (net/netlink/af_netlink.c:2535)netlink_unicast (net/netlink/af_netlink.c:1314 net/netlink/af_netlink.c:1339) netlink_sendmsg (net/netlink/af_netlink.c:1883)____sys_sendmsg (net/socket.c:712 net/socket.c:727 net/socket.c:2566) ___sys_sendmsg (net/socket.c:2622)__sys_sendmsg (net/socket.c:2652)do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
--- net/8021q/vlan.c | 42 +++++++++++++++++++++++++++++++++--------- net/8021q/vlan.h | 1 + 2 files changed, 34 insertions(+), 9 deletions(-)
net/8021q/vlan.c +33 -9
@@ -358,6 +358,35 @@ static int __vlan_device_event(struct net_device *dev, unsigned long event)return err; } +static void vlan_vid0_add (struct net_device *dev) +{ +struct vlan_info *vlan_info; +int err; + +if (!(dev->features &NETIF_F_HW_VLAN_CTAG_FILTER )) +return ; + +pr_info ("adding VLAN 0 to HW filter on device %s\n" , dev->name); + + err =vlan_vid_add (dev,htons (ETH_P_8021Q ),0 ); +if (err) +return ; + + vlan_info =rtnl_dereference (dev->vlan_info); + vlan_info->auto_vid0 = true; +} + +static void vlan_vid0_del (struct net_device *dev) +{ +struct vlan_info *vlan_info =rtnl_dereference (dev->vlan_info); + +if (!vlan_info || !vlan_info->auto_vid0) +return ; + + vlan_info->auto_vid0 = false; +vlan_vid_del (dev,htons (ETH_P_8021Q ),0 ); +} +static int vlan_device_event (struct notifier_block *unused,unsigned long event,void *ptr) {
@@ -379,15 +408,10 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,return notifier_from_errno (err); } -if ((event ==NETDEV_UP ) && - (dev->features &NETIF_F_HW_VLAN_CTAG_FILTER )) { -pr_info ("adding VLAN 0 to HW filter on device %s\n" , - dev->name); -vlan_vid_add (dev,htons (ETH_P_8021Q ),0 ); - } -if (event ==NETDEV_DOWN && - (dev->features &NETIF_F_HW_VLAN_CTAG_FILTER )) -vlan_vid_del (dev,htons (ETH_P_8021Q ),0 ); +if (event ==NETDEV_UP ) +vlan_vid0_add (dev); +else if (event ==NETDEV_DOWN ) +vlan_vid0_del (dev); vlan_info =rtnl_dereference (dev->vlan_info);if (!vlan_info)
net/8021q/vlan.h +1 -0
@@ -33,6 +33,7 @@ struct vlan_info {struct vlan_group grp;struct list_head vid_list;unsigned int nr_vids; +bool auto_vid0;struct rcu_head rcu; };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 154/187 net: bridge: Do not offload IGMP/MLD messages
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Huang <[email protected]>
[ Upstream commit 683dc24da8bf199bb7446e445ad7f801c79a550e ]
Do not offload IGMP/MLD messages as it could lead to IGMP/MLD Reports being unintentionally flooded to Hosts. Instead, let the bridge decide where to send these IGMP/MLD messages.
Consider the case where the local host is sending out reports in response to a remote querier like the following:
mcast-listener-process (IP_ADD_MEMBERSHIP)
\
br0
/ \
swp1 swp2
| |QUERIER SOME-OTHER-HOST
In the above setup, br0 will want to br_forward() reports for mcast-listener-process's group(s) via swp1 to QUERIER; but since the source hwdom is 0, the report is eligible for tx offloading, and is flooded by hardware to both swp1 and swp2, reaching SOME-OTHER-HOST as well. (Example and illustration provided by Tobias.)
--- net/bridge/br_switchdev.c | 3 +++ 1 file changed, 3 insertions(+)
net/bridge/br_switchdev.c +3 -0
@@ -17,6 +17,9 @@ static bool nbp_switchdev_can_offload_tx_fwd(const struct net_bridge_port *p,if (!static_branch_unlikely (&br_switchdev_tx_fwd_offload))return false; +if (br_multicast_igmp_type (skb)) +return false; +return (p->flags &BR_TX_FWD_OFFLOAD ) && (p->hwdom !=BR_INPUT_SKB_CB (skb)->src_hwdom); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 155/187 net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Liu <[email protected]>
[ Upstream commit 0e1d5d9b5c5966e2e42e298670808590db5ed628 ]
htb_lookup_leaf has a BUG_ON that can trigger with the following:
tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1
The root cause is the following:
1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc
2. netem_dequeue calls enqueue on the child qdisc
3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS
4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase
5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL
6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON
The function graph for this scenario is shown here:
0) | htb_enqueue() {
0) + 13.635 us | netem_enqueue();
0) 4.719 us | htb_activate_prios();
0) # 2249.199 us | }
0) | htb_dequeue() {
0) 2.355 us | htb_lookup_leaf();
0) | netem_dequeue() {
0) + 11.061 us | blackhole_enqueue();
0) | qdisc_tree_reduce_backlog() {
0) | qdisc_lookup_rcu() {
0) 1.873 us | qdisc_match_from_root();
0) 6.292 us | }
0) 1.894 us | htb_search();
0) | htb_qlen_notify() {
0) 2.655 us | htb_deactivate_prios();
0) 6.933 us | }
0) + 25.227 us | }
0) 1.983 us | blackhole_dequeue();
0) + 86.553 us | }
0) # 2932.761 us | qdisc_warn_nonwc();
0) | htb_lookup_leaf() {
0) | BUG_ON();------------------------------------------
The full original bug report can be seen here [1].
We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL.
--- net/sched/sch_htb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/sched/sch_htb.c +3 -1
@@ -821,7 +821,9 @@ static struct htb_class *htb_lookup_leaf(struct htb_prio *hprio, const int prio)u32 *pid; } stk[TC_HTB_MAXDEPTH ], *sp = stk; -BUG_ON (!hprio->row.rb_node); +if (unlikely (!hprio->row.rb_node)) +return NULL ; + sp->root = hprio->row.rb_node; sp->pptr = &hprio->ptr; sp->pid = &hprio->last_ptr_id;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 156/187 rxrpc: Fix irq-disabled in local_bh_enable()
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit e4d2878369d590bf8455e3678a644e503172eafa ]
The rxrpc_assess_MTU_size() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpc_new_incoming_call() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses local_bh_enable() which, config dependent, throws a warning if IRQs are enabled:
WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0 ... RIP: 0010:__local_bh_enable_ip+0x43/0xd0 ... Call Trace: <TASK> rt_cache_route+0x7e/0xa0 rt_set_nexthop.isra.0+0x3b3/0x3f0 __mkroute_output+0x43a/0x460 ip_route_output_key_hash+0xf7/0x140 ip_route_output_flow+0x1b/0x90 rxrpc_assess_MTU_size.isra.0+0x2a0/0x590 rxrpc_new_incoming_peer+0x46/0x120 rxrpc_alloc_incoming_call+0x1b1/0x400 rxrpc_new_incoming_call+0x1da/0x5e0 rxrpc_input_packet+0x827/0x900 rxrpc_io_thread+0x403/0xb60 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 ... hardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50 hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70 softirqs last enabled at (0): copy_process+0xc61/0x2730 softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90
Fix this by moving the call to rxrpc_assess_MTU_size() out of rxrpc_init_peer() and further up the stack where it can be done without interrupts disabled.
It shouldn't be a problem for rxrpc_new_incoming_call() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point.
--- net/rxrpc/ar-internal.h | 1 + net/rxrpc/call_accept.c | 1 + net/rxrpc/peer_object.c | 6 ++---- 3 files changed, 4 insertions(+), 4 deletions(-)
net/rxrpc/ar-internal.h +1 -0
@@ -1315,6 +1315,7 @@ struct rxrpc_peer *rxrpc_lookup_peer_rcu(struct rxrpc_local *, const struct sockaddr_rxrpc *);struct rxrpc_peer *rxrpc_lookup_peer (struct rxrpc_local *local,struct sockaddr_rxrpc *srx,gfp_t gfp); +void rxrpc_assess_MTU_size (struct rxrpc_local *local,struct rxrpc_peer *peer);struct rxrpc_peer *rxrpc_alloc_peer (struct rxrpc_local *,gfp_t ,enum rxrpc_peer_trace );void rxrpc_new_incoming_peer (struct rxrpc_local *local,struct rxrpc_peer *peer);
net/rxrpc/call_accept.c +1 -0
@@ -404,6 +404,7 @@ bool rxrpc_new_incoming_call(struct rxrpc_local *local,spin_unlock (&rx->incoming_lock);read_unlock_irq (&local->services_lock); +rxrpc_assess_MTU_size (local, call->peer);if (hlist_unhashed (&call->error_link)) {spin_lock_irq (&call->peer->lock);
net/rxrpc/peer_object.c +2 -4
@@ -149,8 +149,7 @@ struct rxrpc_peer *rxrpc_lookup_peer_rcu(struct rxrpc_local *local,* assess the MTU size for the network interface through which this peer is * reached */ -static void rxrpc_assess_MTU_size (struct rxrpc_local *local, -struct rxrpc_peer *peer) +void rxrpc_assess_MTU_size (struct rxrpc_local *local,struct rxrpc_peer *peer) {struct net *net = local->net;struct dst_entry *dst;
@@ -277,8 +276,6 @@ static void rxrpc_init_peer(struct rxrpc_local *local, struct rxrpc_peer *peer, peer->hdrsize +=sizeof (struct rxrpc_wire_header ); peer->max_data = peer->if_mtu - peer->hdrsize; - -rxrpc_assess_MTU_size (local, peer); }/*
@@ -297,6 +294,7 @@ static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_local *local,if (peer) {memcpy (&peer->srx, srx,sizeof (*srx));rxrpc_init_peer (local, peer, hash_key); +rxrpc_assess_MTU_size (local, peer); }_leave (" = %p" , peer);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 157/187 rxrpc: Fix recv-recv race of completed call
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 962fb1f651c2cf2083e0c3ef53ba69e3b96d3fbc ]
If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again.
In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message).
The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly:
kernel BUG at net/rxrpc/recvmsg.c:474!
Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale.
--- include/trace/events/rxrpc.h | 3 +++ net/rxrpc/call_accept.c | 1 + net/rxrpc/recvmsg.c | 19 +++++++++++++++++-- 3 files changed, 21 insertions(+), 2 deletions(-)
include/trace/events/rxrpc.h +3 -0
@@ -283,12 +283,15 @@ EM(rxrpc_call_put_userid, "PUT user-id ") \ EM(rxrpc_call_see_accept, "SEE accept ") \ EM(rxrpc_call_see_activate_client, "SEE act-clnt") \ + EM(rxrpc_call_see_already_released, "SEE alrdy-rl") \ EM(rxrpc_call_see_connect_failed, "SEE con-fail") \ EM(rxrpc_call_see_connected, "SEE connect ") \ EM(rxrpc_call_see_conn_abort, "SEE conn-abt") \ + EM(rxrpc_call_see_discard, "SEE discard ") \ EM(rxrpc_call_see_disconnected, "SEE disconn ") \ EM(rxrpc_call_see_distribute_error, "SEE dist-err") \ EM(rxrpc_call_see_input, "SEE input ") \ + EM(rxrpc_call_see_recvmsg, "SEE recvmsg ") \ EM(rxrpc_call_see_release, "SEE release ") \ EM(rxrpc_call_see_userid_exists, "SEE u-exists") \EM (rxrpc_call_see_waiting_call,"SEE q-conn " ) \
net/rxrpc/call_accept.c +1 -0
@@ -219,6 +219,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx) tail = b->call_backlog_tail;while (CIRC_CNT (head, tail, size) >0 ) {struct rxrpc_call *call = b->call_backlog[tail]; +rxrpc_see_call (call, rxrpc_call_see_discard);rcu_assign_pointer (call->socket, rx);if (rx->discard_new_call) {_debug ("discard %lx" , call->user_call_ID);
net/rxrpc/recvmsg.c +17 -2
@@ -351,6 +351,16 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, goto try_again; } +rxrpc_see_call (call, rxrpc_call_see_recvmsg); +if (test_bit (RXRPC_CALL_RELEASED , &call->flags)) { +rxrpc_see_call (call, rxrpc_call_see_already_released); +list_del_init (&call->recvmsg_link); +spin_unlock_irq (&rx->recvmsg_lock); +release_sock (&rx->sk); +trace_rxrpc_recvmsg (call->debug_id, rxrpc_recvmsg_unqueue,0 ); +rxrpc_put_call (call, rxrpc_call_put_recvmsg); + goto try_again; + }if (!(flags &MSG_PEEK ))list_del_init (&call->recvmsg_link);else
@@ -374,8 +384,13 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,release_sock (&rx->sk); -if (test_bit (RXRPC_CALL_RELEASED , &call->flags)) -BUG (); +if (test_bit (RXRPC_CALL_RELEASED , &call->flags)) { +rxrpc_see_call (call, rxrpc_call_see_already_released); +mutex_unlock (&call->user_mutex); +if (!(flags &MSG_PEEK )) +rxrpc_put_call (call, rxrpc_call_put_recvmsg); + goto try_again; + }if (test_bit (RXRPC_CALL_HAS_USERID , &call->flags)) {if (flags &MSG_CMSG_COMPAT ) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 158/187 rxrpc: Fix notification vs call-release vs recvmsg
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit 2fd895842d49c23137ae48252dd211e5d6d8a3ed ]
When a call is released, rxrpc takes the spinlock and removes it from ->recvmsg_q in an effort to prevent racing recvmsg() invocations from seeing the same call. Now, rxrpc_recvmsg() only takes the spinlock when actually removing a call from the queue; it doesn't, however, take it in the lead up to that when it checks to see if the queue is empty. It *does* hold the socket lock, which prevents a recvmsg/recvmsg race - but this doesn't prevent sendmsg from ending the call because sendmsg() drops the socket lock and relies on the call->user_mutex.
Fix this by firstly removing the bit in rxrpc_release_call() that dequeues the released call and, instead, rely on recvmsg() to simply discard released calls (done in a preceding fix).
Secondly, rxrpc_notify_socket() is abandoned if the call is already marked as released rather than trying to be clever by setting both pointers in call->recvmsg_link to NULL to trick list_empty(). This isn't perfect and can still race, resulting in a released call on the queue, but recvmsg() will now clean that up.
--- include/trace/events/rxrpc.h | 3 ++- net/rxrpc/call_object.c | 28 ++++++++++++---------------- net/rxrpc/recvmsg.c | 4 ++++ 3 files changed, 18 insertions(+), 17 deletions(-)
include/trace/events/rxrpc.h +2 -1
@@ -275,10 +275,10 @@ EM(rxrpc_call_put_kernel, "PUT kernel ") \ EM(rxrpc_call_put_poke, "PUT poke ") \ EM(rxrpc_call_put_recvmsg, "PUT recvmsg ") \ + EM(rxrpc_call_put_release_recvmsg_q, "PUT rls-rcmq") \ EM(rxrpc_call_put_release_sock, "PUT rls-sock") \ EM(rxrpc_call_put_release_sock_tba, "PUT rls-sk-a") \ EM(rxrpc_call_put_sendmsg, "PUT sendmsg ") \ - EM(rxrpc_call_put_unnotify, "PUT unnotify") \ EM(rxrpc_call_put_userid_exists, "PUT u-exists") \ EM(rxrpc_call_put_userid, "PUT user-id ") \EM (rxrpc_call_see_accept,"SEE accept " ) \
@@ -291,6 +291,7 @@ EM(rxrpc_call_see_disconnected, "SEE disconn ") \ EM(rxrpc_call_see_distribute_error, "SEE dist-err") \ EM(rxrpc_call_see_input, "SEE input ") \ + EM(rxrpc_call_see_notify_released, "SEE nfy-rlsd") \ EM(rxrpc_call_see_recvmsg, "SEE recvmsg ") \ EM(rxrpc_call_see_release, "SEE release ") \EM (rxrpc_call_see_userid_exists,"SEE u-exists" ) \
net/rxrpc/call_object.c +12 -16
@@ -561,7 +561,7 @@ static void rxrpc_cleanup_rx_buffers(struct rxrpc_call *call)void rxrpc_release_call (struct rxrpc_sock *rx,struct rxrpc_call *call) {struct rxrpc_connection *conn = call->conn; -bool put = false, putu = false; +bool putu = false;_enter ("{%d,%d}" , call->debug_id,refcount_read (&call->ref));
@@ -573,23 +573,13 @@ void rxrpc_release_call(struct rxrpc_sock *rx, struct rxrpc_call *call)rxrpc_put_call_slot (call); -/* Make sure we don't get any more notifications */ +/* Note that at this point, the call may still be on or may have been +* added back on to the socket receive queue. recvmsg() must discard +* released calls. The CALL_RELEASED flag should prevent further +* notifications. +*/ spin_lock_irq (&rx->recvmsg_lock); - -if (!list_empty (&call->recvmsg_link)) { -_debug ("unlinking once-pending call %p { e=%lx f=%lx }" , - call, call->events, call->flags); -list_del (&call->recvmsg_link); - put = true; - } - -/* list_empty() must return false in rxrpc_notify_socket() */ - call->recvmsg_link.next =NULL ; - call->recvmsg_link.prev =NULL ; -spin_unlock_irq (&rx->recvmsg_lock); -if (put) -rxrpc_put_call (call, rxrpc_call_put_unnotify);write_lock (&rx->call_lock);
@@ -638,6 +628,12 @@ void rxrpc_release_calls_on_socket(struct rxrpc_sock *rx)rxrpc_put_call (call, rxrpc_call_put_release_sock); } +while ((call =list_first_entry_or_null (&rx->recvmsg_q, + struct rxrpc_call, recvmsg_link))) { +list_del_init (&call->recvmsg_link); +rxrpc_put_call (call, rxrpc_call_put_release_recvmsg_q); + } +_leave ("" ); }
net/rxrpc/recvmsg.c +4 -0
@@ -29,6 +29,10 @@ void rxrpc_notify_socket(struct rxrpc_call *call)if (!list_empty (&call->recvmsg_link))return ; +if (test_bit (RXRPC_CALL_RELEASED , &call->flags)) { +rxrpc_see_call (call, rxrpc_call_see_notify_released); +return ; + }rcu_read_lock ();
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 159/187 rxrpc: Fix transmission of an abort in response to an abort
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit e9c0b96ec0a34fcacdf9365713578d83cecac34c ]
Under some circumstances, such as when a server socket is closing, ABORT packets will be generated in response to incoming packets. Unfortunately, this also may include generating aborts in response to incoming aborts - which may cause a cycle. It appears this may be made possible by giving the client a multicast address.
Fix this such that rxrpc_reject_packet() will refuse to generate aborts in response to aborts.
--- net/rxrpc/output.c | 3 +++ 1 file changed, 3 insertions(+)
net/rxrpc/output.c +3 -0
@@ -814,6 +814,9 @@ void rxrpc_reject_packet(struct rxrpc_local *local, struct sk_buff *skb)__be32 code;int ret, ioc; +if (sp->hdr.type ==RXRPC_PACKET_TYPE_ABORT ) +return ;/* Never abort an abort. */ +rxrpc_see_skb (skb, rxrpc_skb_see_reject); iov[0 ].iov_base = &whdr;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 160/187 rxrpc: Fix to use conn aborts for conn-wide failures
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
[ Upstream commit f0295678ad304195927829b1dbf06553aa2187b0 ]
Fix rxrpc to use connection-level aborts for things that affect the whole connection, such as the service ID not matching a local service.
--- net/rxrpc/ar-internal.h | 3 +++ net/rxrpc/call_accept.c | 12 ++++++------ net/rxrpc/io_thread.c | 14 ++++++++++++++ net/rxrpc/output.c | 19 ++++++++++--------- net/rxrpc/security.c | 8 ++++---- 5 files changed, 37 insertions(+), 19 deletions(-)
net/rxrpc/ar-internal.h +3 -0
@@ -42,6 +42,7 @@ enum rxrpc_skb_mark {RXRPC_SKB_MARK_SERVICE_CONN_SECURED ,/* Service connection response has been verified */ RXRPC_SKB_MARK_REJECT_BUSY ,/* Reject with BUSY */ RXRPC_SKB_MARK_REJECT_ABORT ,/* Reject with ABORT (code in skb->priority) */ + RXRPC_SKB_MARK_REJECT_CONN_ABORT, /* Reject with connection ABORT (code in skb->priority) */ };/*
@@ -1197,6 +1198,8 @@ int rxrpc_encap_rcv(struct sock *, struct sk_buff *);void rxrpc_error_report (struct sock *);bool rxrpc_direct_abort (struct sk_buff *skb,enum rxrpc_abort_reason why,s32 abort_code,int err); +bool rxrpc_direct_conn_abort (struct sk_buff *skb,enum rxrpc_abort_reason why, +s32 abort_code,int err);int rxrpc_io_thread (void *data);static inline void rxrpc_wake_up_io_thread (struct rxrpc_local *local) {
net/rxrpc/call_accept.c +6 -6
@@ -373,8 +373,8 @@ bool rxrpc_new_incoming_call(struct rxrpc_local *local,spin_lock (&rx->incoming_lock);if (rx->sk.sk_state ==RXRPC_SERVER_LISTEN_DISABLED || rx->sk.sk_state ==RXRPC_CLOSE ) { -rxrpc_direct_abort (skb, rxrpc_abort_shut_down, -RX_INVALID_OPERATION , -ESHUTDOWN ); +rxrpc_direct_conn_abort (skb, rxrpc_abort_shut_down, +RX_INVALID_OPERATION , -ESHUTDOWN ); goto no_call; }
@@ -420,12 +420,12 @@ bool rxrpc_new_incoming_call(struct rxrpc_local *local, unsupported_service:read_unlock_irq (&local->services_lock); -return rxrpc_direct_abort (skb, rxrpc_abort_service_not_offered, -RX_INVALID_OPERATION , -EOPNOTSUPP ); +return rxrpc_direct_conn_abort (skb, rxrpc_abort_service_not_offered, +RX_INVALID_OPERATION , -EOPNOTSUPP ); unsupported_security:read_unlock_irq (&local->services_lock); -return rxrpc_direct_abort (skb, rxrpc_abort_service_not_offered, -RX_INVALID_OPERATION , -EKEYREJECTED ); +return rxrpc_direct_conn_abort (skb, rxrpc_abort_service_not_offered, +RX_INVALID_OPERATION , -EKEYREJECTED ); no_call:spin_unlock (&rx->incoming_lock);read_unlock_irq (&local->services_lock);
net/rxrpc/io_thread.c +14 -0
@@ -97,6 +97,20 @@ bool rxrpc_direct_abort(struct sk_buff *skb, enum rxrpc_abort_reason why,return false; } +/* +* Directly produce a connection abort from a packet. +*/ +bool rxrpc_direct_conn_abort (struct sk_buff *skb,enum rxrpc_abort_reason why, +s32 abort_code,int err) +{ +struct rxrpc_skb_priv *sp =rxrpc_skb (skb); + +trace_rxrpc_abort (0 , why, sp->hdr.cid,0 , sp->hdr.seq, abort_code, err); + skb->mark =RXRPC_SKB_MARK_REJECT_CONN_ABORT ; + skb->priority = abort_code; +return false; +} +static bool rxrpc_bad_message (struct sk_buff *skb,enum rxrpc_abort_reason why) {return rxrpc_direct_abort (skb, why,RX_PROTOCOL_ERROR , -EBADMSG );
net/rxrpc/output.c +10 -9
@@ -829,7 +829,13 @@ void rxrpc_reject_packet(struct rxrpc_local *local, struct sk_buff *skb) msg.msg_controllen =0 ; msg.msg_flags =0 ; -memset (&whdr,0 ,sizeof (whdr)); + whdr = (struct rxrpc_wire_header ) { + .epoch =htonl (sp->hdr.epoch), + .cid =htonl (sp->hdr.cid), + .callNumber =htonl (sp->hdr.callNumber), + .serviceId =htons (sp->hdr.serviceId), + .flags = ~sp->hdr.flags &RXRPC_CLIENT_INITIATED , + };switch (skb->mark) {case RXRPC_SKB_MARK_REJECT_BUSY :
@@ -837,6 +843,9 @@ void rxrpc_reject_packet(struct rxrpc_local *local, struct sk_buff *skb) size =sizeof (whdr); ioc =1 ;break ; +case RXRPC_SKB_MARK_REJECT_CONN_ABORT : + whdr.callNumber =0 ; + fallthrough;case RXRPC_SKB_MARK_REJECT_ABORT : whdr.type =RXRPC_PACKET_TYPE_ABORT ; code =htonl (skb->priority);
@@ -850,14 +859,6 @@ void rxrpc_reject_packet(struct rxrpc_local *local, struct sk_buff *skb)if (rxrpc_extract_addr_from_skb (&srx, skb) ==0 ) { msg.msg_namelen = srx.transport_len; - whdr.epoch =htonl (sp->hdr.epoch); - whdr.cid =htonl (sp->hdr.cid); - whdr.callNumber =htonl (sp->hdr.callNumber); - whdr.serviceId =htons (sp->hdr.serviceId); - whdr.flags = sp->hdr.flags; - whdr.flags ^=RXRPC_CLIENT_INITIATED ; - whdr.flags &=RXRPC_CLIENT_INITIATED ; -iov_iter_kvec (&msg.msg_iter,WRITE , iov, ioc, size); ret =do_udp_sendmsg (local->socket, &msg, size);if (ret <0 )
net/rxrpc/security.c +4 -4
@@ -137,15 +137,15 @@ const struct rxrpc_security *rxrpc_get_incoming_security(struct rxrpc_sock *rx, sec =rxrpc_security_lookup (sp->hdr.securityIndex);if (!sec) { -rxrpc_direct_abort (skb, rxrpc_abort_unsupported_security, -RX_INVALID_OPERATION , -EKEYREJECTED ); +rxrpc_direct_conn_abort (skb, rxrpc_abort_unsupported_security, +RX_INVALID_OPERATION , -EKEYREJECTED );return NULL ; }if (sp->hdr.securityIndex !=RXRPC_SECURITY_NONE && !rx->securities) { -rxrpc_direct_abort (skb, rxrpc_abort_no_service_key, - sec->no_key_abort, -EKEYREJECTED ); +rxrpc_direct_conn_abort (skb, rxrpc_abort_no_service_key, + sec->no_key_abort, -EKEYREJECTED );return NULL ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 161/187 Revert "cgroup_freezer: cgroup_freezing: Check if not frozen"
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Ridong <[email protected]>
[ Upstream commit 14a67b42cb6f3ab66f41603c062c5056d32ea7dd ]
This reverts commit cff5f49d433fcd0063c8be7dd08fa5bf190c6c37.
Commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") modified the cgroup_freezing() logic to verify that the FROZEN flag is not set, affecting the return value of the freezing() function, in order to address a warning in __thaw_task.
A race condition exists that may allow tasks to escape being frozen. The following scenario demonstrates this issue:
CPU 0 (get_signal path) CPU 1 (freezer.state reader)try_to_freeze read freezer.state__refrigerator freezer_read
update_if_frozen
WRITE_ONCE(current->__state, TASK_FROZEN); ... /* Task is now marked frozen */ /* frozen(task) == true */ /* Assuming other tasks are frozen */ freezer->state |= CGROUP_FROZEN;
/* freezing(current) returns false */
/* because cgroup is frozen (not freezing) */ break out__set_current_state(TASK_RUNNING);
/* Bug: Task resumes running when it should remain frozen */
The existing !frozen(p) check in __thaw_task makes the WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables reverting the commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to resolve the issue.
The warning has been removed in the previous patch. This patch revert the commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to complete the fix.
--- kernel/cgroup/legacy_freezer.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
kernel/cgroup/legacy_freezer.c +1 -7
@@ -66,15 +66,9 @@ static struct freezer *parent_freezer(struct freezer *freezer)bool cgroup_freezing (struct task_struct *task) {bool ret; -unsigned int state;rcu_read_lock (); -/* Check if the cgroup is still FREEZING, but not FROZEN. The extra -* !FROZEN check is required, because the FREEZING bit is not cleared -* when the state FROZEN is reached. -*/ - state =task_freezer (task)->state; - ret = (state &CGROUP_FREEZING ) && !(state &CGROUP_FROZEN ); + ret =task_freezer (task)->state &CGROUP_FREEZING ;rcu_read_unlock ();return ret;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 162/187 drm/mediatek: Add wait_event_timeout when disabling plane
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason-JH Lin <[email protected]>
[ Upstream commit d208261e9f7c66960587b10473081dc1cecbe50b ]
Our hardware registers are set through GCE, not by the CPU. DRM might assume the hardware is disabled immediately after calling atomic_disable() of drm_plane, but it is only truly disabled after the GCE IRQ is triggered.
Additionally, the cursor plane in DRM uses async_commit, so DRM will not wait for vblank and will free the buffer immediately after calling atomic_disable().
To prevent the framebuffer from being freed before the layer disable settings are configured into the hardware, which can cause an IOMMU fault error, a wait_event_timeout has been added to wait for the ddp_cmdq_cb() callback,indicating that the GCE IRQ has been triggered.
--- drivers/gpu/drm/mediatek/mtk_crtc.c | 33 ++++++++++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_crtc.h | 1 + drivers/gpu/drm/mediatek/mtk_plane.c | 5 +++++ 3 files changed, 39 insertions(+)
drivers/gpu/drm/mediatek/mtk_crtc.c +33 -0
@@ -719,6 +719,39 @@ int mtk_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,return 0 ; } +void mtk_crtc_plane_disable (struct drm_crtc *crtc,struct drm_plane *plane) +{ +#if IS_REACHABLE (CONFIG_MTK_CMDQ ) +struct mtk_crtc *mtk_crtc =to_mtk_crtc (crtc); +struct mtk_plane_state *plane_state =to_mtk_plane_state (plane->state); +int i; + +/* no need to wait for disabling the plane by CPU */ +if (!mtk_crtc->cmdq_client.chan) +return ; + +if (!mtk_crtc->enabled) +return ; + +/* set pending plane state to disabled */ +for (i =0 ; i < mtk_crtc->layer_nr; i++) { +struct drm_plane *mtk_plane = &mtk_crtc->planes[i]; +struct mtk_plane_state *mtk_plane_state =to_mtk_plane_state (mtk_plane->state); + +if (mtk_plane->index == plane->index) { +memcpy (mtk_plane_state, plane_state,sizeof (*plane_state)); +break ; + } + } +mtk_crtc_update_config (mtk_crtc, false); + +/* wait for planes to be disabled by CMDQ */ +wait_event_timeout (mtk_crtc->cb_blocking_queue, + mtk_crtc->cmdq_vblank_cnt ==0 , +msecs_to_jiffies (500 )); +#endif +} +void mtk_crtc_async_update (struct drm_crtc *crtc,struct drm_plane *plane,struct drm_atomic_state *state) {
drivers/gpu/drm/mediatek/mtk_crtc.h +1 -0
@@ -21,6 +21,7 @@ int mtk_crtc_create(struct drm_device *drm_dev, const unsigned int *path, unsigned int num_conn_routes);int mtk_crtc_plane_check (struct drm_crtc *crtc,struct drm_plane *plane,struct mtk_plane_state *state); +void mtk_crtc_plane_disable (struct drm_crtc *crtc,struct drm_plane *plane);void mtk_crtc_async_update (struct drm_crtc *crtc,struct drm_plane *plane,struct drm_atomic_state *plane_state);struct device *mtk_crtc_dma_dev_get (struct drm_crtc *crtc);
drivers/gpu/drm/mediatek/mtk_plane.c +5 -0
@@ -285,9 +285,14 @@ static void mtk_plane_atomic_disable(struct drm_plane *plane,struct drm_plane_state *new_state =drm_atomic_get_new_plane_state (state, plane);struct mtk_plane_state *mtk_plane_state =to_mtk_plane_state (new_state); +struct drm_plane_state *old_state =drm_atomic_get_old_plane_state (state, + plane); + mtk_plane_state->pending.enable = false;wmb ();/* Make sure the above parameter is set before update */ mtk_plane_state->pending.dirty = true; + +mtk_crtc_plane_disable (old_state->crtc, plane); } static void mtk_plane_atomic_update(struct drm_plane *plane,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 163/187 drm/mediatek: only announce AFBC if really supported
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Icenowy Zheng <[email protected]>
[ Upstream commit 8d121a82fa564e0c8bd86ce4ec56b2a43b9b016e ]
Currently even the SoC's OVL does not declare the support of AFBC, AFBC is still announced to the userspace within the IN_FORMATS blob, which breaks modern Wayland compositors like KWin Wayland and others.
Gate passing modifiers to drm_universal_plane_init() behind querying the driver of the hardware block for AFBC support.
--- drivers/gpu/drm/mediatek/mtk_crtc.c | 3 ++- drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 1 + drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 9 +++++++++ drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++++++ drivers/gpu/drm/mediatek/mtk_plane.c | 7 +++++-- drivers/gpu/drm/mediatek/mtk_plane.h | 3 ++- 7 files changed, 27 insertions(+), 4 deletions(-)
drivers/gpu/drm/mediatek/mtk_crtc.c +2 -1
@@ -963,7 +963,8 @@ static int mtk_crtc_init_comp_planes(struct drm_device *drm_dev,mtk_ddp_comp_supported_rotations (comp),mtk_ddp_comp_get_blend_modes (comp),mtk_ddp_comp_get_formats (comp), - mtk_ddp_comp_get_num_formats(comp), i); +mtk_ddp_comp_get_num_formats (comp), + mtk_ddp_comp_is_afbc_supported(comp), i);if (ret)return ret;
drivers/gpu/drm/mediatek/mtk_ddp_comp.c +1 -0
@@ -366,6 +366,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = { .get_blend_modes = mtk_ovl_get_blend_modes, .get_formats = mtk_ovl_get_formats, .get_num_formats = mtk_ovl_get_num_formats, + .is_afbc_supported = mtk_ovl_is_afbc_supported, };static const struct mtk_ddp_comp_funcs ddp_postmask = {
drivers/gpu/drm/mediatek/mtk_ddp_comp.h +9 -0
@@ -83,6 +83,7 @@ struct mtk_ddp_comp_funcs {u32 (*get_blend_modes)(struct device *dev);const u32 *(*get_formats)(struct device *dev);size_t (*get_num_formats)(struct device *dev); +bool (*is_afbc_supported)(struct device *dev);void (*connect)(struct device *dev,struct device *mmsys_dev,unsigned int next);void (*disconnect)(struct device *dev,struct device *mmsys_dev,unsigned int next);void (*add)(struct device *dev,struct mtk_mutex *mutex);
@@ -294,6 +295,14 @@ size_t mtk_ddp_comp_get_num_formats(struct mtk_ddp_comp *comp)return 0 ; } +static inline bool mtk_ddp_comp_is_afbc_supported (struct mtk_ddp_comp *comp) +{ +if (comp->funcs && comp->funcs->is_afbc_supported) +return comp->funcs->is_afbc_supported (comp->dev); + +return false; +} +static inline bool mtk_ddp_comp_add (struct mtk_ddp_comp *comp,struct mtk_mutex *mutex) {if (comp->funcs && comp->funcs->add) {
drivers/gpu/drm/mediatek/mtk_disp_drv.h +1 -0
@@ -106,6 +106,7 @@ void mtk_ovl_disable_vblank(struct device *dev);u32 mtk_ovl_get_blend_modes (struct device *dev);const u32 *mtk_ovl_get_formats (struct device *dev);size_t mtk_ovl_get_num_formats (struct device *dev); +bool mtk_ovl_is_afbc_supported (struct device *dev);void mtk_ovl_adaptor_add_comp (struct device *dev,struct mtk_mutex *mutex);void mtk_ovl_adaptor_remove_comp (struct device *dev,struct mtk_mutex *mutex);
drivers/gpu/drm/mediatek/mtk_disp_ovl.c +7 -0
@@ -236,6 +236,13 @@ size_t mtk_ovl_get_num_formats(struct device *dev)return ovl->data->num_formats; } +bool mtk_ovl_is_afbc_supported (struct device *dev) +{ +struct mtk_disp_ovl *ovl =dev_get_drvdata (dev); + +return ovl->data->supports_afbc; +} +int mtk_ovl_clk_enable (struct device *dev) {struct mtk_disp_ovl *ovl =dev_get_drvdata (dev);
drivers/gpu/drm/mediatek/mtk_plane.c +5 -2
@@ -326,7 +326,8 @@ static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {int mtk_plane_init (struct drm_device *dev,struct drm_plane *plane,unsigned long possible_crtcs,enum drm_plane_type type,unsigned int supported_rotations,const u32 blend_modes, -const u32 *formats,size_t num_formats,unsigned int plane_idx) +const u32 *formats,size_t num_formats, +bool supports_afbc,unsigned int plane_idx) {int err;
@@ -337,7 +338,9 @@ int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane, err =drm_universal_plane_init (dev, plane, possible_crtcs, &mtk_plane_funcs, formats, - num_formats, modifiers, type,NULL ); + num_formats, + supports_afbc ? modifiers :NULL , + type,NULL );if (err) {DRM_ERROR ("failed to initialize plane\n" );return err;
drivers/gpu/drm/mediatek/mtk_plane.h +2 -1
@@ -49,5 +49,6 @@ to_mtk_plane_state(struct drm_plane_state *state)int mtk_plane_init (struct drm_device *dev,struct drm_plane *plane,unsigned long possible_crtcs,enum drm_plane_type type,unsigned int supported_rotations,const u32 blend_modes, -const u32 *formats,size_t num_formats,unsigned int plane_idx); +const u32 *formats,size_t num_formats, +bool supports_afbc,unsigned int plane_idx);#endif
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 164/187 libbpf: Fix handling of BPF arena relocations
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrii Nakryiko <[email protected]>
[ Upstream commit 0238c45fbbf8228f52aa4642f0cdc21c570d1dfe ]
Initial __arena global variable support implementation in libbpf contains a bug: it remembers struct bpf_map pointer for arena, which is used later on to process relocations. Recording this pointer is problematic because map pointers are not stable during ELF relocation collection phase, as an array of struct bpf_map's can be reallocated, invalidating all the pointers. Libbpf is dealing with similar issues by using a stable internal map index, though for BPF arena map specifically this approach wasn't used due to an oversight.
The resulting behavior is non-deterministic issue which depends on exact layout of ELF object file, number of actual maps, etc. We didn't hit this until very recently, when this bug started triggering crash in BPF CI when validating one of sched-ext BPF programs.
The fix is rather straightforward: we just follow an established pattern of remembering map index (just like obj->kconfig_map_idx, for example) instead of struct bpf_map *, and resolving index to a pointer at the point where map information is necessary.
While at it also add debug-level message for arena-related relocation resolution information, which we already have for all other kinds of maps.
--- tools/lib/bpf/libbpf.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-)
tools/lib/bpf/libbpf.c +13 -7
@@ -735,7 +735,7 @@ struct bpf_object {struct usdt_manager *usdt_man; -struct bpf_map *arena_map; +int arena_map_idx;void *arena_data;size_t arena_data_sz;
@@ -1517,6 +1517,7 @@ static struct bpf_object *bpf_object__new(const char *path, obj->efile.obj_buf_sz = obj_buf_sz; obj->efile.btf_maps_shndx =-1 ; obj->kconfig_map_idx =-1 ; + obj->arena_map_idx =-1 ; obj->kern_version =get_kernel_version (); obj->state =OBJ_OPEN ;
@@ -2964,7 +2965,7 @@ static int init_arena_map_data(struct bpf_object *obj, struct bpf_map *map,const long page_sz =sysconf (_SC_PAGE_SIZE);size_t mmap_sz; - mmap_sz =bpf_map_mmap_sz (obj->arena_map); + mmap_sz =bpf_map_mmap_sz (map);if (roundup (data_sz, page_sz) > mmap_sz) {pr_warn ("elf: sec '%s': declared ARENA map size (%zu) is too small to hold global __arena variables of size %zu\n" , sec_name, mmap_sz, data_sz);
@@ -3038,12 +3039,12 @@ static int bpf_object__init_user_btf_maps(struct bpf_object *obj, bool strict,if (map->def.type !=BPF_MAP_TYPE_ARENA )continue ; -if (obj->arena_map) { +if (obj->arena_map_idx >=0 ) {pr_warn ("map '%s': only single ARENA map is supported (map '%s' is also ARENA)\n" , - map->name, obj->arena_map->name); + map->name, obj->maps[obj->arena_map_idx].name);return -EINVAL ; } - obj->arena_map = map; + obj->arena_map_idx = i;if (obj->efile.arena_data) { err = init_arena_map_data(obj, map, ARENA_SEC, obj->efile.arena_data_shndx,
@@ -3053,7 +3054,7 @@ static int bpf_object__init_user_btf_maps(struct bpf_object *obj, bool strict,return err; } } -if (obj->efile.arena_data && !obj->arena_map) { +if (obj->efile.arena_data && obj->arena_map_idx <0 ) {pr_warn ("elf: sec '%s': to use global __arena variables the ARENA map should be explicitly declared in SEC(\".maps\")\n" ,ARENA_SEC );return -ENOENT ;
@@ -4583,8 +4584,13 @@ static int bpf_program__record_reloc(struct bpf_program *prog,if (shdr_idx == obj->efile.arena_data_shndx) { reloc_desc->type =RELO_DATA ; reloc_desc->insn_idx = insn_idx; - reloc_desc->map_idx = obj->arena_map - obj->maps; + reloc_desc->map_idx = obj->arena_map_idx; reloc_desc->sym_off = sym->st_value; + + map = &obj->maps[obj->arena_map_idx]; +pr_debug ("prog '%s': found arena map %d (%s, sec %d, off %zu) for insn %u\n" , + prog->name, obj->arena_map_idx, map->name, map->sec_idx, + map->sec_offset, insn_idx);return 0 ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 165/187 efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error paths
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit 64e135f1eaba0bbb0cdee859af3328c68d5b9789 ]
When processing mount options, efivarfs allocates efivarfs_fs_info (sfi) early in fs_context initialization. However, sfi is associated with the superblock and typically freed when the superblock is destroyed. If the fs_context is released (final put) before fill_super is called—such as on error paths or during reconfiguration—the sfi structure would leak, as ownership never transfers to the superblock.
Implement the .free callback in efivarfs_context_ops to ensure any allocated sfi is properly freed if the fs_context is torn down before fill_super, preventing this memory leak.
--- fs/efivarfs/super.c | 6 ++++++ 1 file changed, 6 insertions(+)
fs/efivarfs/super.c +6 -0
@@ -387,10 +387,16 @@ static int efivarfs_reconfigure(struct fs_context *fc)return 0 ; } +static void efivarfs_free (struct fs_context *fc) +{ +kfree (fc->s_fs_info); +} +static const struct fs_context_operations efivarfs_context_ops = { .get_tree = efivarfs_get_tree, .parse_param = efivarfs_parse_param, .reconfigure = efivarfs_reconfigure, + .free = efivarfs_free, };struct efivarfs_ctx {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 166/187 sched: Change nr_uninterruptible type to unsigned long
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aruna Ramakrishna <[email protected]>
commit 36569780b0d64de283f9d6c2195fd1a43e221ee8 upstream.
The commit e6fe3f422be1 ("sched: Make multiple runqueue task counters 32-bit") changed nr_uninterruptible to an unsigned int. But the nr_uninterruptible values for each of the CPU runqueues can grow to large numbers, sometimes exceeding INT_MAX. This is valid, if, over time, a large number of tasks are migrated off of one CPU after going into an uninterruptible state. Only the sum of all nr_interruptible values across all CPUs yields the correct result, as explained in a comment in kernel/sched/loadavg.c.
Change the type of nr_uninterruptible back to unsigned long to prevent overflows, and thus the miscalculation of load average.
--- kernel/sched/loadavg.c | 2 +- kernel/sched/sched.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
kernel/sched/loadavg.c +1 -1
@@ -80,7 +80,7 @@ long calc_load_fold_active(struct rq *thlong nr_active, delta =0 ; nr_active = this_rq->nr_running - adjust; - nr_active += (int )this_rq->nr_uninterruptible; + nr_active += (long )this_rq->nr_uninterruptible;if (nr_active != this_rq->calc_load_active) { delta = nr_active - this_rq->calc_load_active;
kernel/sched/sched.h +1 -1
@@ -1147,7 +1147,7 @@ struct rq {* one CPU and if it got migrated afterwards it may decrease * it on another CPU. Always updated under the runqueue lock: */ -unsigned int nr_uninterruptible; +unsigned long nr_uninterruptible;union {struct task_struct __rcu *donor;/* Scheduler context */
Greg Kroah-Hartman
maintainerPATCH 167/187 usb: hub: fix detection of high tier USB3 devices behind suspended hubs
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 8f5b7e2bec1c36578fdaa74a6951833541103e27 upstream.
USB3 devices connected behind several external suspended hubs may not be detected when plugged in due to aggressive hub runtime pm suspend.
The hub driver immediately runtime-suspends hubs if there are no active children or port activity.
There is a delay between the wake signal causing hub resume, and driver visible port activity on the hub downstream facing ports. Most of the LFPS handshake, resume signaling and link training done on the downstream ports is not visible to the hub driver until completed, when device then will appear fully enabled and running on the port.
This delay between wake signal and detectable port change is even more significant with chained suspended hubs where the wake signal will propagate upstream first. Suspended hubs will only start resuming downstream ports after upstream facing port resumes.
The hub driver may resume a USB3 hub, read status of all ports, not yet see any activity, and runtime suspend back the hub before any port activity is visible.
This exact case was seen when conncting USB3 devices to a suspended Thunderbolt dock.
USB3 specification defines a 100ms tU3WakeupRetryDelay, indicating USB3 devices expect to be resumed within 100ms after signaling wake. if not then device will resend the wake signal.
Give the USB3 hubs twice this time (200ms) to detect any port changes after resume, before allowing hub to runtime suspend again.
--- drivers/usb/core/hub.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-)
drivers/usb/core/hub.c +32 -1
@@ -68,6 +68,12 @@*/ #define USB_SHORT_SET_ADDRESS_REQ_TIMEOUT 500/* ms */ +/* +* Give SS hubs 200ms time after wake to train downstream links before +* assuming no port activity and allowing hub to runtime suspend back. +*/ +#define USB_SS_PORT_U0_WAKE_TIME 200/* ms */ +/* Protect struct usb_device->state and ->children members * Note: Both are also protected by ->dev.sem, except that ->state can * change to USB_STATE_NOTATTACHED even when the semaphore isn't held. */
@@ -1068,11 +1074,12 @@ int usb_remove_device(struct usb_deviceenum hub_activation_type {HUB_INIT ,HUB_INIT2 ,HUB_INIT3 ,/* INITs must come first */ -HUB_POST_RESET ,HUB_RESUME ,HUB_RESET_RESUME , +HUB_POST_RESET ,HUB_RESUME ,HUB_RESET_RESUME ,HUB_POST_RESUME , };static void hub_init_func2 (struct work_struct *ws);static void hub_init_func3 (struct work_struct *ws); +static void hub_post_resume (struct work_struct *ws);static void hub_activate (struct usb_hub *hub,enum hub_activation_type type) {
@@ -1095,6 +1102,13 @@ static void hub_activate(struct usb_hub goto init2; goto init3; } + +if (type ==HUB_POST_RESUME ) { +usb_autopm_put_interface_async (to_usb_interface (hub->intfdev)); +hub_put (hub); +return ; + } +hub_get (hub);/* The superspeed hub except for root hub has to use Hub Depth
@@ -1343,6 +1357,16 @@ static void hub_activate(struct usb_hubdevice_unlock (&hdev->dev); } +if (type ==HUB_RESUME &&hub_is_superspeed (hub->hdev)) { +/* give usb3 downstream links training time after hub resume */ +INIT_DELAYED_WORK (&hub->init_work, hub_post_resume); +queue_delayed_work (system_power_efficient_wq, &hub->init_work, +msecs_to_jiffies (USB_SS_PORT_U0_WAKE_TIME )); +usb_autopm_get_interface_no_resume ( +to_usb_interface (hub->intfdev)); +return ; + } +hub_put (hub); }
@@ -1361,6 +1385,13 @@ static void hub_init_func3(struct work_shub_activate (hub,HUB_INIT3 ); } +static void hub_post_resume (struct work_struct *ws) +{ + struct usb_hub *hub = container_of(ws, struct usb_hub, init_work.work); + +hub_activate (hub,HUB_POST_RESUME ); +} +enum hub_quiescing_type {HUB_DISCONNECT ,HUB_PRE_RESET ,HUB_SUSPEND };
Greg Kroah-Hartman
maintainerPATCH 168/187 usb: hub: Fix flushing and scheduling of delayed work that tunes runtime pm
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit a49e1e2e785fb3621f2d748581881b23a364998a upstream.
Delayed work to prevent USB3 hubs from runtime-suspending immediately after resume was added in commit 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs").
This delayed work needs be flushed if system suspends, or hub needs to be quiesced for other reasons right after resume. Not flushing it triggered issues on QC SC8280XP CRD board during suspend/resume testing.
Fix it by flushing the delayed resume work in hub_quiesce()
The delayed work item that allow hub runtime suspend is also scheduled just before calling autopm get. Alan pointed out there is a small risk that work is run before autopm get, which would call autopm put before get, and mess up the runtime pm usage order.
Swap the order of work sheduling and calling autopm get to solve this.
--- drivers/usb/core/hub.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/core/hub.c +4 -2
@@ -1359,11 +1359,12 @@ static void hub_activate(struct usb_hubif (type ==HUB_RESUME &&hub_is_superspeed (hub->hdev)) {/* give usb3 downstream links training time after hub resume */ +usb_autopm_get_interface_no_resume ( +to_usb_interface (hub->intfdev)); +INIT_DELAYED_WORK (&hub->init_work, hub_post_resume);queue_delayed_work (system_power_efficient_wq, &hub->init_work,msecs_to_jiffies (USB_SS_PORT_U0_WAKE_TIME )); -usb_autopm_get_interface_no_resume ( -to_usb_interface (hub->intfdev));return ; }
@@ -1417,6 +1418,7 @@ static void hub_quiesce(struct usb_hub */* Stop hub_wq and related activity */ timer_delete_sync (&hub->irq_urb_retry); +flush_delayed_work (&hub->init_work);usb_kill_urb (hub->urb);if (hub->has_indicators)cancel_delayed_work_sync (&hub->leds);
Greg Kroah-Hartman
maintainerPATCH 169/187 usb: hub: Fix flushing of delayed work used for post resume purposes
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 9bd9c8026341f75f25c53104eb7e656e357ca1a2 upstream.
Delayed work that prevents USB3 hubs from runtime-suspending too early needed to be flushed in hub_quiesce() to resolve issues detected on QC SC8280XP CRD board during suspend resume testing.
This flushing did however trigger new issues on Raspberry Pi 3B+, which doesn't have USB3 ports, and doesn't queue any post resume delayed work.
The flushed 'hub->init_work' item is used for several purposes, and is originally initialized with a 'NULL' work function. The work function is also changed on the fly, which may contribute to the issue.
Solve this by creating a dedicated delayed work item for post resume work, and flush that delayed work in hub_quiesce()
--- drivers/usb/core/hub.c | 21 ++++++++------------- drivers/usb/core/hub.h | 1 + 2 files changed, 9 insertions(+), 13 deletions(-)
drivers/usb/core/hub.c +8 -13
@@ -1074,12 +1074,11 @@ int usb_remove_device(struct usb_deviceenum hub_activation_type {HUB_INIT ,HUB_INIT2 ,HUB_INIT3 ,/* INITs must come first */ -HUB_POST_RESET ,HUB_RESUME ,HUB_RESET_RESUME ,HUB_POST_RESUME , +HUB_POST_RESET ,HUB_RESUME ,HUB_RESET_RESUME , };static void hub_init_func2 (struct work_struct *ws);static void hub_init_func3 (struct work_struct *ws); -static void hub_post_resume (struct work_struct *ws);static void hub_activate (struct usb_hub *hub,enum hub_activation_type type) {
@@ -1103,12 +1102,6 @@ static void hub_activate(struct usb_hub goto init3; } -if (type ==HUB_POST_RESUME ) { -usb_autopm_put_interface_async (to_usb_interface (hub->intfdev)); -hub_put (hub); -return ; - } -hub_get (hub);/* The superspeed hub except for root hub has to use Hub Depth
@@ -1362,8 +1355,8 @@ static void hub_activate(struct usb_hubusb_autopm_get_interface_no_resume (to_usb_interface (hub->intfdev)); -INIT_DELAYED_WORK (&hub->init_work, hub_post_resume); -queue_delayed_work (system_power_efficient_wq, &hub->init_work, +queue_delayed_work (system_power_efficient_wq, + &hub->post_resume_work,msecs_to_jiffies (USB_SS_PORT_U0_WAKE_TIME ));return ; }
@@ -1388,9 +1381,10 @@ static void hub_init_func3(struct work_sstatic void hub_post_resume (struct work_struct *ws) { - struct usb_hub *hub = container_of(ws, struct usb_hub, init_work.work); + struct usb_hub *hub = container_of(ws, struct usb_hub, post_resume_work.work); -hub_activate (hub,HUB_POST_RESUME ); +usb_autopm_put_interface_async (to_usb_interface (hub->intfdev)); +hub_put (hub); }enum hub_quiescing_type {
@@ -1418,7 +1412,7 @@ static void hub_quiesce(struct usb_hub */* Stop hub_wq and related activity */ timer_delete_sync (&hub->irq_urb_retry); -flush_delayed_work (&hub->init_work); +flush_delayed_work (&hub->post_resume_work);usb_kill_urb (hub->urb);if (hub->has_indicators)cancel_delayed_work_sync (&hub->leds);
@@ -1977,6 +1971,7 @@ static int hub_probe(struct usb_interfac hub->hdev = hdev;INIT_DELAYED_WORK (&hub->leds, led_work);INIT_DELAYED_WORK (&hub->init_work,NULL ); +INIT_DELAYED_WORK (&hub->post_resume_work, hub_post_resume);INIT_WORK (&hub->events, hub_event);INIT_LIST_HEAD (&hub->onboard_devs);spin_lock_init (&hub->irq_urb_lock);
drivers/usb/core/hub.h +1 -0
@@ -70,6 +70,7 @@ struct usb_hub {u8 indicator[USB_MAXCHILDREN ];struct delayed_work leds;struct delayed_work init_work; +struct delayed_work post_resume_work;struct work_struct events;spinlock_t irq_urb_lock;struct timer_list irq_urb_retry;
Greg Kroah-Hartman
maintainerPATCH 170/187 usb: hub: Dont try to recover devices lost during warm reset.
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 2521106fc732b0b75fd3555c689b1ed1d29d273c upstream.
Hub driver warm-resets ports in SS.Inactive or Compliance mode to recover a possible connected device. The port reset code correctly detects if a connection is lost during reset, but hub driver port_event() fails to take this into account in some cases. port_event() ends up using stale values and assumes there is a connected device, and will try all means to recover it, including power-cycling the port.
Details:
This case was triggered when xHC host was suspended with DbC (Debug Capability) enabled and connected. DbC turns one xHC port into a simple usb debug device, allowing debugging a system with an A-to-A USB debug cable.
xhci DbC code disables DbC when xHC is system suspended to D3, and enables it back during resume.
We essentially end up with two hosts connected to each other during suspend, and, for a short while during resume, until DbC is enabled back. The suspended xHC host notices some activity on the roothub port, but can't train the link due to being suspended, so xHC hardware sets a CAS (Cold Attach Status) flag for this port to inform xhci host driver that the port needs to be warm reset once xHC resumes.
CAS is xHCI specific, and not part of USB specification, so xhci driver tells usb core that the port has a connection and link is in compliance mode. Recovery from complinace mode is similar to CAS recovery.
xhci CAS driver support that fakes a compliance mode connection was added in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
Once xHCI resumes and DbC is enabled back, all activity on the xHC roothub host side port disappears. The hub driver will anyway think port has a connection and link is in compliance mode, and hub driver will try to recover it.
The port power-cycle during recovery seems to cause issues to the active DbC connection.
Fix this by clearing connect_change flag if hub_port_reset() returns -ENOTCONN, thus avoiding the whole unnecessary port recovery and initialization attempt.
--- drivers/usb/core/hub.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/usb/core/hub.c +6 -2
@@ -5747,6 +5747,7 @@ static void port_event(struct usb_hub *hstruct usb_device *hdev = hub->hdev;u16 portstatus, portchange;int i =0 ; +int err; connect_change =test_bit (port1, hub->change_bits);clear_bit (port1, hub->event_bits);
@@ -5843,8 +5844,11 @@ static void port_event(struct usb_hub *h }else if (!udev || !(portstatus &USB_PORT_STAT_CONNECTION ) || udev->state ==USB_STATE_NOTATTACHED ) {dev_dbg (&port_dev->dev,"do warm reset, port only\n" ); -if (hub_port_reset (hub, port1,NULL , -HUB_BH_RESET_TIME , true) <0 ) + err =hub_port_reset (hub, port1,NULL , +HUB_BH_RESET_TIME , true); +if (!udev && err == -ENOTCONN ) + connect_change =0 ; +else if (err <0 )hub_port_disable (hub, port1,1 ); }else {dev_dbg (&port_dev->dev,"do warm reset, full device\n" );
Greg Kroah-Hartman
maintainerPATCH 171/187 usb: dwc3: qcom: Dont leave BCR asserted
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krishna Kurapati <[email protected]>
commit ef8abc0ba49ce717e6bc4124e88e59982671f3b5 upstream.
Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log:
[ 1.332226] usb30_prim_gdsc status stuck at 'off'
Leave the BCR deasserted when exiting the driver to avoid this issue.
--- drivers/usb/dwc3/dwc3-qcom.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/usb/dwc3/dwc3-qcom.c +2 -6
@@ -763,13 +763,13 @@ static int dwc3_qcom_probe(struct platfo ret =reset_control_deassert (qcom->resets);if (ret) {dev_err (&pdev->dev,"failed to deassert resets, err=%d\n" , ret); - goto reset_assert; +return ret; } ret =dwc3_qcom_clk_init (qcom,of_clk_get_parent_count (np));if (ret) {dev_err_probe (dev, ret,"failed to get clocks\n" ); - goto reset_assert; +return ret; } qcom->qscratch_base =devm_platform_ioremap_resource (pdev,0 );
@@ -835,8 +835,6 @@ clk_disable:clk_disable_unprepare (qcom->clks[i]);clk_put (qcom->clks[i]); } -reset_assert: -reset_control_assert (qcom->resets);return ret; }
@@ -857,8 +855,6 @@ static void dwc3_qcom_remove(struct plat qcom->num_clocks =0 ;dwc3_qcom_interconnect_exit (qcom); -reset_control_assert (qcom->resets); -pm_runtime_allow (dev);pm_runtime_disable (dev); }
Greg Kroah-Hartman
maintainerPATCH 172/187 net: libwx: fix multicast packets received count
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiawen Wu <[email protected]>
commit 2b30a3d1ec2538a1fd363fde746b9fe1d38abc77 upstream.
Multicast good packets received by PF rings that pass ethternet MAC address filtering are counted for rtnl_link_stats64.multicast. The counter is not cleared on read. Fix the duplicate counting on updating statistics.
--- drivers/net/ethernet/wangxun/libwx/wx_hw.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/wangxun/libwx/wx_hw.c +2 -0
@@ -2523,6 +2523,8 @@ void wx_update_stats(struct wx *wx) hwstats->fdirmiss +=rd32 (wx,WX_RDB_FDIR_MISS ); } +/* qmprc is not cleared on read, manual reset it */ + hwstats->qmprc =0 ;for (i =0 ; i < wx->mac.max_rx_queues; i++) hwstats->qmprc +=rd32 (wx,WX_PX_MPRC (i)); }
Greg Kroah-Hartman
maintainerPATCH 173/187 rust: use `#[used(compiler)]` to fix build and `modpost` with Rust >= 1.89.0
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miguel Ojeda <[email protected]>
commit 7498159226772d66f150dd406be462d75964a366 upstream.
Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the rusttest target due to undefined references such as:
kernel...-cgu.0:(.text....+0x116): undefined reference to
`rust_helper_kunit_get_current_test'Moreover, tooling like modpost gets confused:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o
ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o
The reason behind both issues is that the Rust compiler will now [1] treat #[used] as #[used(linker)] instead of #[used(compiler)] for our targets. This means that the retain section flag (R, SHF_GNU_RETAIN) will be used and that they will be marked as unique too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in rusttest and that multiple .modinfo sections are generated, which confuse tooling like modpost because they only expect one.
Thus start using #[used(compiler)] to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (used_with_arg) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3].
The changes should also be fine for previous Rust versions, since they behave the same way as before [4].
Alternatively, we could use #[no_mangle] or #[export_name = ...] since those still behave like #[used(compiler)], but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts.
--- rust/Makefile | 1 + rust/kernel/firmware.rs | 2 +- rust/kernel/kunit.rs | 2 +- rust/kernel/lib.rs | 2 ++ rust/macros/module.rs | 10 +++++----- scripts/Makefile.build | 2 +- 6 files changed, 11 insertions(+), 8 deletions(-)
rust/Makefile +1 -0
@@ -194,6 +194,7 @@ quiet_cmd_rustdoc_test = RUSTDOC T $< RUST_MODFILE=test.rs \ OBJTREE=$(abspath $(objtree)) \ $(RUSTDOC) --test $(rust_common_flags) \ + -Zcrate-attr='feature(used_with_arg)' \ @$(objtree)/include/generated/rustc_cfg \ $(rustc_target_flags) $(rustdoc_test_target_flags) \ $(rustdoc_test_quiet) \
rust/kernel/firmware.rs +1 -1
@@ -202,7 +202,7 @@ macro_rules! module_firmware { };#[link_section = ".modinfo" ] -#[used] +#[used(compiler)] static __MODULE_FIRMWARE: [u8; $($builder)*::create(__MODULE_FIRMWARE_PREFIX) .build_length()] = $($builder)*::create(__MODULE_FIRMWARE_PREFIX).build(); };
rust/kernel/kunit.rs +1 -1
@@ -278,7 +278,7 @@ macro_rules! kunit_unsafe_test_suite { is_init: false, }; -#[used] +#[used(compiler)] #[allow(unused_unsafe)] #[cfg_attr(not(target_os = "macos" ), link_section = ".kunit_test_suites" )] static mut KUNIT_TEST_SUITE_ENTRY: *const ::kernel::bindings::kunit_suite =
rust/kernel/lib.rs +2 -0
@@ -26,6 +26,8 @@#![feature(const_mut_refs)] #![feature(const_ptr_write)] #![feature(const_refs_to_cell)] +// To be determined. +#![feature(used_with_arg)] // Ensure conditional compilation based on the kernel configuration works; // otherwise we may silently break things like initcall handling.
rust/macros/module.rs +5 -5
@@ -57,7 +57,7 @@ impl<'a> ModInfoBuilder<'a> { {cfg}#[doc(hidden)] #[cfg_attr(not(target_os = \"macos\"), link_section = \".modinfo\")] - #[used] + #[used(compiler)] pub static __{module}_{counter}: [u8; {length}] = *{string}; ", cfg = if builtin {
@@ -247,7 +247,7 @@ pub(crate) fn module(ts: TokenStream) ->// key or a new section. For the moment, keep it simple. #[cfg( MODULE )] #[doc(hidden)] -#[used] +#[used(compiler)] static __IS_RUST_MODULE: () = (); static mut __MOD: core::mem::MaybeUninit<{type_}> =
@@ -271,7 +271,7 @@ pub(crate) fn module(ts: TokenStream) ->#[cfg( MODULE )] #[doc(hidden)] -#[used] +#[used(compiler)] #[link_section = \".init.data\"] static __UNIQUE_ID___addressable_init_module: unsafe extern \"C\" fn() -> i32 = init_module;
@@ -291,7 +291,7 @@ pub(crate) fn module(ts: TokenStream) ->#[cfg( MODULE )] #[doc(hidden)] -#[used] +#[used(compiler)] #[link_section = \".exit.data\"] static __UNIQUE_ID___addressable_cleanup_module: extern \"C\" fn() = cleanup_module;
@@ -301,7 +301,7 @@ pub(crate) fn module(ts: TokenStream) ->#[cfg(not( CONFIG_HAVE_ARCH_PREL32_RELOCATIONS ))] #[doc(hidden)] #[link_section = \"{initcall_section}\"] - #[used] + #[used(compiler)] pub static __{name}_initcall: extern \"C\" fn() -> kernel::ffi::c_int = __{name}_init; #[cfg(not(MODULE))]
scripts/Makefile.build +1 -1
@@ -222,7 +222,7 @@ $(obj)/%.lst: $(obj)/%.c FORCE # Compile Rust sources (.rs) # --------------------------------------------------------------------------- -rust_allowed_features := asm_const,asm_goto,arbitrary_self_types,lint_reasons,raw_ref_op +rust_allowed_features := asm_const,asm_goto,arbitrary_self_types,lint_reasons,raw_ref_op,used_with_arg # `--out-dir` is required to avoid temporaries being created by `rustc` in the # current working directory, which may be not accessible in the out-of-tree
Greg Kroah-Hartman
maintainerPATCH 174/187 smb: smbdirect: add smbdirect_pdu.h with protocol definitions
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit 00fab6cf323fa5850e6cbe283b23e605e6e97912 upstream.
This is just a start moving into a common smbdirect layer.
It will be used in the next commits...
--- fs/smb/common/smbdirect/smbdirect_pdu.h | 55 ++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 fs/smb/common/smbdirect/smbdirect_pdu.h
fs/smb/common/smbdirect/smbdirect_pdu.h new file +55 -0
@@ -0,0 +1,55 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* +* Copyright (c) 2017 Stefan Metzmacher +*/ + +#ifndef __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_PDU_H__ +#define __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_PDU_H__ + +#define SMBDIRECT_V1 0x0100 + +/* SMBD negotiation request packet [MS-SMBD] 2.2.1 */ +struct smbdirect_negotiate_req { +__le16 min_version; +__le16 max_version; +__le16 reserved; +__le16 credits_requested; +__le32 preferred_send_size; +__le32 max_receive_size; +__le32 max_fragmented_size; +} __packed; + +/* SMBD negotiation response packet [MS-SMBD] 2.2.2 */ +struct smbdirect_negotiate_resp { +__le16 min_version; +__le16 max_version; +__le16 negotiated_version; +__le16 reserved; +__le16 credits_requested; +__le16 credits_granted; +__le32 status; +__le32 max_readwrite_size; +__le32 preferred_send_size; +__le32 max_receive_size; +__le32 max_fragmented_size; +} __packed; + +#define SMBDIRECT_DATA_MIN_HDR_SIZE 0x14 +#define SMBDIRECT_DATA_OFFSET 0x18 + +#define SMBDIRECT_FLAG_RESPONSE_REQUESTED 0x0001 + +/* SMBD data transfer packet with payload [MS-SMBD] 2.2.3 */ +struct smbdirect_data_transfer { +__le16 credits_requested; +__le16 credits_granted; +__le16 flags; +__le16 reserved; +__le32 remaining_data_length; +__le32 data_offset; +__le32 data_length; +__le32 padding; +__u8 buffer[]; +} __packed; + +#endif /* __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_PDU_H__ */
Greg Kroah-Hartman
maintainerPATCH 175/187 smb: client: make use of common smbdirect_pdu.h
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit 64946d5be665ddac6b5bf11f5b5ff319aae0f4c6 upstream.
--- fs/smb/client/smbdirect.c | 40 +++++++++++++++++++--------------------- fs/smb/client/smbdirect.h | 41 ----------------------------------------- 2 files changed, 19 insertions(+), 62 deletions(-)
fs/smb/client/smbdirect.c +19 -21
@@ -7,6 +7,7 @@#include <linux/module.h> #include <linux/highmem.h> #include <linux/folio_queue.h> +#include "../common/smbdirect/smbdirect_pdu.h" #include "smbdirect.h" #include "cifs_debug.h" #include "cifsproto.h"
@@ -50,9 +51,6 @@ struct smb_extract_to_rdma {static ssize_t smb_extract_iter_to_rdma (struct iov_iter *iter,size_t len,struct smb_extract_to_rdma *rdma); -/* SMBD version number */ -#define SMBD_V1 0x0100 -/* Port numbers for SMBD transport */ #define SMB_PORT 445#define SMBD_PORT 5445
@@ -299,7 +297,7 @@ static void send_done(struct ib_cq *cq,mempool_free (request, request->info->request_mempool); } -static void dump_smbd_negotiate_resp (struct smbd_negotiate_resp *resp) +static void dump_smbdirect_negotiate_resp (struct smbdirect_negotiate_resp *resp) { log_rdma_event(INFO, "resp message min_version %u max_version %u negotiated_version %u credits_requested %u credits_granted %u status %u max_readwrite_size %u preferred_send_size %u max_receive_size %u max_fragmented_size %u\n", resp->min_version, resp->max_version,
@@ -318,15 +316,15 @@ static bool process_negotiation_response struct smbd_response *response, int packet_length) {struct smbd_connection *info = response->info; -struct smbd_negotiate_resp *packet =smbd_response_payload (response); +struct smbdirect_negotiate_resp *packet =smbd_response_payload (response); -if (packet_length <sizeof (struct smbd_negotiate_resp )) { +if (packet_length <sizeof (struct smbdirect_negotiate_resp )) {log_rdma_event (ERR ,"error: packet_length=%d\n" , packet_length);return false; } -if (le16_to_cpu (packet->negotiated_version) !=SMBD_V1 ) { +if (le16_to_cpu (packet->negotiated_version) !=SMBDIRECT_V1 ) {log_rdma_event (ERR ,"error: negotiated_version=%x\n" ,le16_to_cpu (packet->negotiated_version));return false;
@@ -448,7 +446,7 @@ static void smbd_post_send_credits(struc/* Called from softirq, when recv is done */ static void recv_done (struct ib_cq *cq,struct ib_wc *wc) { -struct smbd_data_transfer *data_transfer; +struct smbdirect_data_transfer *data_transfer;struct smbd_response *response = container_of(wc->wr_cqe, struct smbd_response, cqe);struct smbd_connection *info = response->info;
@@ -474,7 +472,7 @@ static void recv_done(struct ib_cq *cq,switch (response->type) {/* SMBD negotiation response */ case SMBD_NEGOTIATE_RESP : -dump_smbd_negotiate_resp (smbd_response_payload (response)); +dump_smbdirect_negotiate_resp (smbd_response_payload (response)); info->full_packet_received = true; info->negotiate_done =process_negotiation_response (response, wc->byte_len);
@@ -531,7 +529,7 @@ static void recv_done(struct ib_cq *cq,/* Send a KEEP_ALIVE response right away if requested */ info->keep_alive_requested =KEEP_ALIVE_NONE ;if (le16_to_cpu (data_transfer->flags) & -SMB_DIRECT_RESPONSE_REQUESTED ) { +SMBDIRECT_FLAG_RESPONSE_REQUESTED ) { info->keep_alive_requested =KEEP_ALIVE_PENDING ; }
@@ -686,7 +684,7 @@ static int smbd_post_send_negotiate_req(struct ib_send_wr send_wr;int rc = -ENOMEM ;struct smbd_request *request; -struct smbd_negotiate_req *packet; +struct smbdirect_negotiate_req *packet; request =mempool_alloc (info->request_mempool,GFP_KERNEL );if (!request)
@@ -695,8 +693,8 @@ static int smbd_post_send_negotiate_req( request->info = info; packet =smbd_request_payload (request); - packet->min_version =cpu_to_le16 (SMBD_V1 ); - packet->max_version =cpu_to_le16 (SMBD_V1 ); + packet->min_version =cpu_to_le16 (SMBDIRECT_V1 ); + packet->max_version =cpu_to_le16 (SMBDIRECT_V1 ); packet->reserved =0 ; packet->credits_requested =cpu_to_le16 (info->send_credit_target); packet->preferred_send_size =cpu_to_le32 (info->max_send_size);
@@ -774,10 +772,10 @@ static int manage_credits_prior_sending(/* * Check if we need to send a KEEP_ALIVE message * The idle connection timer triggers a KEEP_ALIVE message when expires -* SMB_DIRECT_RESPONSE_REQUESTED is set in the message flag to have peer send +* SMBDIRECT_FLAG_RESPONSE_REQUESTED is set in the message flag to have peer send * back a response. * return value: -* 1 if SMB_DIRECT_RESPONSE_REQUESTED needs to be set +* 1 if SMBDIRECT_FLAG_RESPONSE_REQUESTED needs to be set * 0: otherwise */ static int manage_keep_alive_before_sending (struct smbd_connection *info)
@@ -837,7 +835,7 @@ static int smbd_post_send_iter(struct smint header_length;int data_length;struct smbd_request *request; -struct smbd_data_transfer *packet; +struct smbdirect_data_transfer *packet;int new_credits =0 ; wait_credit:
@@ -919,7 +917,7 @@ wait_send_queue: packet->flags =0 ;if (manage_keep_alive_before_sending (info)) - packet->flags |=cpu_to_le16 (SMB_DIRECT_RESPONSE_REQUESTED ); + packet->flags |=cpu_to_le16 (SMBDIRECT_FLAG_RESPONSE_REQUESTED ); packet->reserved =0 ;if (!data_length)
@@ -938,10 +936,10 @@ wait_send_queue: le32_to_cpu(packet->remaining_data_length));/* Map the packet to DMA */ - header_length =sizeof (struct smbd_data_transfer ); + header_length =sizeof (struct smbdirect_data_transfer );/* If this is a packet without payload, don't send padding */ if (!data_length) - header_length = offsetof(struct smbd_data_transfer , padding); + header_length = offsetof(struct smbdirect_data_transfer , padding); request->sge[0].addr = ib_dma_map_single(info->id->device, (void *)packet,
@@ -1432,7 +1430,7 @@ static int allocate_caches_and_workqueuekmem_cache_create ( name,sizeof (struct smbd_request ) + -sizeof (struct smbd_data_transfer ), +sizeof (struct smbdirect_data_transfer ),0 ,SLAB_HWCACHE_ALIGN ,NULL );if (!info->request_cache)return -ENOMEM ;
@@ -1735,7 +1733,7 @@ static int smbd_recv_buf(struct smbd_con unsigned int size) {struct smbd_response *response; -struct smbd_data_transfer *data_transfer; +struct smbdirect_data_transfer *data_transfer;int to_copy, to_read, data_read, offset;u32 data_length, remaining_data_length, data_offset;int rc;
fs/smb/client/smbdirect.h +0 -41
47 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 176/187 smb: smbdirect: add smbdirect.h with public structures
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit 7e136a718633b2c54764e185f3bfccf0763fc1dd upstream.
Will be used in client and server in the next commits.
--- fs/smb/common/smbdirect/smbdirect.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 fs/smb/common/smbdirect/smbdirect.h
fs/smb/common/smbdirect/smbdirect.h new file +17 -0
@@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* +* Copyright (C) 2017, Microsoft Corporation. +* Copyright (C) 2018, LG Electronics. +*/ + +#ifndef __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_H__ +#define __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_H__ + +/* SMB-DIRECT buffer descriptor V1 structure [MS-SMBD] 2.2.3.1 */ +struct smbdirect_buffer_descriptor_v1 { +__le64 offset; +__le32 token; +__le32 length; +} __packed; + +#endif /* __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_H__ */
Greg Kroah-Hartman
maintainerPATCH 177/187 smb: smbdirect: add smbdirect_socket.h
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit 22234e37d7e97652cb53133009da5e14793d3c10 upstream.
This abstracts the common smbdirect layer.
Currently with just a few things in it, but that will change over time until everything is in common.
Will be used in client and server in the next commits
--- fs/smb/common/smbdirect/smbdirect_socket.h | 41 +++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 fs/smb/common/smbdirect/smbdirect_socket.h
fs/smb/common/smbdirect/smbdirect_socket.h new file +41 -0
@@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* +* Copyright (c) 2025 Stefan Metzmacher +*/ + +#ifndef __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_SOCKET_H__ +#define __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_SOCKET_H__ + +enum smbdirect_socket_status { +SMBDIRECT_SOCKET_CREATED , +SMBDIRECT_SOCKET_CONNECTING , +SMBDIRECT_SOCKET_CONNECTED , +SMBDIRECT_SOCKET_NEGOTIATE_FAILED , +SMBDIRECT_SOCKET_DISCONNECTING , +SMBDIRECT_SOCKET_DISCONNECTED , +SMBDIRECT_SOCKET_DESTROYED +}; + +struct smbdirect_socket { +enum smbdirect_socket_status status; + +/* RDMA related */ +struct { +struct rdma_cm_id *cm_id; + } rdma; + +/* IB verbs related */ +struct { +struct ib_pd *pd; +struct ib_cq *send_cq; +struct ib_cq *recv_cq; + +/* +* shortcuts for rdma.cm_id->{qp,device}; +*/ +struct ib_qp *qp; +struct ib_device *dev; + } ib; +}; + +#endif /* __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_SOCKET_H__ */
Greg Kroah-Hartman
maintainerPATCH 178/187 smb: client: make use of common smbdirect_socket
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit c3011b9a7deaaaabdf955815d29eac39c8b75e67 upstream.
This is the next step in the direction of a common smbdirect layer. Currently only structures are shared, but that will change over time until everything is shared.
--- fs/smb/client/cifs_debug.c | 2 fs/smb/client/smbdirect.c | 258 ++++++++++++++++++++++++--------------------- fs/smb/client/smbdirect.h | 10 - 3 files changed, 145 insertions(+), 125 deletions(-)
fs/smb/client/cifs_debug.c +1 -1
@@ -387,7 +387,7 @@ static int cifs_debug_data_proc_show(strseq_printf (m,"\nSMBDirect (in hex) protocol version: %x " "transport status: %x" , server->smbd_conn->protocol, - server->smbd_conn->transport_status); + server->smbd_conn->socket.status); seq_printf(m, "\nConn receive_credit_max: %x " "send_credit_target: %x max_send_size: %x", server->smbd_conn->receive_credit_max,
fs/smb/client/smbdirect.c +141 -117
732 lines not on this page · raw message
fs/smb/client/smbdirect.h +3 -7
@@ -15,6 +15,8 @@#include <rdma/rdma_cm.h> #include <linux/mempool.h> +#include "../common/smbdirect/smbdirect_socket.h" +extern int rdma_readwrite_threshold;extern int smbd_max_frmr_depth;extern int smbd_keep_alive_interval;
@@ -50,14 +52,8 @@ enum smbd_connection_status {* 5. mempools for allocating packets */ struct smbd_connection { -enum smbd_connection_status transport_status; +struct smbdirect_socket socket; -/* RDMA related */ -struct rdma_cm_id *id; -struct ib_qp_init_attr qp_attr; -struct ib_pd *pd; -struct ib_cq *send_cq, *recv_cq; -struct ib_device_attr dev_attr;int ri_rc;struct completion ri_done;wait_queue_head_t conn_wait;
Greg Kroah-Hartman
maintainerPATCH 179/187 smb: smbdirect: introduce smbdirect_socket_parameters
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit dce8047f4725d4469c0813ff50c4115fc2d0b628 upstream.
This is the next step in the direction of a common smbdirect layer.
--- fs/smb/client/smbdirect.h | 1 + fs/smb/common/smbdirect/smbdirect.h | 20 ++++++++++++++++++++ fs/smb/common/smbdirect/smbdirect_socket.h | 2 ++ 3 files changed, 23 insertions(+)
fs/smb/client/smbdirect.h +1 -0
@@ -15,6 +15,7 @@#include <rdma/rdma_cm.h> #include <linux/mempool.h> +#include "../common/smbdirect/smbdirect.h" #include "../common/smbdirect/smbdirect_socket.h" extern int rdma_readwrite_threshold;
fs/smb/common/smbdirect/smbdirect.h +20 -0
@@ -14,4 +14,24 @@ struct smbdirect_buffer_descriptor_v1 { __le32 length; } __packed; +/* +* Connection parameters mostly from [MS-SMBD] 3.1.1.1 +* +* These are setup and negotiated at the beginning of a +* connection and remain constant unless explicitly changed. +* +* Some values are important for the upper layer. +*/ +struct smbdirect_socket_parameters { +__u16 recv_credit_max; +__u16 send_credit_target; +__u32 max_send_size; +__u32 max_fragmented_send_size; +__u32 max_recv_size; +__u32 max_fragmented_recv_size; +__u32 max_read_write_size; +__u32 keepalive_interval_msec; +__u32 keepalive_timeout_msec; +} __packed; +#endif /* __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_H__ */
fs/smb/common/smbdirect/smbdirect_socket.h +2 -0
@@ -36,6 +36,8 @@ struct smbdirect_socket {struct ib_qp *qp; struct ib_device *dev; } ib; + +struct smbdirect_socket_parameters parameters; };#endif /* __FS_SMB_COMMON_SMBDIRECT_SMBDIRECT_SOCKET_H__ */
Greg Kroah-Hartman
maintainerPATCH 180/187 smb: client: make use of common smbdirect_socket_parameters
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit cc55f65dd352bdb7bdf8db1c36fb348c294c3b66 upstream.
--- fs/smb/client/cifs_debug.c | 21 ++++++---- fs/smb/client/smb2ops.c | 14 ++++-- fs/smb/client/smbdirect.c | 91 ++++++++++++++++++++++++++------------------- fs/smb/client/smbdirect.h | 10 ---- 4 files changed, 77 insertions(+), 59 deletions(-)
fs/smb/client/cifs_debug.c +13 -8
@@ -362,6 +362,10 @@ static int cifs_debug_data_proc_show(str c =0 ;spin_lock (&cifs_tcp_ses_lock);list_for_each_entry (server, &cifs_tcp_ses_list, tcp_ses_list) { +#ifdef CONFIG_CIFS_SMB_DIRECT +struct smbdirect_socket_parameters *sp; +#endif +/* channel info will be printed as a part of sessions below */ if (SERVER_IS_CHAN (server))continue ;
@@ -383,6 +387,7 @@ static int cifs_debug_data_proc_show(strseq_printf (m,"\nSMBDirect transport not available" ); goto skip_rdma; } + sp = &server->smbd_conn->socket.parameters; seq_printf(m, "\nSMBDirect (in hex) protocol version: %x " "transport status: %x",
@@ -390,18 +395,18 @@ static int cifs_debug_data_proc_show(str server->smbd_conn->socket.status);seq_printf (m,"\nConn receive_credit_max: %x " "send_credit_target: %x max_send_size: %x" , - server->smbd_conn->receive_credit_max, - server->smbd_conn->send_credit_target, - server->smbd_conn->max_send_size); + sp->recv_credit_max, + sp->send_credit_target, + sp->max_send_size);seq_printf (m,"\nConn max_fragmented_recv_size: %x " "max_fragmented_send_size: %x max_receive_size:%x" , - server->smbd_conn->max_fragmented_recv_size, - server->smbd_conn->max_fragmented_send_size, - server->smbd_conn->max_receive_size); + sp->max_fragmented_recv_size, + sp->max_fragmented_send_size, + sp->max_recv_size);seq_printf (m,"\nConn keep_alive_interval: %x " "max_readwrite_size: %x rdma_readwrite_threshold: %x" , - server->smbd_conn->keep_alive_interval, - server->smbd_conn->max_readwrite_size, + sp->keepalive_interval_msec *1000 , + sp->max_read_write_size, server->smbd_conn->rdma_readwrite_threshold); seq_printf(m, "\nDebug count_get_receive_buffer: %x " "count_put_receive_buffer: %x count_send_empty: %x",
fs/smb/client/smb2ops.c +10 -4
@@ -504,6 +504,9 @@ smb3_negotiate_wsize(struct cifs_tcon *t wsize = min_t(unsigned int, wsize, server->max_write);#ifdef CONFIG_CIFS_SMB_DIRECT if (server->rdma) { +struct smbdirect_socket_parameters *sp = + &server->smbd_conn->socket.parameters; +if (server->sign)/* * Account for SMB2 data transfer packet header and
@@ -511,12 +514,12 @@ smb3_negotiate_wsize(struct cifs_tcon *t*/ wsize = min_t(unsigned int, wsize, - server->smbd_conn->max_fragmented_send_size - + sp->max_fragmented_send_size -SMB2_READWRITE_PDU_HEADER_SIZE -sizeof (struct smb2_transform_hdr )); else wsize = min_t(unsigned int, - wsize, server->smbd_conn->max_readwrite_size); + wsize, sp->max_read_write_size); }#endif if (!(server->capabilities &SMB2_GLOBAL_CAP_LARGE_MTU ))
@@ -552,6 +555,9 @@ smb3_negotiate_rsize(struct cifs_tcon *t rsize = min_t(unsigned int, rsize, server->max_read);#ifdef CONFIG_CIFS_SMB_DIRECT if (server->rdma) { +struct smbdirect_socket_parameters *sp = + &server->smbd_conn->socket.parameters; +if (server->sign)/* * Account for SMB2 data transfer packet header and
@@ -559,12 +565,12 @@ smb3_negotiate_rsize(struct cifs_tcon *t*/ rsize = min_t(unsigned int, rsize, - server->smbd_conn->max_fragmented_recv_size - + sp->max_fragmented_recv_size -SMB2_READWRITE_PDU_HEADER_SIZE -sizeof (struct smb2_transform_hdr )); else rsize = min_t(unsigned int, - rsize, server->smbd_conn->max_readwrite_size); + rsize, sp->max_read_write_size); }#endif
fs/smb/client/smbdirect.c +53 -38
304 lines not on this page · raw message
fs/smb/client/smbdirect.h +1 -9
@@ -69,15 +69,7 @@ struct smbd_connection {spinlock_t lock_new_credits_offered;int new_credits_offered; -/* Connection parameters defined in [MS-SMBD] 3.1.1.1 */ -int receive_credit_max; -int send_credit_target; -int max_send_size; -int max_fragmented_recv_size; -int max_fragmented_send_size; -int max_receive_size; -int keep_alive_interval; -int max_readwrite_size; +/* dynamic connection parameters defined in [MS-SMBD] 3.1.1.1 */ enum keep_alive_status keep_alive_requested;int protocol;atomic_t send_credits;
Greg Kroah-Hartman
maintainerPATCH 181/187 cifs: Fix the smbd_response slab to allow usercopy
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit 43e7e284fc77b710d899569360ea46fa3374ae22 upstream.
The handling of received data in the smbdirect client code involves using copy_to_iter() to copy data from the smbd_reponse struct's packet trailer to a folioq buffer provided by netfslib that encapsulates a chunk of pagecache.
If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks then performed in copy_to_iter() oopsing with something like the following:
CIFS: Attempting to mount //172.31.9.1/test
CIFS: VFS: RDMA transport established
usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)!
------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopy_abort+0x6c/0x80 ... Call Trace: <TASK> __check_heap_object+0xe3/0x120 __check_object_size+0x4dc/0x6d0 smbd_recv+0x77f/0xfe0 [cifs] cifs_readv_from_socket+0x276/0x8f0 [cifs] cifs_read_from_socket+0xcd/0x120 [cifs] cifs_demultiplex_thread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 ret_from_fork+0x2b8/0x3b0 ret_from_fork_asm+0x1a/0x30
The problem is that the smbd_response slab's packet field isn't marked as being permitted for usercopy.
Fix this by passing parameters to kmem_slab_create() to indicate that copy_to_iter() is permitted from the packet region of the smbd_response slab objects, less the header space.
--- fs/smb/client/smbdirect.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
fs/smb/client/smbdirect.c +13 -5
@@ -1452,6 +1452,9 @@ static int allocate_caches_and_workqueuechar name[MAX_NAME_LEN ];int rc; +if (WARN_ON_ONCE (sp->max_recv_size <sizeof (struct smbdirect_data_transfer ))) +return -ENOMEM ; +scnprintf (name,MAX_NAME_LEN ,"smbd_request_%p" , info); info->request_cache = kmem_cache_create(
@@ -1469,12 +1472,17 @@ static int allocate_caches_and_workqueue goto out1;scnprintf (name,MAX_NAME_LEN ,"smbd_response_%p" , info); + +struct kmem_cache_args response_args = { + .align = __alignof__(struct smbd_response ), + .useroffset = (offsetof(struct smbd_response , packet) + +sizeof (struct smbdirect_data_transfer )), + .usersize = sp->max_recv_size -sizeof (struct smbdirect_data_transfer ), + }; info->response_cache = -kmem_cache_create ( - name, -sizeof (struct smbd_response ) + - sp->max_recv_size, -0 ,SLAB_HWCACHE_ALIGN ,NULL ); +kmem_cache_create (name, +sizeof (struct smbd_response ) + sp->max_recv_size, + &response_args,SLAB_HWCACHE_ALIGN );if (!info->response_cache) goto out2;
Greg Kroah-Hartman
maintainerPATCH 182/187 cifs: Fix reading into an ITER_FOLIOQ from the smbdirect code
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit 263debecb4aa7cec0a86487e6f409814f6194a21 upstream.
When performing a file read from RDMA, smbd_recv() prints an "Invalid msg type 4" error and fails the I/O. This is due to the switch-statement there not handling the ITER_FOLIOQ handed down from netfslib.
Fix this by collapsing smbd_recv_buf() and smbd_recv_page() into smbd_recv() and just using copy_to_iter() instead of memcpy(). This future-proofs the function too, in case more ITER_* types are added.
--- fs/smb/client/smbdirect.c | 112 ++++++---------------------------------------- 1 file changed, 17 insertions(+), 95 deletions(-)
fs/smb/client/smbdirect.c +17 -95
@@ -1755,35 +1755,39 @@ try_again: }/* -* Receive data from receive reassembly queue +* Receive data from the transport's receive reassembly queue * All the incoming data packets are placed in reassembly queue -* buf: the buffer to read data into +* iter: the buffer to read data into * size: the length of data to read * return value: actual data read -* Note: this implementation copies the data from reassebmly queue to receive +* +* Note: this implementation copies the data from reassembly queue to receive * buffers used by upper layer. This is not the optimal code path. A better way * to do it is to not have upper layer allocate its receive buffers but rather * borrow the buffer from reassembly queue, and return it after data is * consumed. But this will require more changes to upper layer code, and also * need to consider packet boundaries while they still being reassembled. */ -static int smbd_recv_buf (struct smbd_connection *info,char *buf, -unsigned int size) +int smbd_recv (struct smbd_connection *info,struct msghdr *msg) {struct smbdirect_socket *sc = &info->socket;struct smbd_response *response;struct smbdirect_data_transfer *data_transfer; +size_t size =iov_iter_count (&msg->msg_iter);int to_copy, to_read, data_read, offset;u32 data_length, remaining_data_length, data_offset;int rc; +if (WARN_ON_ONCE (iov_iter_rw (&msg->msg_iter) ==WRITE )) +return -EINVAL ;/* It's a bug in upper layer to get there */ + again:/* * No need to hold the reassembly queue lock all the time as we are * the only one reading from the front of the queue. The transport * may add more entries to the back of the queue at the same time */ -log_read (INFO ,"size=%d info->reassembly_data_length=%d\n" , size, +log_read (INFO ,"size=%zd info->reassembly_data_length=%d\n" , size, info->reassembly_data_length);if (info->reassembly_data_length >= size) {int queue_length;
@@ -1821,7 +1825,10 @@ again:if (response->first_segment && size ==4 ) {unsigned int rfc1002_len = data_length + remaining_data_length; - *((__be32 *)buf) =cpu_to_be32 (rfc1002_len); +__be32 rfc1002_hdr =cpu_to_be32 (rfc1002_len); +if (copy_to_iter (&rfc1002_hdr,sizeof (rfc1002_hdr), + &msg->msg_iter) !=sizeof (rfc1002_hdr)) +return -EFAULT ; data_read =4 ; response->first_segment = false; log_read(INFO, "returning rfc1002 length %d\n",
@@ -1830,10 +1837,9 @@ again: } to_copy =min_t (int, data_length - offset, to_read); -memcpy ( - buf + data_read, - (char *)data_transfer + data_offset + offset, - to_copy); +if (copy_to_iter ((char *)data_transfer + data_offset + offset, + to_copy, &msg->msg_iter) != to_copy) +return -EFAULT ;/* move on to the next buffer? */ if (to_copy == data_length - offset) {
@@ -1899,90 +1905,6 @@ read_rfc1002_done: }/* -* Receive a page from receive reassembly queue -* page: the page to read data into -* to_read: the length of data to read -* return value: actual data read -*/ -static int smbd_recv_page (struct smbd_connection *info, -struct page *page,unsigned int page_offset, -unsigned int to_read) -{ -struct smbdirect_socket *sc = &info->socket; -int ret; -char *to_address; -void *page_address; - -/* make sure we have the page ready for read */ - ret =wait_event_interruptible ( - info->wait_reassembly_queue, - info->reassembly_data_length >= to_read || - sc->status !=SMBDIRECT_SOCKET_CONNECTED ); -if (ret) -return ret; - -/* now we can read from reassembly queue and not sleep */ - page_address =kmap_atomic (page); - to_address = (char *) page_address + page_offset; - -log_read (INFO ,"reading from page=%p address=%p to_read=%d\n" , - page, to_address, to_read); - - ret =smbd_recv_buf (info, to_address, to_read); -kunmap_atomic (page_address); - -return ret; -} - -/* -* Receive data from transport -* msg: a msghdr point to the buffer, can be ITER_KVEC or ITER_BVEC -* return: total bytes read, or 0. SMB Direct will not do partial read. -*/ -int smbd_recv (struct smbd_connection *info,struct msghdr *msg) -{ -char *buf; -struct page *page; -unsigned int to_read, page_offset; -int rc; - -if (iov_iter_rw (&msg->msg_iter) ==WRITE ) { -/* It's a bug in upper layer to get there */ -cifs_dbg (VFS ,"Invalid msg iter dir %u\n" , -iov_iter_rw (&msg->msg_iter)); - rc = -EINVAL ; - goto out; - } - -switch (iov_iter_type (&msg->msg_iter)) { -case ITER_KVEC : - buf = msg->msg_iter.kvec->iov_base; - to_read = msg->msg_iter.kvec->iov_len; - rc =smbd_recv_buf (info, buf, to_read); -break ; - -case ITER_BVEC : - page = msg->msg_iter.bvec->bv_page; - page_offset = msg->msg_iter.bvec->bv_offset; - to_read = msg->msg_iter.bvec->bv_len; - rc =smbd_recv_page (info, page, page_offset, to_read); -break ; - -default : -/* It's a bug in upper layer to get there */ -cifs_dbg (VFS ,"Invalid msg type %d\n" , -iov_iter_type (&msg->msg_iter)); - rc = -EINVAL ; - } - -out: -/* SMBDirect will read it all or nothing */ -if (rc >0 ) - msg->msg_iter.count =0 ; -return rc; -} - -/* * Send data to transport * Each rqst is transported as a SMBDirect payload * rqst: the data to write
Greg Kroah-Hartman
maintainerPATCH 183/187 sched,freezer: Remove unnecessary warning in __thaw_task
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Ridong <[email protected]>
commit 9beb8c5e77dc10e3889ff5f967eeffba78617a88 upstream.
Commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") modified the cgroup_freezing() logic to verify that the FROZEN flag is not set, affecting the return value of the freezing() function, in order to address a warning in __thaw_task.
A race condition exists that may allow tasks to escape being frozen. The following scenario demonstrates this issue:
CPU 0 (get_signal path) CPU 1 (freezer.state reader)try_to_freeze read freezer.state__refrigerator freezer_read
update_if_frozen
WRITE_ONCE(current->__state, TASK_FROZEN); ... /* Task is now marked frozen */ /* frozen(task) == true */ /* Assuming other tasks are frozen */ freezer->state |= CGROUP_FROZEN;
/* freezing(current) returns false */
/* because cgroup is frozen (not freezing) */ break out__set_current_state(TASK_RUNNING);
/* Bug: Task resumes running when it should remain frozen */
The existing !frozen(p) check in __thaw_task makes the WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables reverting commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to resolve the issue.
This patch removes the warning from __thaw_task. A subsequent patch will revert commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen") to complete the fix.
--- kernel/freezer.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
kernel/freezer.c +3 -12
@@ -201,18 +201,9 @@ static int __restore_freezer_state(strucvoid __thaw_task (struct task_struct *p) { -unsigned long flags; - -spin_lock_irqsave (&freezer_lock, flags); -if (WARN_ON_ONCE (freezing (p))) - goto unlock; - -if (!frozen (p) ||task_call_func (p, __restore_freezer_state,NULL )) - goto unlock; - -wake_up_state (p,TASK_FROZEN ); -unlock: -spin_unlock_irqrestore (&freezer_lock, flags); +guard (spinlock_irqsave)(&freezer_lock); +if (frozen (p) && !task_call_func (p, __restore_freezer_state,NULL )) +wake_up_state (p,TASK_FROZEN ); }/**
Greg Kroah-Hartman
maintainerPATCH 184/187 sched/ext: Prevent update_locked_rq() calls with NULL rq
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
commit e14fd98c6d66cb76694b12c05768e4f9e8c95664 upstream.
Avoid invoking update_locked_rq() when the runqueue (rq) pointer is NULL in the SCX_CALL_OP and SCX_CALL_OP_RET macros.
Previously, calling update_locked_rq(NULL) with preemption enabled could trigger the following warning:
BUG: using __this_cpu_write() in preemptible [00000000]
This happens because __this_cpu_write() is unsafe to use in preemptible context.
rq is NULL when an ops invoked from an unlocked context. In such cases, we don't need to store any rq, since the value should already be NULL (unlocked). Ensure that update_locked_rq() is only called when rq is non-NULL, preventing calling __this_cpu_write() on preemptible context.
--- kernel/sched/ext.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
kernel/sched/ext.c +8 -4
@@ -1149,7 +1149,8 @@ static inline struct rq *scx_locked_rq(v #define SCX_CALL_OP(mask, op, rq, args...) \ do { \ - update_locked_rq(rq); \ + if (rq) \ + update_locked_rq(rq); \ if (mask) { \ scx_kf_allow(mask); \ scx_ops.op(args); \
@@ -1157,14 +1158,16 @@ do { \ }else { \ scx_ops.op (args); \ } \ -update_locked_rq (NULL ); \ +if (rq) \ +update_locked_rq (NULL ); \ } while (0) #define SCX_CALL_OP_RET(mask, op, rq, args...) \ ({ \ __typeof__(scx_ops.op(args)) __ret; \ \ - update_locked_rq(rq); \ + if (rq) \ + update_locked_rq(rq); \ if (mask) { \ scx_kf_allow(mask); \ __ret = scx_ops.op(args); \
@@ -1172,7 +1175,8 @@ do { \ }else { \ __ret = scx_ops.op (args); \ } \ -update_locked_rq (NULL ); \ +if (rq) \ +update_locked_rq (NULL ); \ __ret; \ })
Greg Kroah-Hartman
maintainerPATCH 185/187 drm/xe/mocs: Initialize MOCS index early
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Balasubramani Vivekanandan <[email protected]>
commit 2a58b21adee3df10ca6f4491af965c4890d2d8e3 upstream.
MOCS uc_index is used even before it is initialized in the following callstack
guc_prepare_xfer()
__xe_guc_upload()
xe_guc_min_load_for_hwconfig()
xe_uc_init_hwconfig()
xe_gt_init_hwconfig()Do MOCS index initialization earlier in the device probe.
Stable-dep-of: 3155ac89251d ("drm/xe: Move page fault init after topology init")
--- drivers/gpu/drm/xe/xe_gt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/xe_gt.c +2 -2
@@ -375,6 +375,8 @@ int xe_gt_init_early(struct xe_gt *gt)if (err)return err; +xe_mocs_init_early (gt); +return 0 ; }
@@ -592,8 +594,6 @@ int xe_gt_init(struct xe_gt *gt)if (err)return err; -xe_mocs_init_early (gt); - err =xe_gt_sysfs_init (gt);if (err)return err;
Greg Kroah-Hartman
maintainerPATCH 186/187 drm/xe: Move page fault init after topology init
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Brost <[email protected]>
commit 3155ac89251dcb5e35a3ec2f60a74a6ed22c56fd upstream.
We need the topology to determine GT page fault queue size, move page fault init after topology init.
--- drivers/gpu/drm/xe/xe_gt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/xe/xe_gt.c +3 -3
@@ -590,15 +590,15 @@ int xe_gt_init(struct xe_gt *gt)if (err)return err; - err =xe_gt_pagefault_init (gt); + err =xe_gt_sysfs_init (gt);if (err)return err; - err =xe_gt_sysfs_init (gt); + err =gt_fw_domain_init (gt);if (err)return err; - err =gt_fw_domain_init (gt); + err =xe_gt_pagefault_init (gt);if (err)return err;
Greg Kroah-Hartman
maintainerPATCH 187/187 smb: client: let smbd_post_send_iter() respect the peers max_send_size and transmit all data
In reply to Greg Kroah-Hartman6.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
commit 1944f6ab4967db7ad8d4db527dceae8c77de76e9 upstream.
We should not send smbdirect_data_transfer messages larger than the negotiated max_send_size, typically 1364 bytes, which means 24 bytes of the smbdirect_data_transfer header + 1340 payload bytes.
This happened when doing an SMB2 write with more than 1340 bytes (which is done inline as it's below rdma_readwrite_threshold).
It means the peer resets the connection.
When testing between cifs.ko and ksmbd.ko something like this is logged:
client:
CIFS: VFS: RDMA transport re-established
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
siw: got TERMINATE. layer 1, type 2, code 2
CIFS: VFS: \\carina Send error in SessSetup = -11
smb2_reconnect: 12 callbacks suppressed
CIFS: VFS: reconnect tcon failed rc = -11
CIFS: VFS: reconnect tcon failed rc = -11
CIFS: VFS: reconnect tcon failed rc = -11
CIFS: VFS: SMB: Zero rsize calculated, using minimum value 65536
and:
CIFS: VFS: RDMA transport re-established
siw: got TERMINATE. layer 1, type 2, code 2
CIFS: VFS: smbd_recv:1894 disconnected
siw: got TERMINATE. layer 1, type 2, code 2
The ksmbd dmesg is showing things like:
smb_direct: Recv error. status='local length error (1)' opcode=128
smb_direct: disconnected
smb_direct: Recv error. status='local length error (1)' opcode=128
ksmbd: smb_direct: disconnected
ksmbd: sock_read failed: -107
As smbd_post_send_iter() limits the transmitted number of bytes we need loop over it in order to transmit the whole iter.
--- fs/smb/client/smbdirect.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-)
fs/smb/client/smbdirect.c +27 -4
@@ -907,8 +907,10 @@ wait_send_queue: .local_dma_lkey = sc->ib.pd->local_dma_lkey, .direction = DMA_TO_DEVICE, }; +size_t payload_len =umin (*_remaining_data_length, + sp->max_send_size -sizeof (*packet)); - rc =smb_extract_iter_to_rdma (iter, *_remaining_data_length, + rc =smb_extract_iter_to_rdma (iter, payload_len, &extract);if (rc <0 ) goto err_dma;
@@ -1013,6 +1015,27 @@ static int smbd_post_send_empty(struct sreturn smbd_post_send_iter (info,NULL , &remaining_data_length); } +static int smbd_post_send_full_iter (struct smbd_connection *info, +struct iov_iter *iter, +int *_remaining_data_length) +{ +int rc =0 ; + +/* +* smbd_post_send_iter() respects the +* negotiated max_send_size, so we need to +* loop until the full iter is posted +*/ + +while (iov_iter_count (iter) >0 ) { + rc =smbd_post_send_iter (info, iter, _remaining_data_length); +if (rc <0 ) +break ; + } + +return rc; +} +/* * Post a receive request to the transport * The remote peer can only send data when a receive request is posted
@@ -1962,14 +1985,14 @@ int smbd_send(struct TCP_Server_Info *se klen += rqst->rq_iov[i].iov_len;iov_iter_kvec (&iter,ITER_SOURCE , rqst->rq_iov, rqst->rq_nvec, klen); - rc =smbd_post_send_iter (info, &iter, &remaining_data_length); + rc =smbd_post_send_full_iter (info, &iter, &remaining_data_length);if (rc <0 )break ;if (iov_iter_count (&rqst->rq_iter) >0 ) {/* And then the data pages if there are any */ - rc =smbd_post_send_iter (info, &rqst->rq_iter, - &remaining_data_length); + rc =smbd_post_send_full_iter (info, &rqst->rq_iter, + &remaining_data_length);if (rc <0 )break ; }
# Librecast Test Results
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.15.8-rc1-g81bcc8b99854 #30 SMP PREEMPT_DYNAMIC Tue Jul 22 15:58:43 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Hi
no regressions here on x86_64 (RKL, Intel 11th Gen. CPU)
Thanks
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.thanks,
greg k-h
Regressions while building allyesconfig build for arm64 and x86 with the toolchain clang-nightly version 22.0.0.
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Build regression: arm64 x86 mm ksm.c error variable 'output' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
Build regression: arm64 x86 samsung s5p_mfc_cmd_v6.c error variable 'h2r_args' is uninitialized when passed as a const pointer argument here
Build regression: arm64 x86 mediatek mcu.c error variable 'hdr' is uninitialized when passed as a const pointer argument here Build regression: arm64 x86 broadcom phy_lcn.c error variable 'diq_start' is uninitialized when passed as a const pointer argument here
Build regression: arm64 x86 usb cxacru.c error variable 'bp' is used uninitialized whenever 'if' condition is false
Build regression: arm64 x86 drm dpu_plane.c error variable 'crtc_state' is used uninitialized whenever 'if' condition is false Build regression: arm64 x86 drm amdgpu imu_v12_0.c error variable 'data' is uninitialized when used here
## Build logmm/ksm.c:3674:11: error: variable 'output' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
3674 | else if (ksm_advisor == KSM_ADVISOR_SCAN_TIME)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:45:7: error:
variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
45 | &h2r_args);
| ^~~~~~~~
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:133:7: error:
variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
133 | &h2r_args);
| ^~~~~~~~
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:148:7: error:
variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
148 | &h2r_args);
| ^~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:3365:21: error:
variable 'hdr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
3365 | skb_put_data(skb, &hdr, sizeof(hdr));
| ^~~
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:1875:21: error:
variable 'hdr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
1875 | skb_put_data(skb, &hdr, sizeof(hdr));
| ^~~
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:2728:13:
error: variable 'diq_start' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
2728 |&diq_start, 1, 16, 69);
| ^~~~~~~~~
drivers/usb/atm/cxacru.c:1104:6: error: variable 'bp' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
1104 | if (instance->modem_type->boot_rom_patch) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1066:6: error: variable 'crtc_state' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
1066 | if (plane_state->crtc)
| ^~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/imu_v12_0.c:374:30: error: variable 'data' is uninitialized when used here [-Werror,-Wuninitialized]
374 | program_imu_rlc_ram(adev, data, (const
u32)size);
| ^~~~
## Source
* Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* Git sha: 81bcc8b99854ba689a8c85fb1d39d5acdce0385a
* Git describe: v6.15.7-188-g81bcc8b99854
* Architectures: arm64 x86
* Toolchains: Debian clang version 22.0.0 (++20250721112855+43a829a7e894-1~exp1~20250721112913.1588)
* Kconfigs: allyesconfig
## Build
* Build log: https://regressions.linaro.org/lkft/linux-stable-rc-linux-6.15.y/v6.15.7-188-g81bcc8b99854/build/clang-nightly-allyesconfig/
* Build run: https://regressions.linaro.org/lkft/linux-stable-rc-linux-6.15.y/v6.15.7-188-g81bcc8b99854/testruns/1699830/
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/30EaSfe4S6Pi4zE2kv1TGQcGByr/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/30EaSfe4S6Pi4zE2kv1TGQcGByr/config
## Steps to reproduce
* tuxmake --runtime podman --target-arch arm64 --toolchain clang-nightly --kconfig allyesconfig LLVM=1 LLVM_IAS=1
--
Linaro LKFT
https://lkft.linaro.org
Quoted 2 lines · Naresh Kamboju
Regressions while building allyesconfig build for arm64 and x86 with the toolchain clang-nightly version 22.0.0.
This is a "regression" in the sense that the warnings are new but it is from the toolchain side, not the kernel side.
Quoted 5 lines
## Build log
mm/ksm.c:3674:11: error: variable 'output' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
3674 | else if (ksm_advisor==KSM_ADVISOR_SCAN_TIME)| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix pending in Andrew's tree:
https://git.kernel.org/akpm/mm/c/153ad566724fe6f57b14f66e9726d295d22e576d
Quoted 12 lines
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:45:7: error:
variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
45 |&h2r_args);
| ^~~~~~~~
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:133:7: error:
variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
133 |&h2r_args);
| ^~~~~~~~
Quoted 5 lines
drivers/media/platform/samsung/s5p-mfc/s5p_mfc_cmd_v6.c:148:7: error:
variable 'h2r_args' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
148 |&h2r_args);
| ^~~~~~~~
Quoted 11 lines
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:3365:21: error:
variable 'hdr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
3365 |skb_put_data(skb, &hdr, sizeof(hdr));
| ^~~
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c:1875:21: error:
variable 'hdr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
1875 |skb_put_data(skb, &hdr, sizeof(hdr));
| ^~~
https://lore.kernel.org/all/20250715-mt7996-fix-uninit-const-pointer-v1-1-b5d8d11d7b78@kernel.org/
Quoted 6 lines
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:2728:13:
error: variable 'diq_start' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer]
2728 |&diq_start, 1, 16, 69);
| ^~~~~~~~~
Pending in the wireless tree:
https://git.kernel.org/wireless/wireless-next/c/81284e86bf8849f8e98e8ead3ff5811926b2107f
Quoted 5 lines
drivers/usb/atm/cxacru.c:1104:6: error: variable 'bp' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]1104 | if (instance->modem_type->boot_rom_patch) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I need to send a v2 for this based on Greg's feedback:
https://lore.kernel.org/all/20250716172903.GA4010969@ax162/
Quoted 5 lines
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1066:6: error: variable 'crtc_state' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
1066 | if (plane_state->crtc)| ^~~~~~~~~~~~~~~~~
https://lore.kernel.org/all/20250715-drm-msm-fix-const-uninit-warning-v1-1-d6a366fd9a32@kernel.org/
Quoted 5 lines
drivers/gpu/drm/amd/amdgpu/imu_v12_0.c:374:30: error: variable 'data' is uninitialized when used here [-Werror,-Wuninitialized]
374 | program_imu_rlc_ram(adev, data, (const
u32)size);
| ^~~~
Alex said he picked it up but I have not seen it appear in his tree yet:
Cheers,
Nathan
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.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 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
Tested on a ThinkPad E14 Gen 3 with a AMD Ryzen 5 5500U CPU and a Framework Desktop.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · On Tue, 22 Jul 2025 15:42:50 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +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:
Thanks!
Cheers,
Miguel
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.thanks,
greg k-h
6.15.8-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 6.15.8-rc1rv-g81bcc8b99854
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.1.1 20250425, GNU ld (GNU Binutils) 2.44.0) #1 SMP PREEMPT_DYNAMIC Wed Jul 23 11:14:10 JST 2025
Thanks
[2025-07-22 15:42] Greg Kroah-Hartman:
Quoted 5 lines
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 8 lines
Responses should be made by Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.
Compiles fine for x86_64 with GCC 15.1.1, and runs fine on various physical Intel machines (Ivy Bridge, Haswell, Kaby Lake, Coffee Lake) and in a Skylake VM.
Regards
Pascal
Am 22.07.2025 um 15:42 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.15.8 release. There are 187 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.15.8-rc1-g81bcc8b99854
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
The kernel, bpf tool, and perf tool builds fine for v6.15.8-rc1 on x86 and arm64 Azure VM.
Thanks,
Hardik
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.15.8 release. There are 187 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 Thu, 24 Jul 2025 13:43:10 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.15.8-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 81bcc8b99854ba689a8c85fb1d39d5acdce0385a
* git describe: v6.15.7-188-g81bcc8b99854
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.15.y/build/v6.15.7-188-g81bcc8b99854
## Test Regressions (compared to v6.15.6-193-ge6001d5f7944)
## Metric Regressions (compared to v6.15.6-193-ge6001d5f7944)
## Test Fixes (compared to v6.15.6-193-ge6001d5f7944)
## Metric Fixes (compared to v6.15.6-193-ge6001d5f7944)
## Test result summary
total: 329387, pass: 302234, fail: 7786, skip: 19367, xfail: 0
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 138 passed, 1 failed
* arm64: 57 total, 56 passed, 1 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 27 passed, 7 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 39 passed, 1 failed
* riscv: 25 total, 25 passed, 0 failed
* s390: 22 total, 22 passed, 0 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 47 passed, 2 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-rust
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* modules
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.15.8 release. There are 187 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.15.y
6.6 passes our testing, too.
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany