6.17.8-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 815/849 smb: client: validate change notify buffer before copy
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joshua Rogers <[email protected]>
commit 4012abe8a78fbb8869634130024266eaef7081fe upstream.
SMB2_change_notify called smb2_validate_iov() but ignored the return code, then kmemdup()ed using server provided OutputBufferOffset/Length.
Check the return of smb2_validate_iov() and bail out on error.
Discovered with help from the ZeroPath security tooling.
--- fs/smb/client/smb2pdu.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
fs/smb/client/smb2pdu.c +5 -2
@@ -4054,9 +4054,12 @@ replay_again: smb_rsp = (struct smb2_change_notify_rsp *)rsp_iov.iov_base; -smb2_validate_iov (le16_to_cpu (smb_rsp->OutputBufferOffset), -le32_to_cpu (smb_rsp->OutputBufferLength), &rsp_iov, + rc =smb2_validate_iov (le16_to_cpu (smb_rsp->OutputBufferOffset), +le32_to_cpu (smb_rsp->OutputBufferLength), + &rsp_iov,sizeof (struct file_notify_information )); +if (rc) + goto cnotify_exit; *out_data =kmemdup ((char *)smb_rsp +le16_to_cpu (smb_rsp->OutputBufferOffset),le32_to_cpu (smb_rsp->OutputBufferLength),GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 816/849 io_uring: fix regbuf vector size truncation
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
commit 146eb58629f45f8297e83d69e64d4eea4b28d972 upstream.
There is a report of io_estimate_bvec_size() truncating the calculated number of segments that leads to corruption issues. Check it doesn't overflow "int"s used later. Rough but simple, can be improved on top.
--- io_uring/rsrc.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
io_uring/rsrc.c +9 -2
@@ -1402,8 +1402,11 @@ static int io_estimate_bvec_size(structsize_t max_segs =0 ;unsigned i; -for (i =0 ; i < nr_iovs; i++) +for (i =0 ; i < nr_iovs; i++) { max_segs += (iov[i].iov_len >> shift) +2 ; +if (max_segs >INT_MAX ) +return -EOVERFLOW ; + }return max_segs; }
@@ -1509,7 +1512,11 @@ int io_import_reg_vec(int ddir, struct iif (unlikely (ret))return ret; }else { - nr_segs =io_estimate_bvec_size (iov, nr_iovs, imu); +int ret =io_estimate_bvec_size (iov, nr_iovs, imu); + +if (ret <0 ) +return ret; + nr_segs = ret; }if (sizeof (struct bio_vec ) >sizeof (struct iovec )) {
Greg Kroah-Hartman
maintainerPATCH 817/849 smb: client: fix potential UAF in smb2_close_cached_fid()
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henrique Carvalho <[email protected]>
commit 734e99623c5b65bf2c03e35978a0b980ebc3c2f8 upstream.
find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.
Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.
--- fs/smb/client/cached_dir.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
fs/smb/client/cached_dir.c +9 -7
@@ -389,11 +389,11 @@ out:* lease. Release one here, and the second below. */ cfid->has_lease = false; -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }spin_unlock (&cfids->cfid_list_lock); -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }else { *ret_cfid = cfid;atomic_inc (&tcon->num_remote_opens);
@@ -434,12 +434,14 @@ int open_cached_dir_by_dentry(struct cifstatic void smb2_close_cached_fid (struct kref *ref) +__releases(&cfid->cfids->cfid_list_lock) { struct cached_fid *cfid = container_of(ref, struct cached_fid, refcount);int rc; -spin_lock (&cfid->cfids->cfid_list_lock); +lockdep_assert_held (&cfid->cfids->cfid_list_lock); +if (cfid->on_list) {list_del (&cfid->entry); cfid->on_list = false;
@@ -474,7 +476,7 @@ void drop_cached_dir_by_name(const unsigspin_lock (&cfid->cfids->cfid_list_lock);if (cfid->has_lease) { cfid->has_lease = false; -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }spin_unlock (&cfid->cfids->cfid_list_lock);close_cached_dir (cfid);
@@ -483,7 +485,7 @@ void drop_cached_dir_by_name(const unsigvoid close_cached_dir (struct cached_fid *cfid) { -kref_put (&cfid->refcount, smb2_close_cached_fid); +kref_put_lock (&cfid->refcount, smb2_close_cached_fid, &cfid->cfids->cfid_list_lock); }/*
@@ -594,7 +596,7 @@ cached_dir_offload_close(struct work_strWARN_ON (cfid->on_list); -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid);cifs_put_tcon (tcon, netfs_trace_tcon_ref_put_cached_close); }
@@ -771,7 +773,7 @@ static void cfids_laundromat_worker(stru* Drop the ref-count from above, either the lease-ref (if there * was one) or the extra one acquired. */ -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }queue_delayed_work (cfid_put_wq, &cfids->laundromat_work, dir_cache_timeout *HZ );
Re: [PATCH 6.17 817/849] smb: client: fix potential UAF in smb2_close_cached_fid()
Quoted 45 lines · Greg Kroah-Hartman
6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henrique Carvalho <[email protected]>
commit
734e99623c5b65bf2c03e35978a0b980ebc3c2f8upstream.
find_or_create_cached_dir()could grab a new reference afterkref_put()had seen the refcount drop to zero but beforecfid_list_lockis acquired insmb2_close_cached_fid(), leading to use-after-free.Switch to
kref_put_lock()socfid_release()is called withcfid_list_lockheld, closing that gap.Fixes ebe98f1447bb ("cifs: enable caching of directories for which a lease is held")Reported-by Jay Shin <[email protected]>Reviewed-by Paulo Alcantara (Red Hat) <[email protected]>Signed-off-by Henrique Carvalho <[email protected]>Signed-off-by Steve French <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- fs/smb/client/cached_dir.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)fs/smb/client/cached_dir.c +2
-2@@ -389,11 +389,11 @@ out:* lease. Release one here, and the second below. */ cfid->has_lease = false; -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }spin_unlock (&cfids->cfid_list_lock); -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }else { *ret_cfid = cfid;atomic_inc (&tcon->num_remote_opens);@@ -434,12 +434,14 @@ int open_cached_dir_by_dentry(struct cif static void
fs/smb/client/cached_dir.c int open_cached_dir_by_dentry(struct cif · line 444
Quoted 10 lines
fs/smb/client/cached_dir.c +3
-1smb2_close_cached_fid(struct kref *ref) +__releases(&cfid->cfids->cfid_list_lock) { struct cached_fid *cfid = container_of(ref, struct cached_fid, refcount);int rc; -spin_lock (&cfid->cfids->cfid_list_lock); +lockdep_assert_held (&cfid->cfids->cfid_list_lock); +
This _backport_ (of a 6.18-rc5 commit) omits to change cfids_invalidation_worker() which was removed in 6.18-rc1 by:7ae6152b7831 smb: client: remove cfids_invalidation_worker
This likely causes:
https://bugzilla.suse.com/show_bug.cgi?id=1254096
BUG: workqueue leaked atomic, lock or RCU
Because cfids_invalidation_worker() still does:
kref_put(&cfid->refcount, smb2_close_cached_fid);
instead of now required kref_put_lock() aka:
close_cached_dir(cfid);thanks,
Signature · 2 lines
js suse labs
Henrique Carvalho
Reviewed-by Paulo Alcantara (Red Hat)Re: [PATCH 6.17 817/849] smb: client: fix potential UAF in smb2_close_cached_fid()
Quoted 9 lines · Jiri Slaby
Quoted 8 lines · Greg Kroah-Hartman
6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henrique Carvalho <[email protected]>
commit
734e99623c5b65bf2c03e35978a0b980ebc3c2f8upstream.
...
Quoted 7 lines
This _backport_ (of a 6.18-rc5 commit) omits to change
cfids_invalidation_worker()which was removed in 6.18-rc1 by:7ae6152b7831smb: client: removecfids_invalidation_workerThis likely causes:
https://bugzilla.suse.com/show_bug.cgi?id=1254096
Quoted 8 lines
BUG: workqueue leaked atomic, lock or RCUBecause
cfids_invalidation_worker()still does:kref_put(&cfid->refcount, smb2_close_cached_fid); instead of now required kref_put_lock() aka: close_cached_dir(cfid);thanks,
Thanks, Jiri.
I'm sending the updated patch attached.
This new version should also replace the patch backported to stable versions:
- 6.12.y (065bd62412271a2d734810dd50336cae88c54427)
- 6.6.y (cb52d9c86d70298de0ab7c7953653898cbc0efd6)
Alternatively, I'm sending just the fix ("smb: client: fix incomplete backport in cfids_invalidation_worker()").
Signature · 2 lines
Henrique SUSE Labs
From d5d33a751e9d099d46f48dba40b8b77ec6c0407a Mon Sep 17 00:00:00 2001
From: Henrique Carvalho <[email protected]>
Date: Mon, 3 Nov 2025 19:52:55 -0300
Subject: [PATCH] smb: client: fix potential UAF in smb2_close_cached_fid()
commit 734e99623c5b65bf2c03e35978a0b980ebc3c2f8 upstream.
find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.
Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.
--- fs/smb/client/cached_dir.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
fs/smb/client/cached_dir.c +10 -8
@@ -389,11 +389,11 @@ int open_cached_dir(unsigned int xid, struct cifs_tcon *tcon,* lease. Release one here, and the second below. */ cfid->has_lease = false; -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }spin_unlock (&cfids->cfid_list_lock); -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }else { *ret_cfid = cfid;atomic_inc (&tcon->num_remote_opens);
@@ -434,12 +434,14 @@ int open_cached_dir_by_dentry(struct cifs_tcon *tcon,static void smb2_close_cached_fid (struct kref *ref) +__releases(&cfid->cfids->cfid_list_lock) { struct cached_fid *cfid = container_of(ref, struct cached_fid, refcount);int rc; -spin_lock (&cfid->cfids->cfid_list_lock); +lockdep_assert_held (&cfid->cfids->cfid_list_lock); +if (cfid->on_list) {list_del (&cfid->entry); cfid->on_list = false;
@@ -474,7 +476,7 @@ void drop_cached_dir_by_name(const unsigned int xid, struct cifs_tcon *tcon,spin_lock (&cfid->cfids->cfid_list_lock);if (cfid->has_lease) { cfid->has_lease = false; -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }spin_unlock (&cfid->cfids->cfid_list_lock);close_cached_dir (cfid);
@@ -483,7 +485,7 @@ void drop_cached_dir_by_name(const unsigned int xid, struct cifs_tcon *tcon,void close_cached_dir (struct cached_fid *cfid) { -kref_put (&cfid->refcount, smb2_close_cached_fid); +kref_put_lock (&cfid->refcount, smb2_close_cached_fid, &cfid->cfids->cfid_list_lock); }/*
@@ -594,7 +596,7 @@ cached_dir_offload_close(struct work_struct *work)WARN_ON (cfid->on_list); -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid);cifs_put_tcon (tcon, netfs_trace_tcon_ref_put_cached_close); }
@@ -718,7 +720,7 @@ static void cfids_invalidation_worker(struct work_struct *work)list_for_each_entry_safe (cfid, q, &entry, entry) {list_del (&cfid->entry);/* Drop the ref-count acquired in invalidate_all_cached_dirs */ -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); } }
@@ -771,7 +773,7 @@ static void cfids_laundromat_worker(struct work_struct *work)* Drop the ref-count from above, either the lease-ref (if there * was one) or the extra one acquired. */ -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); }queue_delayed_work (cfid_put_wq, &cfids->laundromat_work, dir_cache_timeout *HZ );
Signature · 1 line
2.50.1
From 38ef85145fd3655cd4ac16578871afdc0aa6636f Mon Sep 17 00:00:00 2001
From: Henrique Carvalho <[email protected]>
Date: Wed, 26 Nov 2025 10:55:53 -0300
Subject: [PATCH] smb: client: fix incomplete backport in
cfids_invalidation_worker()
The previous commit bdb596ceb4b7 ("smb: client: fix potential UAF in smb2_close_cached_fid()") was an incomplete backport and missed one kref_put() call in cfids_invalidation_worker() that should have been converted to close_cached_dir().
--- fs/smb/client/cached_dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/smb/client/cached_dir.c +1 -1
@@ -720,7 +720,7 @@ static void cfids_invalidation_worker(struct work_struct *work)list_for_each_entry_safe (cfid, q, &entry, entry) {list_del (&cfid->entry);/* Drop the ref-count acquired in invalidate_all_cached_dirs */ -kref_put (&cfid->refcount, smb2_close_cached_fid); +close_cached_dir (cfid); } }
Signature · 1 line
2.50.1
Greg Kroah-Hartman
maintainerRe: [PATCH 6.17 817/849] smb: client: fix potential UAF in smb2_close_cached_fid()
Quoted 33 lines · Henrique Carvalho
Quoted 9 lines · Jiri Slaby
Quoted 8 lines · Greg Kroah-Hartman
6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henrique Carvalho <[email protected]>
commit
734e99623c5b65bf2c03e35978a0b980ebc3c2f8upstream....
Quoted 7 lines
This _backport_ (of a 6.18-rc5 commit) omits to change
cfids_invalidation_worker()which was removed in 6.18-rc1 by:7ae6152b7831smb: client: removecfids_invalidation_workerThis likely causes:
https://bugzilla.suse.com/show_bug.cgi?id=1254096Quoted 8 lines
BUG: workqueue leaked atomic, lock or RCUBecause
cfids_invalidation_worker()still does:kref_put(&cfid->refcount, smb2_close_cached_fid); instead of now required kref_put_lock() aka: close_cached_dir(cfid);thanks,
Thanks, Jiri.
I'm sending the updated patch attached.
Quoted 8 lines
This new version should also replace the patch backported to stable versions:
- 6.12.y (
065bd62412271a2d734810dd50336cae88c54427)
- 6.6.y (cb52d9c86d70298de0ab7c7953653898cbc0efd6)Alternatively, I'm sending just the fix ("smb: client: fix incomplete backport in
cfids_invalidation_worker()").
Thanks, I've taken the "fixup" now.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 818/849 perf/core: Fix system hang caused by cpu-clock usage
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dapeng Mi <[email protected]>
commit eb3182ef0405ff2f6668fd3e5ff9883f60ce8801 upstream.
cpu-clock usage by the async-profiler tool can trigger a system hang, which got bisected back to the following commit by Octavia Togami:
18dbcbfabfff ("perf: Fix the POLL_HUP delivery breakage") causes this issue
The root cause of the hang is that cpu-clock is a special type of SW event which relies on hrtimers. The __perf_event_overflow() callback is invoked from the hrtimer handler for cpu-clock events, and __perf_event_overflow() tries to call cpu_clock_event_stop() to stop the event, which calls htimer_cancel() to cancel the hrtimer.
But that's a recursion into the hrtimer code from a hrtimer handler, which (unsurprisingly) deadlocks.
To fix this bug, use hrtimer_try_to_cancel() instead, and set the PERF_HES_STOPPED flag, which causes perf_swevent_hrtimer() to stop the event once it sees the PERF_HES_STOPPED flag.
[ mingo: Fixed the comments and improved the changelog. ]
--- kernel/events/core.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
kernel/events/core.c +15 -5
@@ -11757,7 +11757,8 @@ static enum hrtimer_restart perf_swevent event = container_of(hrtimer, struct perf_event, hw.hrtimer); -if (event->state !=PERF_EVENT_STATE_ACTIVE ) +if (event->state !=PERF_EVENT_STATE_ACTIVE || + event->hw.state &PERF_HES_STOPPED )return HRTIMER_NORESTART ; event->pmu->read (event);
@@ -11803,15 +11804,20 @@ static void perf_swevent_cancel_hrtimer(struct hw_perf_event *hwc = &event->hw;/* -* The throttle can be triggered in the hrtimer handler. -* The HRTIMER_NORESTART should be used to stop the timer, -* rather than hrtimer_cancel(). See perf_swevent_hrtimer() +* Careful: this function can be triggered in the hrtimer handler, +* for cpu-clock events, so hrtimer_cancel() would cause a +* deadlock. +* +* So use hrtimer_try_to_cancel() to try to stop the hrtimer, +* and the cpu-clock handler also sets the PERF_HES_STOPPED flag, +* which guarantees that perf_swevent_hrtimer() will stop the +* hrtimer once it sees the PERF_HES_STOPPED flag. */ if (is_sampling_event (event) && (hwc->interrupts !=MAX_INTERRUPTS )) {ktime_t remaining =hrtimer_get_remaining (&hwc->hrtimer);local64_set (&hwc->period_left,ktime_to_ns (remaining)); -hrtimer_cancel (&hwc->hrtimer); +hrtimer_try_to_cancel (&hwc->hrtimer); } }
@@ -11855,12 +11861,14 @@ static void cpu_clock_event_update(strucstatic void cpu_clock_event_start (struct perf_event *event,int flags) { + event->hw.state =0 ;local64_set (&event->hw.prev_count,local_clock ());perf_swevent_start_hrtimer (event); }static void cpu_clock_event_stop (struct perf_event *event,int flags) { + event->hw.state =PERF_HES_STOPPED ;perf_swevent_cancel_hrtimer (event);if (flags &PERF_EF_UPDATE )cpu_clock_event_update (event);
@@ -11934,12 +11942,14 @@ static void task_clock_event_update(strustatic void task_clock_event_start (struct perf_event *event,int flags) { + event->hw.state =0 ;local64_set (&event->hw.prev_count, event->ctx->time);perf_swevent_start_hrtimer (event); }static void task_clock_event_stop (struct perf_event *event,int flags) { + event->hw.state =PERF_HES_STOPPED ;perf_swevent_cancel_hrtimer (event);if (flags &PERF_EF_UPDATE )task_clock_event_update (event, event->ctx->time);
Greg Kroah-Hartman
maintainerPATCH 819/849 x86/amd_node: Fix AMD root device caching
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <[email protected]>
commit 0a4b61d9c2e496b5f0a10e29e355a1465c8738bb upstream.
Recent AMD node rework removed the "search and count" method of caching AMD root devices. This depended on the value from a Data Fabric register that was expected to hold the PCI bus of one of the root devices attached to that fabric.
However, this expectation is incorrect. The register, when read from PCI config space, returns the bitwise-OR of the buses of all attached root devices.
This behavior is benign on AMD reference design boards, since the bus numbers are aligned. This results in a bitwise-OR value matching one of the buses. For example, 0x00 | 0x40 | 0xA0 | 0xE0 = 0xE0.
This behavior breaks on boards where the bus numbers are not exactly aligned. For example, 0x00 | 0x07 | 0xE0 | 0x15 = 0x1F.
The examples above are for AMD node 0. The first root device on other nodes will not be 0x00. The first root device for other nodes will depend on the total number of root devices, the system topology, and the specific PCI bus number assignment.
For example, a system with 2 AMD nodes could have this:
Node 0 : 0x00 0x07 0x0e 0x15
Node 1 : 0x1c 0x23 0x2a 0x31
The bus numbering style in the reference boards is not a requirement. The numbering found in other boards is not incorrect. Therefore, the root device caching method needs to be adjusted.
Go back to the "search and count" method used before the recent rework. Search for root devices using PCI class code rather than fixed PCI IDs.
This keeps the goal of the rework (remove dependency on PCI IDs) while being able to support various board designs.
Merge helper functions to reduce code duplication.
[ bp: Reflow comment. ]
--- arch/x86/include/asm/amd/node.h | 1 arch/x86/kernel/amd_node.c | 150 +++++++++++++--------------------------- 2 files changed, 51 insertions(+), 100 deletions(-)
arch/x86/include/asm/amd/node.h +0 -1
@@ -23,7 +23,6 @@#define AMD_NODE0_PCI_SLOT 0x18struct pci_dev *amd_node_get_func (u16 node,u8 func); -struct pci_dev *amd_node_get_root (u16 node);static inline u16 amd_num_nodes (void ) {
arch/x86/kernel/amd_node.c +51 -99
190 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 820/849 xfs: fix delalloc write failures in software-provided atomic writes
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Darrick J. Wong <[email protected]>
commit 8d54eacd82a0623a963e0c150ad3b02970638b0d upstream.
With the 20 Oct 2025 release of fstests, generic/521 fails for me on regular (aka non-block-atomic-writes) storage:
QA output created by 521
dowrite: write: Input/output error
LOG DUMP (8553 total operations):
1( 1 mod 256): SKIPPED (no operation) 2( 2 mod 256): WRITE 0x7e000 thru 0x8dfff (0x10000 bytes) HOLE 3( 3 mod 256): READ 0x69000 thru 0x79fff (0x11000 bytes) 4( 4 mod 256): FALLOC 0x53c38 thru 0x5e853 (0xac1b bytes) INTERIOR 5( 5 mod 256): COPY 0x55000 thru 0x59fff (0x5000 bytes) to 0x25000 thru 0x29fff 6( 6 mod 256): WRITE 0x74000 thru 0x88fff (0x15000 bytes) 7( 7 mod 256): ZERO 0xedb1 thru 0x11693 (0x28e3 bytes)
with a warning in dmesg from iomap about XFS trying to give it a delalloc mapping for a directio write. Fix the software atomic write iomap_begin code to convert the reservation into a written mapping. This doesn't fix the data corruption problems reported by generic/760, but it's a start.
--- fs/xfs/xfs_iomap.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-)
fs/xfs/xfs_iomap.c +19 -2
@@ -1121,7 +1121,7 @@ xfs_atomic_write_cow_iomap_begin(return -EAGAIN ;trace_xfs_iomap_atomic_write_cow (ip, offset, length); - +retry:xfs_ilock (ip,XFS_ILOCK_EXCL );if (!ip->i_cowfp) {
@@ -1132,6 +1132,8 @@ xfs_atomic_write_cow_iomap_begin(if (!xfs_iext_lookup_extent (ip, ip->i_cowfp, offset_fsb, &icur, &cmap)) cmap.br_startoff = end_fsb;if (cmap.br_startoff <= offset_fsb) { +if (isnullstartblock (cmap.br_startblock)) + goto convert_delay;xfs_trim_extent (&cmap, offset_fsb, count_fsb); goto found; }
@@ -1160,8 +1162,10 @@ xfs_atomic_write_cow_iomap_begin(if (!xfs_iext_lookup_extent (ip, ip->i_cowfp, offset_fsb, &icur, &cmap)) cmap.br_startoff = end_fsb;if (cmap.br_startoff <= offset_fsb) { -xfs_trim_extent (&cmap, offset_fsb, count_fsb);xfs_trans_cancel (tp); +if (isnullstartblock (cmap.br_startblock)) + goto convert_delay; +xfs_trim_extent (&cmap, offset_fsb, count_fsb); goto found; }
@@ -1201,6 +1205,19 @@ found:xfs_iunlock (ip,XFS_ILOCK_EXCL );return xfs_bmbt_to_iomap (ip, iomap, &cmap, flags,IOMAP_F_SHARED , seq); +convert_delay: +xfs_iunlock (ip,XFS_ILOCK_EXCL ); + error =xfs_bmapi_convert_delalloc (ip,XFS_COW_FORK , offset, iomap, +NULL ); +if (error) +return error; + +/* +* Try the lookup again, because the delalloc conversion might have +* turned the COW mapping into unwritten, but we need it to be in +* written state. +*/ + goto retry; out_unlock:xfs_iunlock (ip,XFS_ILOCK_EXCL );return error;
Greg Kroah-Hartman
maintainerPATCH 821/849 xfs: fix various problems in xfs_atomic_write_cow_iomap_begin
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Darrick J. Wong <[email protected]>
commit 8d7bba1e8314013ecc817a91624104ceb9352ddc upstream.
I think there are several things wrong with this function:
A) xfs_bmapi_write can return a much larger unwritten mapping than what the caller asked for. We convert part of that range to written, but return the entire written mapping to iomap even though that's inaccurate.
B) The arguments to xfs_reflink_convert_cow_locked are wrong -- an unwritten mapping could be *smaller* than the write range (or even the hole range). In this case, we convert too much file range to written state because we then return a smaller mapping to iomap.
C) It doesn't handle delalloc mappings. This I covered in the patch that I already sent to the list.
D) Reassigning count_fsb to handle the hole means that if the second cmap lookup attempt succeeds (due to racing with someone else) we trim the mapping more than is strictly necessary. The changing meaning of count_fsb makes this harder to notice.
E) The tracepoint is kinda wrong because @length is mutated. That makes it harder to chase the data flows through this function because you can't just grep on the pos/bytecount strings.
F) We don't actually check that the br_state = XFS_EXT_NORM assignment is accurate, i.e that the cow fork actually contains a written mapping for the range we're interested in
G) Somewhat inadequate documentation of why we need to xfs_trim_extent so aggressively in this function.
H) Not sure why xfs_iomap_end_fsb is used here, the vfs already clamped the write range to s_maxbytes.
Fix these issues, and then the atomic writes regressions in generic/760, generic/617, generic/091, generic/263, and generic/521 all go away for me.
--- fs/xfs/xfs_iomap.c | 61 +++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 50 insertions(+), 11 deletions(-)
fs/xfs/xfs_iomap.c +50 -11
@@ -1082,6 +1082,29 @@ const struct iomap_ops xfs_zoned_direct_ };#endif /* CONFIG_XFS_RT */ +#ifdef DEBUG +static void +xfs_check_atomic_cow_conversion ( +struct xfs_inode *ip, +xfs_fileoff_t offset_fsb, +xfs_filblks_t count_fsb, +const struct xfs_bmbt_irec *cmap) +{ +struct xfs_iext_cursor icur; +struct xfs_bmbt_irec cmap2 = { }; + +if (xfs_iext_lookup_extent (ip, ip->i_cowfp, offset_fsb, &icur, &cmap2)) +xfs_trim_extent (&cmap2, offset_fsb, count_fsb); + +ASSERT (cmap2.br_startoff == cmap->br_startoff); +ASSERT (cmap2.br_blockcount == cmap->br_blockcount); +ASSERT (cmap2.br_startblock == cmap->br_startblock); +ASSERT (cmap2.br_state == cmap->br_state); +} +#else +# define xfs_check_atomic_cow_conversion (...) ((void)0) +#endif + static int xfs_atomic_write_cow_iomap_begin( struct inode *inode,
@@ -1093,9 +1116,10 @@ xfs_atomic_write_cow_iomap_begin( {struct xfs_inode *ip =XFS_I (inode);struct xfs_mount *mp = ip->i_mount; -const xfs_fileoff_t offset_fsb =XFS_B_TO_FSBT (mp, offset); -xfs_fileoff_t end_fsb =xfs_iomap_end_fsb (mp, offset, length); -xfs_filblks_t count_fsb = end_fsb - offset_fsb; +const xfs_fileoff_t offset_fsb =XFS_B_TO_FSBT (mp, offset); +const xfs_fileoff_t end_fsb =XFS_B_TO_FSB (mp, offset + length); +const xfs_filblks_t count_fsb = end_fsb - offset_fsb; +xfs_filblks_t hole_count_fsb;int nmaps =1 ;xfs_filblks_t resaligned;struct xfs_bmbt_irec cmap;
@@ -1134,14 +1158,20 @@ retry:if (cmap.br_startoff <= offset_fsb) {if (isnullstartblock (cmap.br_startblock)) goto convert_delay; + +/* +* cmap could extend outside the write range due to previous +* speculative preallocations. We must trim cmap to the write +* range because the cow fork treats written mappings to mean +* "write in progress". +*/ xfs_trim_extent (&cmap, offset_fsb, count_fsb); goto found; } - end_fsb = cmap.br_startoff; - count_fsb = end_fsb - offset_fsb; + hole_count_fsb = cmap.br_startoff - offset_fsb; - resaligned =xfs_aligned_fsb_count (offset_fsb, count_fsb, + resaligned =xfs_aligned_fsb_count (offset_fsb, hole_count_fsb,xfs_get_cowextsz_hint (ip));xfs_iunlock (ip,XFS_ILOCK_EXCL );
@@ -1177,7 +1207,7 @@ retry:* atomic writes to that same range will be aligned (and don't require * this COW-based method). */ - error =xfs_bmapi_write (tp, ip, offset_fsb, count_fsb, + error =xfs_bmapi_write (tp, ip, offset_fsb, hole_count_fsb,XFS_BMAPI_COWFORK |XFS_BMAPI_PREALLOC |XFS_BMAPI_EXTSZALIGN ,0 , &cmap, &nmaps);if (error) {
@@ -1190,17 +1220,26 @@ retry:if (error) goto out_unlock; +/* +* cmap could map more blocks than the range we passed into bmapi_write +* because of EXTSZALIGN or adjacent pre-existing unwritten mappings +* that were merged. Trim cmap to the original write range so that we +* don't convert more than we were asked to do for this write. +*/ +xfs_trim_extent (&cmap, offset_fsb, count_fsb); + found:if (cmap.br_state !=XFS_EXT_NORM ) { - error =xfs_reflink_convert_cow_locked (ip, offset_fsb, - count_fsb); + error =xfs_reflink_convert_cow_locked (ip, cmap.br_startoff, + cmap.br_blockcount);if (error) goto out_unlock; cmap.br_state =XFS_EXT_NORM ; +xfs_check_atomic_cow_conversion (ip, offset_fsb, count_fsb, + &cmap); } - length =XFS_FSB_TO_B (mp, cmap.br_startoff + cmap.br_blockcount); -trace_xfs_iomap_found (ip, offset, length - offset,XFS_COW_FORK , &cmap); +trace_xfs_iomap_found (ip, offset, length,XFS_COW_FORK , &cmap); seq =xfs_iomap_inode_sequence (ip,IOMAP_F_SHARED );xfs_iunlock (ip,XFS_ILOCK_EXCL );return xfs_bmbt_to_iomap (ip, iomap, &cmap, flags,IOMAP_F_SHARED , seq);
Greg Kroah-Hartman
maintainerPATCH 822/849 x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit f1fdffe0afea02ba783acfe815b6a60e7180df40 upstream.
Running x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an out of bounds access.
--- arch/x86/kernel/cpu/amd.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/kernel/cpu/amd.c +1 -0
@@ -1021,6 +1021,7 @@ static void init_amd_zen4(struct cpuinfostatic const struct x86_cpu_id zen5_rdseed_microcode[] = {ZEN_MODEL_STEP_UCODE (0x1a ,0x02 ,0x1 ,0x0b00215a ),ZEN_MODEL_STEP_UCODE (0x1a ,0x11 ,0x0 ,0x0b101054 ), + {}, };static void init_amd_zen5 (struct cpuinfo_x86 *c)
Greg Kroah-Hartman
maintainerPATCH 823/849 drm: define NVIDIA DRM format modifiers for GB20x
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Jones <[email protected]>
commit 1cf52a0d4ba079fb354fa1339f5fb34142228dae upstream.
The layout of bits within the individual tiles (referred to as sectors in the DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro) changed for 8 and 16-bit surfaces starting in Blackwell 2 GPUs (With the exception of GB10).
To denote the difference, extend the sector field in the parametric format modifier definition used to generate modifier values for NVIDIA hardware.
Without this change, it would be impossible to differentiate the two layouts based on modifiers, and as a result software could attempt to share surfaces directly between pre-GB20x and GB20x cards, resulting in corruption when the surface was accessed on one of the GPUs after being populated with content by the other.
Of note: This change causes the DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro to evaluate its "s" parameter twice, with the side effects that entails. I surveyed all usage of the modifier in the kernel and Mesa code, and that does not appear to be problematic in any current usage, but I thought it was worth calling out.
--- include/uapi/drm/drm_fourcc.h | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
include/uapi/drm/drm_fourcc.h +15 -8
@@ -979,14 +979,20 @@ extern "C" {* 2 = Gob Height 8, Turing+ Page Kind mapping * 3 = Reserved for future use. * -* 22:22 s Sector layout. On Tegra GPUs prior to Xavier, there is a further -* bit remapping step that occurs at an even lower level than the -* page kind and block linear swizzles. This causes the layout of -* surfaces mapped in those SOC's GPUs to be incompatible with the -* equivalent mapping on other GPUs in the same system. +* 22:22 s Sector layout. There is a further bit remapping step that occurs +* 26:27 at an even lower level than the page kind and block linear +* swizzles. This causes the bit arrangement of surfaces in memory +* to differ subtly, and prevents direct sharing of surfaces between +* GPUs with different layouts. * -* 0 = Tegra K1 - Tegra Parker/TX2 Layout. -* 1 = Desktop GPU and Tegra Xavier+ Layout +* 0 = Tegra K1 - Tegra Parker/TX2 Layout +* 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout +* 2 = GB20x(Blackwell 2)+ 8 bpp surface layout +* 3 = GB20x(Blackwell 2)+ 16 bpp surface layout +* 4 = Reserved for future use. +* 5 = Reserved for future use. +* 6 = Reserved for future use. +* 7 = Reserved for future use. * * 25:23 c Lossless Framebuffer Compression type. *
@@ -1001,7 +1007,7 @@ extern "C" {* 6 = Reserved for future use * 7 = Reserved for future use * -* 55:25 - Reserved for future use. Must be zero. +* 55:28 - Reserved for future use. Must be zero. */ #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (c, s, g, k, h) \ fourcc_mod_code(NVIDIA, (0x10 | \
@@ -1009,6 +1015,7 @@ extern "C" { (((k) &0xff ) <<12 ) | \ (((g) &0x3 ) <<20 ) | \ (((s) &0x1 ) <<22 ) | \ + (((s) &0x6 ) <<25 ) | \ (((c) & 0x7) << 23)))/* To grandfather in prior block linear format modifiers to the above layout,
Signature · 1 line
2.51.2
Greg Kroah-Hartman
maintainerPATCH 824/849 drm/nouveau: Advertise correct modifiers on GB20x
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Jones <[email protected]>
commit 664ce10246ba00746af94a08b7fbda8ccaacd930 upstream.
8 and 16 bit formats use a different layout on GB20x than they did on prior chips. Add the corresponding DRM format modifiers to the list of modifiers supported by the display engine on such chips, and filter the supported modifiers for each format based on its bytes per pixel in nv50_plane_format_mod_supported().
Note this logic will need to be updated when GB10 support is added, since it is a GB20x chip that uses the pre-GB20x sector layout for all formats.
--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++- drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 drivers/gpu/drm/nouveau/dispnv50/wndw.c | 24 ++++++++++++++++++-- drivers/gpu/drm/nouveau/dispnv50/wndwca7e.c | 33 ++++++++++++++++++++++++++++ 4 files changed, 59 insertions(+), 3 deletions(-)
drivers/gpu/drm/nouveau/dispnv50/disp.c +3 -1
@@ -2867,7 +2867,9 @@ nv50_display_create(struct drm_device *d }/* Assign the correct format modifiers */ -if (disp->disp->object.oclass >=TU102_DISP ) +if (disp->disp->object.oclass >=GB202_DISP ) +nouveau_display (dev)->format_modifiers = wndwca7e_modifiers; +else if (disp->disp->object.oclass >=TU102_DISP )nouveau_display (dev)->format_modifiers = wndwc57e_modifiers;else if (drm->client.device.info.family >=NV_DEVICE_INFO_V0_FERMI )
drivers/gpu/drm/nouveau/dispnv50/disp.h +1 -0
@@ -104,4 +104,5 @@ struct nouveau_encoder *nv50_real_outp(sextern const u64 disp50xx_modifiers[];extern const u64 disp90xx_modifiers[];extern const u64 wndwc57e_modifiers[]; +extern const u64 wndwca7e_modifiers[];#endif
drivers/gpu/drm/nouveau/dispnv50/wndw.c +22 -2
@@ -786,13 +786,14 @@ nv50_wndw_destroy(struct drm_plane *plan }/* This function assumes the format has already been validated against the plane -* and the modifier was validated against the device-wides modifier list at FB +* and the modifier was validated against the device-wide modifier list at FB * creation time. */ static bool nv50_plane_format_mod_supported (struct drm_plane *plane,u32 format,u64 modifier) {struct nouveau_drm *drm =nouveau_drm (plane->dev); +const struct drm_format_info *info =drm_format_info (format);uint8_t i;/* All chipsets can display all formats in linear layout */
@@ -800,13 +801,32 @@ static bool nv50_plane_format_mod_supporreturn true;if (drm->client.device.info.chipset <0xc0 ) { -const struct drm_format_info *info =drm_format_info (format);const uint8_t kind = (modifier >>12 ) &0xff ;if (!format)return false;for (i =0 ; i < info->num_planes; i++)if ((info->cpp[i] !=4 ) && kind !=0x70 )return false; + }else if (drm->client.device.info.chipset >=0x1b2 ) { +const uint8_t slayout = ((modifier >>22 ) &0x1 ) | + ((modifier >>25 ) &0x6 ); + +if (!format) +return false; + +/* +* Note in practice this implies only formats where cpp is equal +* for each plane, or >= 4 for all planes, are supported. +*/ +for (i =0 ; i < info->num_planes; i++) { +if (((info->cpp[i] ==2 ) && slayout !=3 ) || + ((info->cpp[i] ==1 ) && slayout !=2 ) || + ((info->cpp[i] >=4 ) && slayout !=1 )) +return false; + +/* 24-bit not supported. It has yet another layout */ +WARN_ON (info->cpp[i] ==3 ); + } }return true;
drivers/gpu/drm/nouveau/dispnv50/wndwca7e.c +33 -0
@@ -179,6 +179,39 @@ wndwca7e_ntfy_set(struct nv50_wndw *wndwreturn 0 ; } +/**************************************************************** +* Log2(block height) ----------------------------+ * +* Page Kind ----------------------------------+ | * +* Gob Height/Page Kind Generation ------+ | | * +* Sector layout -------+ | | | * +* Compression ------+ | | | | */ +const u64 wndwca7e_modifiers[] = {/* | | | | | */ +/* 4cpp+ modifiers */ +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,1 ,2 ,0x06 ,0 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,1 ,2 ,0x06 ,1 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,1 ,2 ,0x06 ,2 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,1 ,2 ,0x06 ,3 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,1 ,2 ,0x06 ,4 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,1 ,2 ,0x06 ,5 ), +/* 1cpp/8bpp modifiers */ +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,2 ,2 ,0x06 ,0 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,2 ,2 ,0x06 ,1 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,2 ,2 ,0x06 ,2 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,2 ,2 ,0x06 ,3 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,2 ,2 ,0x06 ,4 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,2 ,2 ,0x06 ,5 ), +/* 2cpp/16bpp modifiers */ +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,3 ,2 ,0x06 ,0 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,3 ,2 ,0x06 ,1 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,3 ,2 ,0x06 ,2 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,3 ,2 ,0x06 ,3 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,3 ,2 ,0x06 ,4 ), +DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D (0 ,3 ,2 ,0x06 ,5 ), +/* All formats support linear */ +DRM_FORMAT_MOD_LINEAR , +DRM_FORMAT_MOD_INVALID +}; +static const struct nv50_wndw_func wndwca7e = { .acquire = wndwc37e_acquire,
Greg Kroah-Hartman
maintainerPATCH 825/849 drm/amdgpu/smu: Handle S0ix for vangogh
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 7c5609b72bfe57d8c601d9561e0d2551b605c017 upstream.
Fix the flows for S0ix. There is no need to stop
rlc or reintialize PMFW in S0ix.
--- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 6 ++++++ drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 3 +++ 2 files changed, 9 insertions(+)
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +6 -0
@@ -2012,6 +2012,12 @@ static int smu_disable_dpms(struct smu_c smu->is_apu && (amdgpu_in_reset(adev) || adev->in_s0ix))return 0 ; +/* vangogh s0ix */ +if ((amdgpu_ip_version (adev,MP1_HWIP ,0 ) ==IP_VERSION (11 ,5 ,0 ) || +amdgpu_ip_version (adev,MP1_HWIP ,0 ) ==IP_VERSION (11 ,5 ,2 )) && + adev->in_s0ix) +return 0 ; +/* * For gpu reset, runpm and hibernation through BACO, * BACO feature has to be kept enabled.
drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c +3 -0
@@ -2217,6 +2217,9 @@ static int vangogh_post_smu_init(structuint32_t total_cu = adev->gfx.config.max_cu_per_sh * adev->gfx.config.max_sh_per_se * adev->gfx.config.max_shader_engines; +if (adev->in_s0ix) +return 0 ; +/* allow message will be sent after enable message on Vangogh*/ if (smu_cmn_feature_is_enabled (smu,SMU_FEATURE_DPM_GFXCLK_BIT ) && (adev->pg_flags &AMD_PG_SUPPORT_GFX_PG )) {
Greg Kroah-Hartman
maintainerPATCH 826/849 drm/amd/display: Fix NULL deref in debugfs odm_combine_segments
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rong Zhang <[email protected]>
commit 6dd97ceb645c08aca9fc871a3006e47fe699f0ac upstream.
When a connector is connected but inactive (e.g., disabled by desktop environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading odm_combine_segments causes kernel NULL pointer dereference.
BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 </TASK> Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554
Fix this by checking pipe_ctx->stream_res.tg before dereferencing.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +2 -1
@@ -1301,7 +1301,8 @@ static int odm_combine_segments_show(strif (connector->status != connector_status_connected)return -ENODEV ; -if (pipe_ctx !=NULL && pipe_ctx->stream_res.tg->funcs->get_odm_combine_segments) +if (pipe_ctx && pipe_ctx->stream_res.tg && + pipe_ctx->stream_res.tg->funcs->get_odm_combine_segments) pipe_ctx->stream_res.tg->funcs->get_odm_combine_segments (pipe_ctx->stream_res.tg, &segments);seq_printf (m,"%d\n" , segments);
Greg Kroah-Hartman
maintainerPATCH 827/849 drm/amdkfd: Dont clear PT after process killed
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Philip Yang <[email protected]>
commit 597eb70f7ff7551ff795cd51754b81aabedab67b upstream.
If process is killed. the vm entity is stopped, submit pt update job will trigger the error message "*ERROR* Trying to push to a killed entity", job will not execute.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +4 -0
@@ -1263,6 +1263,10 @@ static int unmap_bo_from_gpuvm(struct kg (void )amdgpu_vm_bo_unmap (adev, bo_va, entry->va); +/* VM entity stopped if process killed, don't clear freed pt bo */ +if (!amdgpu_vm_ready (vm)) +return 0 ; + (void )amdgpu_vm_clear_freed (adev, vm, &bo_va->last_pt_update); (void )amdgpu_sync_fence (sync, bo_va->last_pt_update,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 828/849 virtio-net: fix received length check in big packets
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bui Quang Minh <[email protected]>
commit 0c716703965ffc5ef4311b65cb5d84a703784717 upstream.
Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags.
Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one.
This commit fixes the received length check corresponding to the new change.
--- drivers/net/virtio_net.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-)
drivers/net/virtio_net.c +12 -13
@@ -910,17 +910,6 @@ static struct sk_buff *page_to_skb(struc goto ok; } -/* -* Verify that we can indeed put this data into a skb. -* This is here to handle cases when the device erroneously -* tries to receive more than is possible. This is usually -* the case of a broken device. -*/ -if (unlikely (len >MAX_SKB_FRAGS *PAGE_SIZE )) { -net_dbg_ratelimited ("%s: too much data\n" , skb->dev->name); -dev_kfree_skb (skb); -return NULL ; - }BUG_ON (offset >=PAGE_SIZE );while (len) {unsigned int frag_size =min ((unsigned )PAGE_SIZE - offset, len);
@@ -2112,9 +2101,19 @@ static struct sk_buff *receive_big(struc struct virtnet_rq_stats *stats) {struct page *page = buf; -struct sk_buff *skb = -page_to_skb (vi, rq, page,0 , len,PAGE_SIZE ,0 ); +struct sk_buff *skb; + +/* Make sure that len does not exceed the size allocated in +* add_recvbuf_big. +*/ +if (unlikely (len > (vi->big_packets_num_skbfrags +1 ) *PAGE_SIZE )) { +pr_debug ("%s: rx error: len %u exceeds allocated size %lu\n" , + dev->name, len, + (vi->big_packets_num_skbfrags +1 ) *PAGE_SIZE ); + goto err; + } + skb =page_to_skb (vi, rq, page,0 , len,PAGE_SIZE ,0 );u64_stats_add (&stats->bytes, len - vi->hdr_len);if (unlikely (!skb)) goto err;
Greg Kroah-Hartman
maintainerPATCH 829/849 virtio_net: fix alignment for virtio_net_hdr_v1_hash
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael S. Tsirkin <[email protected]>
commit c3838262b824c71c145cd3668722e99a69bc9cd9 upstream.
Changing alignment of header would mean it's no longer safe to cast a 2 byte aligned pointer between formats. Use two 16 bit fields to make it 2 byte aligned as previously.
This fixes the performance regression since
commit ("virtio_net: enable gso over UDP tunnel support.") as it uses virtio_net_hdr_v1_hash_tunnel which embeds virtio_net_hdr_v1_hash. Pktgen in guest + XDP_DROP on TAP + vhost_net shows the TX PPS is recovered from 2.4Mpps to 4.45Mpps.
--- drivers/net/virtio_net.c | 15 +++++++++++++-- include/linux/virtio_net.h | 3 ++- include/uapi/linux/virtio_net.h | 3 ++- 3 files changed, 17 insertions(+), 4 deletions(-)
drivers/net/virtio_net.c +13 -2
@@ -2539,6 +2539,13 @@ err_buf:return NULL ; } +static inline u32 +virtio_net_hash_value (const struct virtio_net_hdr_v1_hash *hdr_hash) +{ +return __le16_to_cpu (hdr_hash->hash_value_lo) | + (__le16_to_cpu (hdr_hash->hash_value_hi) <<16 ); +} +static void virtio_skb_set_hash (const struct virtio_net_hdr_v1_hash *hdr_hash,struct sk_buff *skb) {
@@ -2565,7 +2572,7 @@ static void virtio_skb_set_hash(const stdefault : rss_hash_type =PKT_HASH_TYPE_NONE ; } -skb_set_hash (skb,__le32_to_cpu (hdr_hash->hash_value), rss_hash_type); +skb_set_hash (skb,virtio_net_hash_value (hdr_hash), rss_hash_type); } static void virtnet_receive_done(struct virtnet_info *vi, struct receive_queue *rq,
@@ -3311,6 +3318,10 @@ static int xmit_skb(struct send_queue *spr_debug ("%s: xmit %p %pM\n" , vi->dev->name, skb, dest); +/* Make sure it's safe to cast between formats */ + BUILD_BUG_ON(__alignof__(*hdr) != __alignof__(hdr->hash_hdr)); + BUILD_BUG_ON(__alignof__(*hdr) != __alignof__(hdr->hash_hdr.hdr)); + can_push = vi->any_header_sg && !((unsigned long)skb->data & (__alignof__(*hdr) - 1)) && !skb_header_cloned (skb) &&skb_headroom (skb) >= hdr_len;
@@ -6759,7 +6770,7 @@ static int virtnet_xdp_rx_hash(const str hash_report =VIRTIO_NET_HASH_REPORT_NONE ; *rss_type = virtnet_xdp_rss_type[hash_report]; - *hash =__le32_to_cpu (hdr_hash->hash_value); + *hash =virtio_net_hash_value (hdr_hash);return 0 ; }
include/linux/virtio_net.h +2 -1
@@ -401,7 +401,8 @@ virtio_net_hdr_tnl_from_skb(const structif (!tnl_hdr_negotiated)return -EINVAL ; - vhdr->hash_hdr.hash_value =0 ; + vhdr->hash_hdr.hash_value_lo =0 ; + vhdr->hash_hdr.hash_value_hi =0 ; vhdr->hash_hdr.hash_report =0 ; vhdr->hash_hdr.padding =0 ;
include/uapi/linux/virtio_net.h +2 -1
@@ -193,7 +193,8 @@ struct virtio_net_hdr_v1 {struct virtio_net_hdr_v1_hash {struct virtio_net_hdr_v1 hdr; -__le32 hash_value; +__le16 hash_value_lo; +__le16 hash_value_hi;#define VIRTIO_NET_HASH_REPORT_NONE 0#define VIRTIO_NET_HASH_REPORT_IPv4 1#define VIRTIO_NET_HASH_REPORT_TCPv4 2
Greg Kroah-Hartman
maintainerPATCH 830/849 lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 2b81082ad37cc3f28355fb73a6a69b91ff7dbf20 upstream.
Commit 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") inadvertently disabled KASAN in curve25519-hacl64.o for GCC unconditionally because clang-min-version will always evaluate to nothing for GCC. Add a check for CONFIG_CC_IS_CLANG to avoid applying the workaround for GCC, which is only needed for clang-17 and older.
--- lib/crypto/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
lib/crypto/Makefile +1 -1
@@ -48,7 +48,7 @@ libcurve25519-generic-y := curve25519 libcurve25519-generic-$(CONFIG_ARCH_SUPPORTS_INT128) := curve25519-hacl64.o libcurve25519-generic-y += curve25519-generic.o # clang versions prior to 18 may blow out the stack with KASAN -ifeq ($(call clang-min-version, 180000),) +ifeq ($(CONFIG_CC_IS_CLANG)_$(call clang-min-version, 180000),y_) KASAN_SANITIZE_curve25519-hacl64.o := n endif
Greg Kroah-Hartman
maintainerPATCH 831/849 scsi: ufs: ufs-pci: Fix S0ix/S3 for Intel controllers
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit bb44826c3bdbf1fa3957008a04908f45e5666463 upstream.
Intel platforms with UFS, can support Suspend-to-Idle (S0ix) and Suspend-to-RAM (S3). For S0ix the link state should be HIBERNATE. For S3, state is lost, so the link state must be OFF. Driver policy, expressed by spm_lvl, can be 3 (link HIBERNATE, device SLEEP) for S0ix but must be changed to 5 (link OFF, device POWEROFF) for S3.
Fix support for S0ix/S3 by switching spm_lvl as needed. During suspend ->prepare(), if the suspend target state is not Suspend-to-Idle, ensure the spm_lvl is at least 5 to ensure that resume will be possible from deep sleep states. During suspend ->complete(), restore the spm_lvl to its original value that is suitable for S0ix.
This fix is first needed in Intel Alder Lake based controllers.
--- drivers/ufs/host/ufshcd-pci.c | 67 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 65 insertions(+), 2 deletions(-)
drivers/ufs/host/ufshcd-pci.c +65 -2
@@ -15,6 +15,7 @@#include <linux/pci.h> #include <linux/pm_runtime.h> #include <linux/pm_qos.h> +#include <linux/suspend.h> #include <linux/debugfs.h> #include <linux/uuid.h> #include <linux/acpi.h>
@@ -31,6 +32,7 @@ struct intel_host {u32 dsm_fns;u32 active_ltr;u32 idle_ltr; +int saved_spm_lvl;struct dentry *debugfs_root;struct gpio_desc *reset_gpio; };
@@ -347,6 +349,7 @@ static int ufs_intel_common_init(struct host =devm_kzalloc (hba->dev,sizeof (*host),GFP_KERNEL );if (!host)return -ENOMEM ; + host->saved_spm_lvl =-1 ;ufshcd_set_variant (hba, host);intel_dsm_init (host, hba->dev);if (INTEL_DSM_SUPPORTED (host,RESET )) {
@@ -538,6 +541,66 @@ static int ufshcd_pci_restore(struct devreturn ufshcd_system_resume (dev); } + +static int ufs_intel_suspend_prepare (struct device *dev) +{ +struct ufs_hba *hba =dev_get_drvdata (dev); +struct intel_host *host =ufshcd_get_variant (hba); +int err; + +/* +* Only s2idle (S0ix) retains link state. Force power-off +* (UFS_PM_LVL_5) for any other case. +*/ +if (pm_suspend_target_state !=PM_SUSPEND_TO_IDLE && hba->spm_lvl <UFS_PM_LVL_5 ) { + host->saved_spm_lvl = hba->spm_lvl; + hba->spm_lvl =UFS_PM_LVL_5 ; + } + + err =ufshcd_suspend_prepare (dev); + +if (err <0 && host->saved_spm_lvl !=-1 ) { + hba->spm_lvl = host->saved_spm_lvl; + host->saved_spm_lvl =-1 ; + } + +return err; +} + +static void ufs_intel_resume_complete (struct device *dev) +{ +struct ufs_hba *hba =dev_get_drvdata (dev); +struct intel_host *host =ufshcd_get_variant (hba); + +ufshcd_resume_complete (dev); + +if (host->saved_spm_lvl !=-1 ) { + hba->spm_lvl = host->saved_spm_lvl; + host->saved_spm_lvl =-1 ; + } +} + +static int ufshcd_pci_suspend_prepare (struct device *dev) +{ +struct ufs_hba *hba =dev_get_drvdata (dev); + +if (!strcmp (hba->vops->name,"intel-pci" )) +return ufs_intel_suspend_prepare (dev); + +return ufshcd_suspend_prepare (dev); +} + +static void ufshcd_pci_resume_complete (struct device *dev) +{ +struct ufs_hba *hba =dev_get_drvdata (dev); + +if (!strcmp (hba->vops->name,"intel-pci" )) { +ufs_intel_resume_complete (dev); +return ; + } + +ufshcd_resume_complete (dev); +}#endif /**
@@ -611,8 +674,8 @@ static const struct dev_pm_ops ufshcd_pc .thaw = ufshcd_system_resume, .poweroff = ufshcd_system_suspend, .restore = ufshcd_pci_restore, - .prepare = ufshcd_suspend_prepare, - .complete = ufshcd_resume_complete, + .prepare = ufshcd_pci_suspend_prepare, + .complete = ufshcd_pci_resume_complete,#endif };
Greg Kroah-Hartman
maintainerPATCH 832/849 scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit d968e99488c4b08259a324a89e4ed17bf36561a4 upstream.
Link startup becomes unreliable for Intel Alder Lake based host controllers when a 2nd DME_LINKSTARTUP is issued unnecessarily. Employ UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress that from happening.
--- drivers/ufs/host/ufshcd-pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/ufs/host/ufshcd-pci.c +2 -1
@@ -428,7 +428,8 @@ static int ufs_intel_lkf_init(struct ufsstatic int ufs_intel_adl_init (struct ufs_hba *hba) { hba->nop_out_timeout =200 ; - hba->quirks |=UFSHCD_QUIRK_BROKEN_AUTO_HIBERN8 ; + hba->quirks |=UFSHCD_QUIRK_BROKEN_AUTO_HIBERN8 | +UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE ; hba->caps |=UFSHCD_CAP_WB_EN ;return ufs_intel_common_init (hba); }
Greg Kroah-Hartman
maintainerPATCH 833/849 scsi: ufs: core: Add a quirk to suppress link_startup_again
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit d34caa89a132cd69efc48361d4772251546fdb88 upstream.
ufshcd_link_startup() has a facility (link_startup_again) to issue DME_LINKSTARTUP a 2nd time even though the 1st time was successful.
Some older hardware benefits from that, however the behaviour is non-standard, and has been found to cause link startup to be unreliable for some Intel Alder Lake based host controllers.
Add UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress link_startup_again, in preparation for setting the quirk for affected controllers.
--- drivers/ufs/core/ufshcd.c | 3 ++- include/ufs/ufshcd.h | 7 +++++++ 2 files changed, 9 insertions(+), 1 deletion(-)
drivers/ufs/core/ufshcd.c +2 -1
@@ -5060,7 +5060,8 @@ static int ufshcd_link_startup(struct uf* If UFS device isn't active then we will have to issue link startup * 2 times to make sure the device state move to active. */ -if (!ufshcd_is_ufs_dev_active (hba)) +if (!(hba->quirks &UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE ) && + !ufshcd_is_ufs_dev_active (hba)) link_startup_again = true; link_startup:
include/ufs/ufshcd.h +7 -0
@@ -689,6 +689,13 @@ enum ufshcd_quirks {* single doorbell mode. */ UFSHCD_QUIRK_BROKEN_LSDBS_CAP =1 <<25 , + +/* +* This quirk indicates that DME_LINKSTARTUP should not be issued a 2nd +* time (refer link_startup_again) after the 1st time was successful, +* because it causes link startup to become unreliable. +*/ + UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE = 1 << 26, }; enum ufshcd_caps {
Greg Kroah-Hartman
maintainerPATCH 834/849 scsi: ufs: core: Fix invalid probe error return value
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit a2b32bc1d9e359a9f90d0de6af16699facb10935 upstream.
After DME Link Startup, the error return value is set to the MIPI UniPro GenericErrorCode which can be 0 (SUCCESS) or 1 (FAILURE). Upon failure during driver probe, the error code 1 is propagated back to the driver probe function which must return a negative value to indicate an error, but 1 is not negative, so the probe is considered to be successful even though it failed. Subsequently, removing the driver results in an oops because it is not in a valid state.
This happens because none of the callers of ufshcd_init() expect a non-negative error code.
Fix the return value and documentation to match actual usage.
--- drivers/ufs/core/ufshcd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/ufs/core/ufshcd.c +2 -2
@@ -10638,7 +10638,7 @@ remove_scsi_host:* @mmio_base: base register address * @irq: Interrupt line of device * -* Return: 0 on success, non-zero value on failure. +* Return: 0 on success; < 0 on failure. */ int ufshcd_init (struct ufs_hba *hba,void __iomem *mmio_base,unsigned int irq) {
@@ -10879,7 +10879,7 @@ out_disable: hba->is_irq_enabled = false;ufshcd_hba_exit (hba); out_error: -return err; +return err >0 ? -EIO : err; }EXPORT_SYMBOL_GPL (ufshcd_init);
Greg Kroah-Hartman
maintainerPATCH 835/849 drm/amd/display: update color on atomic commit time
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Melissa Wen <[email protected]>
commit 2f9c63883730a0bfecb086e6e59246933f936ca1 upstream.
Use atomic_commit_setup to change the DC stream state. It's a preparation to remove from atomic_check changes in CRTC color components of DC stream state and prevent DC to commit TEST_ONLY changes.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 +++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +35 -1
@@ -243,6 +243,7 @@ static int amdgpu_dm_encoder_init(structstatic int amdgpu_dm_connector_get_modes (struct drm_connector *connector); +static int amdgpu_dm_atomic_setup_commit (struct drm_atomic_state *state);static void amdgpu_dm_atomic_commit_tail (struct drm_atomic_state *state); static int amdgpu_dm_atomic_check(struct drm_device *dev,
@@ -3657,7 +3658,7 @@ static const struct drm_mode_config_funcstatic struct drm_mode_config_helper_funcs amdgpu_dm_mode_config_helperfuncs = { .atomic_commit_tail = amdgpu_dm_atomic_commit_tail, - .atomic_commit_setup = drm_dp_mst_atomic_setup_commit, + .atomic_commit_setup = amdgpu_dm_atomic_setup_commit, };static void update_connector_ext_caps (struct amdgpu_dm_connector *aconnector)
@@ -10208,6 +10209,39 @@ static void dm_set_writeback(struct amdgdrm_writeback_queue_job (wb_conn, new_con_state); } +static int amdgpu_dm_atomic_setup_commit (struct drm_atomic_state *state) +{ +struct drm_crtc *crtc; +struct drm_crtc_state *old_crtc_state, *new_crtc_state; +struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; +int i, ret; + + ret =drm_dp_mst_atomic_setup_commit (state); +if (ret) +return ret; + +for_each_oldnew_crtc_in_state (state, crtc, old_crtc_state, new_crtc_state, i) { + dm_old_crtc_state =to_dm_crtc_state (old_crtc_state); + dm_new_crtc_state =to_dm_crtc_state (new_crtc_state); +/* +* Color management settings. We also update color properties +* when a modeset is needed, to ensure it gets reprogrammed. +*/ +if (dm_new_crtc_state->base.active && dm_new_crtc_state->stream && + (dm_new_crtc_state->base.color_mgmt_changed || + dm_old_crtc_state->regamma_tf != dm_new_crtc_state->regamma_tf || +drm_atomic_crtc_needs_modeset (new_crtc_state))) { + ret =amdgpu_dm_update_crtc_color_mgmt (dm_new_crtc_state); +if (ret) { +drm_dbg_atomic (state->dev,"Failed to update color state\n" ); +return ret; + } + } + } + +return 0 ; +} +/** * amdgpu_dm_atomic_commit_tail() - AMDgpu DM's commit tail implementation. * @state: The atomic state to commit
Greg Kroah-Hartman
maintainerPATCH 836/849 extcon: adc-jack: Cleanup wakeup source only if it was enabled
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 92bac7d4de9c07933f6b76d8f1c7f8240f911f4f upstream.
Driver in the probe enables wakeup source conditionally, so the cleanup path should do the same - do not release the wakeup source memory if it was not allocated.
--- drivers/extcon/extcon-adc-jack.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/extcon/extcon-adc-jack.c +2 -1
@@ -164,7 +164,8 @@ static void adc_jack_remove(struct platf {struct adc_jack_data *data =platform_get_drvdata (pdev); -device_init_wakeup (&pdev->dev, false); +if (data->wakeup_source) +device_init_wakeup (&pdev->dev, false);free_irq (data->irq, data);cancel_work_sync (&data->handler.work); }
Greg Kroah-Hartman
maintainerPATCH 837/849 kunit: Extend kconfig help text for KUNIT_UML_PCI
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Weißschuh <[email protected]>
commit 285cae57a51664cc94e85de0ff994f9965b3aca8 upstream.
Checkpatch.pl expects at least 4 lines of help text.
Extend the help text to make checkpatch.pl happy.
--- lib/kunit/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)
lib/kunit/Kconfig +4 -0
@@ -112,5 +112,9 @@ config KUNIT_UML_PCI select UML_PCI help Enables the PCI subsystem on UML for use by KUnit tests. + Some KUnit tests require the PCI core which is not enabled by + default on UML. + + If unsure, say N. endif # KUNIT
Signature · 1 line
2.51.2
Greg Kroah-Hartman
maintainerPATCH 838/849 ALSA: hda/tas2781: Enable init_profile_id for device initialization
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shenghao Ding <[email protected]>
commit 7ddb711b6e0d33e0a673b49f69dff0d950ed60b9 upstream.
Optimize the time consumption of profile switching, init_profile saves the common settings of different profiles, such as the dsp coefficients, etc, which can greatly reduce the profile switching time comsumption and remove the repetitive settings.
--- sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +12 -0
@@ -472,6 +472,12 @@ static void tasdevice_dspfw_init(void *cif (tas_priv->fmw->nr_configurations >0 ) tas_priv->cur_conf =0 ; +/* Init common setting for different audio profiles */ +if (tas_priv->rcabin.init_profile_id >=0 ) +tasdevice_select_cfg_blk (tas_priv, + tas_priv->rcabin.init_profile_id, +TASDEVICE_BIN_BLK_PRE_POWER_UP ); +/* If calibrated data occurs error, dsp will still works with default * calibrated data inside algo. */
@@ -760,6 +766,12 @@ static int tas2781_system_resume(structtasdevice_reset (tas_hda->priv);tasdevice_prmg_load (tas_hda->priv, tas_hda->priv->cur_prog); +/* Init common setting for different audio profiles */ +if (tas_hda->priv->rcabin.init_profile_id >=0 ) +tasdevice_select_cfg_blk (tas_hda->priv, + tas_hda->priv->rcabin.init_profile_id, +TASDEVICE_BIN_BLK_PRE_POWER_UP ); +if (tas_hda->priv->playback_started)tasdevice_tuning_switch (tas_hda->priv,0 );
Greg Kroah-Hartman
maintainerPATCH 839/849 ACPI: SPCR: Check for table version when using precise baudrate
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Punit Agrawal <[email protected]>
commit 543d35004007a06ef247acf2fc55efa8388aa741 upstream.
Commit 4d330fe54145 ("ACPI: SPCR: Support Precise Baud Rate field") added support to use the precise baud rate available since SPCR 1.09 (revision 4) but failed to check the version of the table provided by the firmware.
Accessing an older version of SPCR table causes accesses beyond the end of the table and can lead to garbage data to be used for the baud rate.
Check the version of the firmware provided SPCR to ensure that the precise baudrate is vaild before using it.
--- drivers/acpi/spcr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/spcr.c +1 -1
@@ -152,7 +152,7 @@ int __init acpi_parse_spcr(bool enable_e* Baud Rate field. If this field is zero or not present, Configured * Baud Rate is used. */ -if (table->precise_baudrate) +if (table->header.revision >=4 && table->precise_baudrate) baud_rate = table->precise_baudrate;else switch (table->baud_rate) {case 0 :
Greg Kroah-Hartman
maintainerPATCH 840/849 kbuild: Strip trailing padding bytes from modules.builtin.modinfo
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit a26a6c93edfeee82cb73f55e87d995eea59ddfe8 upstream.
After commit d50f21091358 ("kbuild: align modinfo section for Secureboot Authenticode EDK2 compat"), running modules_install with certain versions of kmod (such as 29.1 in Ubuntu Jammy) in certain configurations may fail with:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
The additional padding bytes to ensure .modinfo is aligned within vmlinux.unstripped are unexpected by kmod, as this section has always just been null-terminated strings.
Strip the trailing padding bytes from modules.builtin.modinfo after it has been extracted from vmlinux.unstripped to restore the format that kmod expects while keeping .modinfo aligned within vmlinux.unstripped to avoid regressing the Authenticode calculation fix for EDK2.
[nathan: Apply to scripts/Makefile.vmlinux_o, location of
modules.builtin.modinfo rule prior to 39cfd5b12160]
--- scripts/Makefile.vmlinux_o | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
scripts/Makefile.vmlinux_o +14 -1
@@ -76,11 +76,24 @@ targets += vmlinux.o # modules.builtin.modinfo # --------------------------------------------------------------------------- +# .modinfo in vmlinux.unstripped is aligned to 8 bytes for compatibility with +# tools that expect vmlinux to have sufficiently aligned sections but the +# additional bytes used for padding .modinfo to satisfy this requirement break +# certain versions of kmod with +# +# depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix +# +# Strip the trailing padding bytes after extracting .modinfo to comply with +# what kmod expects to parse. +quiet_cmd_modules_builtin_modinfo = GEN $@ + cmd_modules_builtin_modinfo = $(cmd_objcopy); \ + sed -i 's/\x00\+$$/\x00/g' $@ + OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary targets += modules.builtin.modinfo modules.builtin.modinfo: vmlinux.o FORCE - $(call if_changed,objcopy) + $(call if_changed,modules_builtin_modinfo) # modules.builtin # ---------------------------------------------------------------------------
Greg Kroah-Hartman
maintainerPATCH 841/849 drm/amdgpu: Fix unintended error log in VCN5_0_0
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sathishkumar S <[email protected]>
commit 46b0e6b9d749cfa891e6969d6565be1131c53aa2 upstream.
The error log is supposed to be gaurded under if failure condition.
--- drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c +3 -2
@@ -769,9 +769,10 @@ static int vcn_v5_0_0_start_dpg_mode(strif (indirect) { ret =amdgpu_vcn_psp_update_sram (adev, inst_idx,0 ); -dev_err (adev->dev,"%s: vcn sram load failed %d\n" , __func__, ret); -if (ret) +if (ret) { +dev_err (adev->dev,"%s: vcn sram load failed %d\n" , __func__, ret);return ret; + } } ring = &adev->vcn.inst[inst_idx].ring_enc[0 ];
Greg Kroah-Hartman
maintainerPATCH 842/849 drm/amd/display: Fix vupdate_offload_work doc
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aurabindo Pillai <[email protected]>
commit e9c840d4505d5049da1873acf93744d384b12a0b upstream.
Fix the following warning in struct documentation:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:168: warning: expecting prototype for struct dm_vupdate_work. Prototype was for struct vupdate_offload_work instead
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +1 -1
@@ -153,7 +153,7 @@ struct idle_workqueue { };/** -* struct dm_vupdate_work - Work data for periodic action in idle +* struct vupdate_offload_work - Work data for offloading task from vupdate handler * @work: Kernel work data for the work event * @adev: amdgpu_device back pointer * @stream: DC stream associated with the crtc
Greg Kroah-Hartman
maintainerPATCH 843/849 drm/amdgpu: Fix function header names in amdgpu_connectors.c
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivasan Shanmugam <[email protected]>
commit 38ab33dbea594700c8d6cc81eec0a54e95d3eb2f upstream.
Align the function headers for amdgpu_max_hdmi_pixel_clock and amdgpu_connector_dvi_mode_valid with the function implementations so they match the expected kdoc style.
Fixes the below:drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1199: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Returns the maximum supported HDMI (TMDS) pixel clock in KHz.drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1212: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Validates the given display mode on DVI and HDMI connectors.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +12 -3
@@ -1196,7 +1196,10 @@ static void amdgpu_connector_dvi_force(s }/** -* Returns the maximum supported HDMI (TMDS) pixel clock in KHz. +* amdgpu_max_hdmi_pixel_clock - Return max supported HDMI (TMDS) pixel clock +* @adev: pointer to amdgpu_device +* +* Return: maximum supported HDMI (TMDS) pixel clock in KHz. */ static int amdgpu_max_hdmi_pixel_clock (const struct amdgpu_device *adev) {
@@ -1209,8 +1212,14 @@ static int amdgpu_max_hdmi_pixel_clock(c }/** -* Validates the given display mode on DVI and HDMI connectors, -* including analog signals on DVI-I. +* amdgpu_connector_dvi_mode_valid - Validate a mode on DVI/HDMI connectors +* @connector: DRM connector to validate the mode on +* @mode: display mode to validate +* +* Validate the given display mode on DVI and HDMI connectors, including +* analog signals on DVI-I. +* +* Return: drm_mode_status indicating whether the mode is valid. */ static enum drm_mode_status amdgpu_connector_dvi_mode_valid (struct drm_connector *connector,const struct drm_display_mode *mode)
Greg Kroah-Hartman
maintainerPATCH 844/849 drm/amdgpu/userq: assign an error code for invalid userq va
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prike Liang <[email protected]>
commit 883bd89d00085c2c5f1efcd25861745cb039f9e3 upstream.
It should return an error code if userq VA validation fails.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c +2 -0
@@ -71,6 +71,7 @@ int amdgpu_userq_input_va_validate(strucreturn 0 ; } + r = -EINVAL ; out_err:amdgpu_bo_unreserve (vm->root.bo);return r;
@@ -476,6 +477,7 @@ amdgpu_userq_create(struct drm_file *filif (amdgpu_userq_input_va_validate (&fpriv->vm, args->in.queue_va, args->in.queue_size) ||amdgpu_userq_input_va_validate (&fpriv->vm, args->in.rptr_va,AMDGPU_GPU_PAGE_SIZE ) ||amdgpu_userq_input_va_validate (&fpriv->vm, args->in.wptr_va,AMDGPU_GPU_PAGE_SIZE )) { + r = -EINVAL ;kfree (queue); goto unlock; }
Greg Kroah-Hartman
maintainerPATCH 845/849 drm/msm/dpu: Fix adjusted mode clock check for 3d merge
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jessica Zhang <[email protected]>
commit f5d079564c44baaeedf5e25f4b943aa042ea0eb1 upstream.
Since 3D merge allows for larger modes to be supported across 2 layer mixers, filter modes based on adjusted mode clock / 2 when 3d merge is supported.
Patchwork: https://patchwork.freedesktop.org/patch/676353/
--- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +3 -0
@@ -1546,6 +1546,9 @@ static enum drm_mode_status dpu_crtc_mod adjusted_mode_clk =dpu_core_perf_adjusted_mode_clk (mode->clock, dpu_kms->perf.perf_cfg); +if (dpu_kms->catalog->caps->has_3d_merge) + adjusted_mode_clk /=2 ; +/* * The given mode, adjusted for the perf clock factor, should not exceed * the max core clock rate
Greg Kroah-Hartman
maintainerPATCH 846/849 drm/amd/display: Reject modes with too high pixel clock on DCE6-10
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Timur Kristóf <[email protected]>
commit 118800b0797a046adaa2a8e9dee9b971b78802a7 upstream.
Reject modes with a pixel clock higher than the maximum display clock. Use 400 MHz as a fallback value when the maximum display clock is not known. Pixel clocks that are higher than the display clock just won't work and are not supported.
With the addition of the YUV422 fallback, DC can now accidentally
select a mode requiring higher pixel clock than actually supported when the DP version supports the required bandwidth but the clock is otherwise too high for the display engine. DCE 6-10 don't support these modes but they don't have a bandwidth calculation to reject them properly.
--- drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c | 3 +++ drivers/gpu/drm/amd/display/dc/clk_mgr/dce60/dce60_clk_mgr.c | 5 +++++ drivers/gpu/drm/amd/display/dc/resource/dce100/dce100_resource.c | 10 +++++++++- drivers/gpu/drm/amd/display/dc/resource/dce60/dce60_resource.c | 10 +++++++++- drivers/gpu/drm/amd/display/dc/resource/dce80/dce80_resource.c | 10 +++++++++- 5 files changed, 35 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c +3 -0
@@ -463,6 +463,9 @@ void dce_clk_mgr_construct( clk_mgr->max_clks_state =DM_PP_CLOCKS_STATE_NOMINAL ; clk_mgr->cur_min_clks_state =DM_PP_CLOCKS_STATE_INVALID ; + base->clks.max_supported_dispclk_khz = + clk_mgr->max_clks_by_state[DM_PP_CLOCKS_STATE_PERFORMANCE ].display_clk_khz; +dce_clock_read_integrated_info (clk_mgr);dce_clock_read_ss_info (clk_mgr); }
drivers/gpu/drm/amd/display/dc/clk_mgr/dce60/dce60_clk_mgr.c +5 -0
@@ -147,6 +147,8 @@ void dce60_clk_mgr_construct(struct dc_context *ctx, struct clk_mgr_internal *clk_mgr) { + struct clk_mgr *base = &clk_mgr->base; +dce_clk_mgr_construct (ctx, clk_mgr); memcpy(clk_mgr->max_clks_by_state,
@@ -157,5 +159,8 @@ void dce60_clk_mgr_construct( clk_mgr->clk_mgr_shift = &disp_clk_shift; clk_mgr->clk_mgr_mask = &disp_clk_mask; clk_mgr->base.funcs = &dce60_funcs; + + base->clks.max_supported_dispclk_khz = + clk_mgr->max_clks_by_state[DM_PP_CLOCKS_STATE_PERFORMANCE ].display_clk_khz; }
drivers/gpu/drm/amd/display/dc/resource/dce100/dce100_resource.c +9 -1
@@ -29,6 +29,7 @@#include "stream_encoder.h" #include "resource.h" +#include "clk_mgr.h" #include "include/irq_service_interface.h" #include "virtual/virtual_stream_encoder.h" #include "dce110/dce110_resource.h"
@@ -843,10 +844,17 @@ static enum dc_status dce100_validate_ba {int i;bool at_least_one_pipe = false; +struct dc_stream_state *stream =NULL ; +const uint32_t max_pix_clk_khz =max (dc->clk_mgr->clks.max_supported_dispclk_khz,400000 );for (i =0 ; i < dc->res_pool->pipe_count; i++) { -if (context->res_ctx.pipe_ctx[i].stream) + stream = context->res_ctx.pipe_ctx[i].stream; +if (stream) { at_least_one_pipe = true; + +if (stream->timing.pix_clk_100hz >= max_pix_clk_khz *10 ) +return DC_FAIL_BANDWIDTH_VALIDATE ; + } }if (at_least_one_pipe) {
drivers/gpu/drm/amd/display/dc/resource/dce60/dce60_resource.c +9 -1
@@ -34,6 +34,7 @@#include "stream_encoder.h" #include "resource.h" +#include "clk_mgr.h" #include "include/irq_service_interface.h" #include "irq/dce60/irq_service_dce60.h" #include "dce110/dce110_timing_generator.h"
@@ -870,10 +871,17 @@ static enum dc_status dce60_validate_ban {int i;bool at_least_one_pipe = false; +struct dc_stream_state *stream =NULL ; +const uint32_t max_pix_clk_khz =max (dc->clk_mgr->clks.max_supported_dispclk_khz,400000 );for (i =0 ; i < dc->res_pool->pipe_count; i++) { -if (context->res_ctx.pipe_ctx[i].stream) + stream = context->res_ctx.pipe_ctx[i].stream; +if (stream) { at_least_one_pipe = true; + +if (stream->timing.pix_clk_100hz >= max_pix_clk_khz *10 ) +return DC_FAIL_BANDWIDTH_VALIDATE ; + } }if (at_least_one_pipe) {
drivers/gpu/drm/amd/display/dc/resource/dce80/dce80_resource.c +9 -1
@@ -32,6 +32,7 @@#include "stream_encoder.h" #include "resource.h" +#include "clk_mgr.h" #include "include/irq_service_interface.h" #include "irq/dce80/irq_service_dce80.h" #include "dce110/dce110_timing_generator.h"
@@ -876,10 +877,17 @@ static enum dc_status dce80_validate_ban {int i;bool at_least_one_pipe = false; +struct dc_stream_state *stream =NULL ; +const uint32_t max_pix_clk_khz =max (dc->clk_mgr->clks.max_supported_dispclk_khz,400000 );for (i =0 ; i < dc->res_pool->pipe_count; i++) { -if (context->res_ctx.pipe_ctx[i].stream) + stream = context->res_ctx.pipe_ctx[i].stream; +if (stream) { at_least_one_pipe = true; + +if (stream->timing.pix_clk_100hz >= max_pix_clk_khz *10 ) +return DC_FAIL_BANDWIDTH_VALIDATE ; + } }if (at_least_one_pipe) {
Greg Kroah-Hartman
maintainerPATCH 847/849 drm/amd/display: use GFP_NOWAIT for allocation in interrupt handler
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aurabindo Pillai <[email protected]>
commit 72a1eb3cf573ab957ae412f0efb0cf6ff0876234 upstream.
schedule_dc_vmin_vmax() is called by dm_crtc_high_irq(). Hence, we cannot have the former sleep. Use GFP_NOWAIT for allocation in this function.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +2 -2
@@ -561,13 +561,13 @@ static void schedule_dc_vmin_vmax(structstruct dc_stream_state *stream, struct dc_crtc_timing_adjust *adjust) { - struct vupdate_offload_work *offload_work = kzalloc(sizeof(*offload_work), GFP_KERNEL); + struct vupdate_offload_work *offload_work = kzalloc(sizeof(*offload_work), GFP_NOWAIT);if (!offload_work) {drm_dbg_driver (adev_to_drm (adev),"Failed to allocate vupdate_offload_work\n" );return ; } -struct dc_crtc_timing_adjust *adjust_copy =kzalloc (sizeof (*adjust_copy),GFP_KERNEL ); +struct dc_crtc_timing_adjust *adjust_copy =kzalloc (sizeof (*adjust_copy),GFP_NOWAIT );if (!adjust_copy) {drm_dbg_driver (adev_to_drm (adev),"Failed to allocate adjust_copy\n" );kfree (offload_work);
Greg Kroah-Hartman
maintainerPATCH 848/849 drm/amd/display: Fix black screen with HDMI outputs
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Hung <[email protected]>
commit fdc93beeadc2439e5e85d056a8fe681dcced09da upstream.
[Why & How]
This fixes the black screen issue on certain APUs with HDMI, accompanied by the following messages:
amdgpu 0000:c4:00.0: amdgpu: [drm] Failed to setup vendor info
frame on connector DP-1: -22
amdgpu 0000:c4:00.0: [drm] Cannot find any crtc or sizes [drm]
Cannot find any crtc or sizes
--- drivers/gpu/drm/amd/display/dc/link/link_detection.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/display/dc/link/link_detection.c +1 -0
@@ -1141,6 +1141,7 @@ static bool detect_link_and_local_sink(s !sink->edid_caps.edid_hdmi) sink->sink_signal =SIGNAL_TYPE_DVI_SINGLE_LINK ; else if (dc_is_dvi_signal(sink->sink_signal) && + dc_is_dvi_signal(link->connector_signal) && aud_support->hdmi_audio_native && sink->edid_caps.edid_hdmi) sink->sink_signal = SIGNAL_TYPE_HDMI_TYPE_A;
Greg Kroah-Hartman
maintainerPATCH 849/849 selftests: drv-net: Reload pkt pointer after calling filter_udphdr
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amery Hung <[email protected]>
commit 11ae737efea10a8cc1c48b6288bde93180946b8c upstream.
Fix a verification failure. filter_udphdr() calls bpf_xdp_pull_data(), which will invalidate all pkt pointers. Therefore, all ctx->data loaded before filter_udphdr() cannot be used. Reload it to prevent verification errors.
The error may not appear on some compiler versions if they decide to load ctx->data after filter_udphdr() when it is first used.
--- tools/testing/selftests/net/lib/xdp_native.bpf.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
tools/testing/selftests/net/lib/xdp_native.bpf.c +4 -5
@@ -420,7 +420,6 @@ static int xdp_adjst_tail_grow_data(struct xdp_md *ctx, __u16 offset)static int xdp_adjst_tail (struct xdp_md *ctx,__u16 port) { -void *data = (void *)(long )ctx->data;struct udphdr *udph =NULL ;__s32 *adjust_offset, *val;__u32 key, hdr_len;
@@ -432,7 +431,8 @@ static int xdp_adjst_tail(struct xdp_md *ctx, __u16 port)if (!udph)return XDP_PASS ; - hdr_len = (void *)udph - data +sizeof (struct udphdr ); + hdr_len = (void *)udph - (void *)(long )ctx->data + +sizeof (struct udphdr ); key =XDP_ADJST_OFFSET ; adjust_offset =bpf_map_lookup_elem (&map_xdp_setup, &key);if (!adjust_offset)
@@ -572,8 +572,6 @@ static int xdp_adjst_head_grow_data(struct xdp_md *ctx, __u64 hdr_len,static int xdp_head_adjst (struct xdp_md *ctx,__u16 port) { -void *data_end = (void *)(long )ctx->data_end; -void *data = (void *)(long )ctx->data;struct udphdr *udph_ptr =NULL ;__u32 key, size, hdr_len;__s32 *val;
@@ -584,7 +582,8 @@ static int xdp_head_adjst(struct xdp_md *ctx, __u16 port)if (!udph_ptr)return XDP_PASS ; - hdr_len = (void *)udph_ptr - data +sizeof (struct udphdr ); + hdr_len = (void *)udph_ptr - (void *)(long )ctx->data + +sizeof (struct udphdr ); key =XDP_ADJST_OFFSET ; val =bpf_map_lookup_elem (&map_xdp_setup, &key);
Signature · 1 line
2.51.2
Hi
no regressions here on x86_64 (RKL, Intel 11th Gen. CPU)
Thanks
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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.17.y
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.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.17.8-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: a0476dc10cb160082a35b307f8dbfe4a066d41ec
* git describe: v6.17.6-886-ga0476dc10cb1
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.17.y/build/v6.17.6-886-ga0476dc10cb1
## Test Regressions (compared to v6.17.6-36-g7914a8bbc909)
## Metric Regressions (compared to v6.17.6-36-g7914a8bbc909)
## Test Fixes (compared to v6.17.6-36-g7914a8bbc909)
## Metric Fixes (compared to v6.17.6-36-g7914a8bbc909)
## Test result summary
total: 126378, pass: 106987, fail: 4241, skip: 15150, xfail: 0
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 139 passed, 0 failed
* arm64: 57 total, 54 passed, 3 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 33 passed, 1 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, 48 passed, 1 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
* 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 Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.y
and the diffstat can be found below.thanks,
greg k-h
6.17.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.17.8-rc1rv-ga0476dc10cb1
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.2.1 20250813, GNU ld (GNU Binutils) 2.45.0) #1 SMP PREEMPT_DYNAMIC Tue Nov 11 19:30:54 JST 2025
Thanks
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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.
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.17.8-rc1-ga0476dc10cb1 #128 SMP PREEMPT_DYNAMIC Tue Nov 11 12:21:46 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
6.17.8-rc1 built and run on x86_64 test system with no errors or regressions:
Thanks,
Slade
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.17:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.17.8-rc1-ga0476dc10cb1
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
Am 11.11.2025 um 01:32 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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]
Compiled and booted 6.17.8-rc1+
NO new regression and issue from dmesg
As per dmidecode command.
Version: AMD Ryzen 3 3250U with Radeon Graphics
Processor Information
Socket Designation: FP5
Type: Central Processor
Family: Zen
Manufacturer: Advanced Micro Devices, Inc.
ID: 81 0F 81 00 FF FB 8B 17
Signature: Family 23, Model 24, Stepping 1
--
software engineer
rajagiri school of engineering and technology
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.y
and the diffstat can be found below.thanks,
greg k-h
Verified if you drop
[PATCH 6.17 145/849] bpftool: Add CET-aware symbol matching for x86_64 architectures or add 70f32a10ad423fd19e22e71d05d0968e61316278 everything builds and runs.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.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, 11 Nov 2025 09:32:50 +0900 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for arm and loongarch64:
Thanks!
Cheers,
Miguel
Hiii greg,
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.y
and the diffstat can be found below.thanks,
greg k
Build and Boot Report for 6.17.8
The kernel version 6.17.8-rc1 was built and boot-tested using qemu-x86_64 and qemu-arm64 with the default configuration (defconfig). The build and boot processes completed successfully, and the kernel operated as expected in the virtualized environments without any issues.
Build Details :
Builds : arm64, x86_64
Kernel Version: 6.17.8-rc1
Configuration : defconfig
Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit : a0476dc10cb160082a35b307f8dbfe4a066d41ec
Best regards,
Dileep Malepu
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.8 release. There are 849 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, 13 Nov 2025 00:43:57 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.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.17.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