summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
4 daysdrm/amd/display: Reuse mpc401_read_mpcc_state on dcn42, dcn60Matthew Stewart
This will populate lut3d_mode, lut3d_size, and shaper_lut_mode so that they have valid values for dcn10_log_hw_state. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Attach retained DMUB windows to PSP reloadTony Cheng
Core2 init never supplied DMUB window params, so PSP reload failed closed before the builder could name the framebuffers dmub_srv already retained. When the caller does not pass hw params, copy the retained window table, soc_fb_info, and psp_version onto the declarative params and point PSP_RELOAD_DMUB_FW at that copy. Require a full window count before execute. A zero Initialize DCN command still leaves the build unsupported, so core2_hardware_init does not run the head. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Call the init BLS from Core2 hardware initTony Cheng
Why: Core2 hardware init still delegated to legacy hwseq. The init head is now a BLS, and a failed or unsupported build must not execute it or fall back. How: core2_hardware_init builds DCN_DECL_INITIALIZATION and executes only on BLS_BUILD_SUCCESS. A zero Initialize DCN command stays unsupported. A non-zero test command type can succeed and execute. Product DC has no DMUB window params and no opcode, so this path does not reload or halt firmware. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Scaffold PSP reload, ABI query, and Initialize DCNTony Cheng
Why: The init head stopped at firmware halt. The flow still needs a PSP reload, an ABI query, and an Initialize DCN entry before Core2 can call the sequence. How: Keep DMUB_GPINT_SEND_AND_WAIT valid beside DMUB_HALT_FW. Append PSP_RELOAD_DMUB_FW through dmub_srv_hw_init, a GET_FW_VERSION GPINT into dmub_abi.fw_version, and a QUERY_FEATURE_CAPS inbox command whose reply is copied into dmub_abi.feature_caps. Emit DMUB_INITIALIZE_DCN with a zero command type and keep the walk UNSUPPORTED so an undefined opcode cannot succeed. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Name the init STOP_FW entry DMUB_HALT_FWTony Cheng
Why: The init head still emits a raw GPINT transport verb for firmware halt. The initialization flow asks for a dedicated DMUB_HALT_FW mnemonic. How: Add DMUB_HALT_FW, emit it from the DCN401 init sequence with STOP_FW params, and dispatch it through the existing GPINT helper without checking the ack. The walk still returns UNSUPPORTED. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Scaffold DMUB STOP_FW on the init BLSTony Cheng
Why: This is still builder scaffolding, not a live init path. The legacy hwseq is still in use; emitting a halt entry does not cut initialization over. How: Append DMUB_GPINT_SEND_AND_WAIT to the DCN401 init sequence with DMUB_GPINT__STOP_FW and param 0. Preflight the GPINT transport before any append, and point the raw response at the init out-target. The completed walk still returns UNSUPPORTED. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Scaffold generic DMUB GPINT BLS dispatchTony Cheng
Why: This is still builder/executor scaffolding, not a live init path. The legacy hwseq is still in use; adding GPINT dispatch does not cut initialization over. How: Register DMUB_GPINT_SEND_AND_WAIT with flat command, parameter, and raw-response fields. dc2_bls_execute takes struct dc2 and dispatches gpint_send_and_wait on the DMUB messenger. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Scaffold DMUB inbox BLS dispatchTony Cheng
Why: This is still builder/executor scaffolding, not a live init path. The legacy hwseq is still in use; adding inbox dispatch does not cut initialization over. How: Dispatch DMUB_SEND_DMCUB_CMD through the DMUB messenger. The messenger copies the builder-built command and forwards the entry's wait type without reading the payload. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Add Core 2 Workaround Manager scaffoldingTony Cheng
[Why] Core needs a Layer-2 post-build stage that can edit a built BLS list for errata before the Executor runs. Inline workarounds stay scattered until that manager exists. [How] Add an empty-registry Workaround Manager over block_sequence_state. Keep the restore image in BSS so the kernel frame stays small, and reject growth past MAX_HWSS_BLOCK_SEQUENCE_SIZE. Name the committed state field current_state so the Linux current macro does not expand it. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Scaffold Core2 BLS builder and executorTony Cheng
Why: This is builder/executor scaffolding, not a live init path. The legacy hwseq is still in use; switching onto this sequence would not pass. How: Keep an explicit dcn401_dc1_init_sequence, validate callbacks inline, then populate LEGACY_CLK_MGR_* and DCCG_INITIALIZE_CLOCKS. The completed walk still returns UNSUPPORTED so the scaffold cannot be treated as working init. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Add Core 2 initialization BLS scaffoldingTony Cheng
why: Core2 initialization cannot safely cut over until the architected DMUB halt, PSP reload, DMUB Initialize-DCN, ABI resolution, and symmetric teardown contracts exist. The remaining operations do not yet have DAL component contracts, so this parent must not cut the selectable lifecycle path over. how: Keep the existing legacy lifecycle behavior and introduce fail-closed Builder/Executor scaffolding over struct block_sequence as peer directories. Encapsulate dispatch behind bls_builder_create and a per-ASIC vtable, emit one explicit DCCG_INITIALIZE_CLOCKS BLC operation, and reject incomplete initialization and missing dispatch targets. Reviewed-by: Jun Lei <jun.lei@amd.com> Signed-off-by: Tony Cheng <tony.cheng@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysMerge branch 'io_uring-7.4' into for-nextJens Axboe
* io_uring-7.4: io_uring: keep the drain active when a deferred drain request is started
4 daysdrm/radeon/vce1: enable the VCE trap interruptMatheus Tagliari
vce_v2_0 sets VCE_SYS_INT_TRAP_INTERRUPT_EN in VCE_SYS_INT_EN so that the VCE_CMD_TRAP emitted after each fence raises an interrupt. The VCE1 code, used by SI and Trinity/Richland, never does, and amdgpu's vce_v1_0 does (mmVCE_SYS_INT_EN, 0x8340, i.e. byte offset 0x20d00 on SI). VCE fences are therefore never processed from the interrupt handler and are only noticed when a fence wait times out. Enable the trap interrupt at the end of vce_v1_0_start(). CIK also goes through vce_v1_0_start() (via vce_v1_0_init() and kv_dpm), but has VCE_SYS_INT_EN at a different offset and already enables it in vce_v2_0_resume(), so only do it for VCE1, i.e. before CHIP_BONAIRE. Observed on a Radeon HD 8870M (Cape Verde, 1002:6821) with VCE firmware 50.0.1, Mesa 25.0.7 radeonsi and ffmpeg h264_vaapi on Debian 6.12.113: - Stock driver: the encode hangs after a few dozen frames ("ring 0 stalled", "ring 3 stalled", "GPU lockup"), and the reset does not recover ("failed VCE resume (-22)", "ring 0 test failed"). - With the hardware ring semaphores of the VCE ring disabled as a workaround, the hang is gone but encoding runs at 3.9 fps (~256 ms per frame), consistent with fences being noticed only by timeouts. - With this series: 640x360 for 1800 frames, 1280x720 for 900 frames and 1920x1080 for 600 frames, all in real time with no decode errors, and 191 fps at 720p / 91 fps at 1080p unthrottled. Four runtime suspend/resume cycles with an encode in between also worked. No lockup, reset, WARNING or error in the kernel log, with DPM and runtime PM enabled. Trinity/Richland takes the same path and is covered by the previous patch, but I have no such hardware to test. CIK is not affected. Fixes: a918efab631a ("drm/radeon: add VCE 1.0 support v4") Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Matheus Tagliari <mptagliari@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/radeon: process the VCE interrupt on SI and TrinityMatheus Tagliari
radeon_vce_fence_emit() ends every VCE fence with VCE_CMD_TRAP, which raises the VCE trap interrupt (IH src_id 167). cik_irq_process() handles it by calling radeon_fence_process() for the matching VCE ring, but si_irq_process() and evergreen_irq_process(), which serve the other ASICs with VCE1 (SI and Trinity/Richland), have no case for it. Add the same handling. The trap interrupt is not enabled on these ASICs yet, so this does not change behaviour on its own; the next patch enables it. The SI part was tested together with the next patch. The Trinity part mirrors the CIK and SI code and has not been tested on Trinity/Richland hardware. Fixes: a918efab631a ("drm/radeon: add VCE 1.0 support v4") Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Matheus Tagliari <mptagliari@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: clear vm pts upon a vm->generation mismatchShahyan Soltani
Upon a vm->generation mismatch, the evicted pagetables are iterated through, resetting their state, and moved to their preferred domain. However validation doesn't process the necessary step of clearing the pagetables' garbage data. Clear the vm page tables through the kernel.evicted loop upon a vm->generation mismatch. This ensures any garbage data is wiped. The new vm->generation value is assigned after the loop. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Shahyan Soltani <shahyan.soltani@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: re-enable GFXOFF for compute on GFX12Harkirat Gill
Commit 2affe2bbc997 ("drm/amdgpu: disable gfxoff with the compute workload on gfx12") disabled GFXOFF whenever a user-mode compute queue exists, as a workaround for an OpenCL test failure. The MES firmware issue behind that failure has since been addressed, so the workaround is no longer required. Without this change, idle inference servers that hold a context for hours never let the graphics block power down, costing roughly 3-4% reported GPU activity and ~3 W per GPU at idle. Measured on gfx1200 with an idle HIP process holding one stream and two resident KFD queues: before: VDDGFX 695 mV, GPU load 2%, ~9-10 W after: VDDGFX 35 mV, GPU load 0%, ~8 W (idle baseline) The resident queue count is unchanged in both cases; only GFXOFF availability differs. The ocltst runtime suite (40 tests) passes with and without this change. Fixes: 2affe2bbc997 ("drm/amdgpu: disable gfxoff with the compute workload on gfx12") Signed-off-by: Harkirat Gill <harkirat.gill@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu/ras: Select EEPROM ops based on PSP IP versionCe Sun
Replace RAS EEPROM feature-status checking with PSP IP version based EEPROM ops selection. Determine FW/DRV EEPROM support according to the PSP IP version instead of querying RAS_CORE_FW_FEATURE_BIT__RAS_EEPROM. Signed-off-by: Ce Sun <cesun102@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: evict the queues only once for CRIU PROCESS_INFOJesse Zhang
criu_process_info() evicts the queues of the process on every call, and each kfd_process_evict_queues() increments qpd->evicted, but CRIU UNPAUSE restores them only once. After PROCESS_INFO twice and UNPAUSE the queues stay evicted for good. On navi31, a barrier-AND packet on an HSA queue completes after PROCESS_INFO + UNPAUSE, but times out after PROCESS_INFO, PROCESS_INFO, UNPAUSE. The error path has a related problem: when kfd_process_evict_queues() itself fails, it has already rolled back its partial eviction, and the kfd_process_restore_queues() in the error path restores once more. Evict only when the queues are not paused yet, and on errors only undo an eviction done by this call. The barrier now completes after any number of PROCESS_INFO calls followed by UNPAUSE. Fixes: cd9f79103003 ("drm/amdkfd: CRIU Implement KFD unpause operation") Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysMerge tag 'fuse-update-7.4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse Pull fuse updates from Miklos Szeredi: - Add dax backing and extent map support for famfs (John Groves, Miklos) - Support large folios (Joanne) - Add selftests and documentation of caching behavior (Luis Henriques) - Add FUSE_SYNCFS request (Jimmy Zuber) - Convert readdir cache to use folios (Tal Zussman) - Lots of bug fixes * tag 'fuse-update-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse: (53 commits) fuse: handle extent map files in fuse_passthrough_fadvise() fuse: resolve extent maps in O(1) when possible fuse: add support for striped backing fuse: add extent map I/O support fuse: add extent map data structure fuse: add support for opening dax device as backing fuse: support opening 64 bit backing ID fuse: support 64 bit, server allocated backing ID fuse: add helpers for EIO return value with kernel message dax: use READ_ONCE() in dax_holder() dax: add fsdev_dax_from_file() fuse: fix copy_file_range reply handling race virtiofs: validate fixed-output response length fuse: don't d_drop() before d_splice_alias() virtio_fs: read the vring size under virtio_fs_mutex in ->get_tree fuse: validate folio state before pipe_buf_try_steal() in fuse_try_move_folio() fuse: rename fuse_direct_io() to fuse_do_direct_io() fuse: Forward vfs_fadvise to backing_file in passthrough mode selftests/fuse: add the missing FUSE_HAS_SYNCFS privilege test fuse: don't launder folios of a bad inode ...
4 daysdrm/amdgpu: drop the gang leader reference when freeing gang jobsJesse Zhang
Every job of a gang except the leader holds a reference to the scheduled fence of the leader in job->gang_submit. Only amdgpu_job_free(), used for jobs which never ran, drops it, so for every gang submission which completes the scheduler fence of the leader, and with it its hardware fence, is leaked. amdgpu_job_free() in turn checks for the leader only after drm_sched_job_cleanup() cleared the scheduler fence, so a leader freed there drops a reference it never took. On navi31, 100 submissions of a GFX + COMPUTE gang grow the slab cache drm_sched_fence is merged into by 60 to 180 objects each time, while 100 GFX only submissions don't. Use amdgpu_job_free() for the jobs the scheduler frees too, and check for the gang leader there before drm_sched_job_cleanup() clears the scheduler fence. As the scheduler clears the entity of the jobs it picked up, check for the scheduler fence instead to tell whether the job needs cleaning up. Keep freeing the remaining IBs with amdgpu_job_free_resources() after drm_sched_job_cleanup(), so that it frees them with the hardware fence or right away and not with the scheduler fence, which nobody signals for jobs aborted after drm_sched_job_arm(), like a CS returning -EAGAIN. v2: unify amdgpu_job_free() and amdgpu_job_free_cb() (Christian), don't free the remaining IBs with the scheduler fence v3: drop the comments (Christian) v4: free the IBs with amdgpu_job_free_resources() again (Christian) Fixes: 68ce8b242242 ("drm/amdgpu: add gang submit backend v2") Fixes: f7d66fb2ea43 ("drm/amdgpu: cleanup scheduler job initialization v2") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: don't wait for the SPM VMID's jobs under the VMID manager lockJesse Zhang
amdgpu_vmid_free_spm() waits for the jobs of the reserved VMID while holding the VMID manager lock of the hub, which every VMID grab on the hub takes as well. Freeing the reservation, by UNRESERVE_VMID or when the VM is destroyed, so stalls the kernel queue submissions of every process on the GFXHUB until those jobs completed, or until the job timeout if one of them hangs. A full GPU reset even deadlocks, since amdgpu_vmid_reset_all() needs the lock before the scheduler is started again to signal the jobs. On navi31, with a GFX job of the reserving process that waits for 1s, an unrelated process' SDMA NOP takes 0.8s instead of no time when the VMID gets unreserved meanwhile. Wait for the submissions of the VM in the callers instead, through the fences of the root PD, before taking the lock. Use DMA_RESV_USAGE_READ, which covers the command submissions but not the KFD eviction fence. UNRESERVE_VMID keeps the root PD reserved while waiting and freeing the VMID, so that no new submission can grab the VMID in between, and only waits when the VM actually has the VMID reserved. v2: wait for the root PD's reservation object in the callers instead of accessing id->active without the lock (Christian) Fixes: ba56c52af8fd ("drm/amdgpu: bind the SPM VMID's page table to the reserving VM") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysio_uring: keep the drain active when a deferred drain request is startedJens Axboe
ecb6817b769f ends the drain when the dispatched drain request has posted its CQE and nothing else is deferred. But the deferred list is processed in between, and if the request it starts is itself a drain request, the drain is over before that one has even run. A request submitted after that point then runs ahead of it: 1. P0 in flight, D1 and D2 (both IOSQE_IO_DRAIN) deferred behind it 2. P0 completes, D1 is started 3. D1 completes, drain_done is set, D2 is started, the list is empty 4. IO_RING_F_DRAIN_ACTIVE is cleared with D2 still in flight Anything submitted now bypasses the drain. The same happens with D2 as the head of a link, as those aren't tracked in ->drain_req at all. Have io_queue_deferred() report whether it started a drain request, and don't end the drain if it did. Starting non-drain requests and ending it is still fine, they were only waiting on the drain request that just completed. Fixes: ecb6817b769f ("io_uring: end the drain when the drain request completes") Reported-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://lore.kernel.org/io-uring/20261027043323.98916-1-kmehltretter@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
4 daysdrm/amdkfd: send SMI process and VM fault events only to allowed clientsJesse Zhang
Commit 92a8dba246d3 ("drm/amdkfd: fix SMI event cross-process information leak") made the VMFAULT and PROCESS_START/END SMI events carry the pid of the process they are about, so that kfd_smi_ev_enabled() only passes them to clients of that process and to privileged clients. Commit 1142738572ef ("drm/amdkfd: Fix SMI event PID reporting for containers") then switched kfd_smi_event_add() to take a task and passed NULL for these events, i.e. pid 0, which every client receives again. On navi31, an unprivileged SMI client (uid 1000) subscribed to PROCESS_START/END sees root running rocminfo: event: c 223a9 rocminfo event: d 223a9 rocminfo The same commit also made the filter compare PIDs of different namespaces: the client stores its PID in its own namespace and events use the PID of the task in the task's namespace, so a client that is PID 1 in one container receives the events of PID 1 in another. And an exited task has no PID in its namespace anymore, which gives pid 0 for PROCESS_END. Match clients by global TGID, which is unique and stays valid after the task exited, and keep showing the namespace PID in the event text. Pass the TGID of the process for the process and VM fault events again. With this the unprivileged client gets nothing, a root client still gets both events, and an unprivileged client that is PID 1 in its own PID namespace no longer gets the events of rocminfo running as PID 1 in another one. v2: rename the pid of the clients and of the filter to tgid (Felix) Fixes: 1142738572ef ("drm/amdkfd: Fix SMI event PID reporting for containers") Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: Do not use internal implementation of tolower()Andy Shevchenko
ctype.h provides tolower() macro specifically for the cases that might be architecture-optimised. Using __tolower(), which is internal implementation, needs a good justification, as this driver is the only user of that and there is no evidence it's required. Note, currently it's no difference as the macro always defined to the internal implementation, but it might change in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: Simplify amdgpu_ring_initTvrtko Ursulin
(Too) many times I grepped the codebase trying to figure out who sets adev->gpu_sched[hw_ip][hw_prio].num_scheds and this time I decided to make this greppable by avoding the fun pointer games. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: Bump KFD ioctl version - SVM no accessDavid Yat Sin
This is not strictly a change in the IOCTL API. This version bump is meant to indicate to user mode the presence of a number of changes and fixes that enable setting the SVM no access attribute. In particular, it indicates the presence of these commits: commit b96f26104946 ("drm/amdkfd: Unmap svm range from GPU set to no-access") commit 093cf8842ace ("drm/amdkfd: Fix always mapped range mapping to all ACCESS GPUs") Signed-off-by: David Yat Sin <David.YatSin@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: Size the vm_pte_scheds array by maximum number of SDMA instancesTvrtko Ursulin
The array is populated from a loop capped by adev->sdma.num_instances so it makes sense to size it using AMDGPU_MAX_SDMA_INSTANCES and save some memory. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysMerge tag 'vfs-7.4-rc1.keyring' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs keyring updates from Christian Brauner: "The kernel has two keyrings that userspace fills with X.509 certificates at boot: .fs-verity for fs-verity built-in signatures and .dm-verity for dm-verity root hash signatures. Neither is linked into any process keyring. Hence, request_key() and KEYCTL_SEARCH can't find them. The only way for userspace to identify them is to read their serial number out of /proc/keys. That is not just a large file often the names can also be reused and appear multiple times which allows forging these keyrings. This adds two fixed special key ids, KEY_SPEC_DM_VERITY_KEYRING and KEY_SPEC_FS_VERITY_KEYRING next to KEY_SPEC_BPF_KEYRING. The latter went in through bpf-next this merge window. lookup_user_key() resolves the fixed key ids to the two keyrings. So userspace can add a dm-verity (fixed keyring id: -10) certificate with keyctl padd asymmetric "" -10 < cert.der and seal the keyring with keyctl restrict_keyring -10 without looking anything up first" * tag 'vfs-7.4-rc1.keyring' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: Documentation: keys: document IDs added since KEY_SPEC_REQKEY_AUTH_KEY keys: add KEY_SPEC_FS_VERITY_KEYRING keys: add KEY_SPEC_DM_VERITY_KEYRING
4 daysdrm/amdgpu: Size the buffer_funcs array by maximum number of SDMA instancesTvrtko Ursulin
The array is populated from a loop capped by adev->sdma.num_instances so it makes sense to size it using AMDGPU_MAX_SDMA_INSTANCES and save some memory. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: remove unused cgs register accessor typedefsOmokefe Emmanuel Onanaroghene
kernel-doc reports prototype mismatches for the cgs register accessor typedefs, e.g.: drivers/gpu/drm/amd/include/cgs_common.h:89: expecting prototype for cgs_read_register(). Prototype was for uint32_t() instead Each of the four typedefs is used exactly once, as the type of a struct cgs_ops member, so they are merely an unnecessary layer of indirection. Drop the typedefs along with their kernel-doc comments and write the function pointer types directly in struct cgs_ops. While at it, drop the unused cgs_handle_t and cgs_get_firmware_info typedefs, and document the members of struct cgs_firmware_info. Reviewed-by: Christian König <christian.koenig@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/all/981f01e1-0c3b-4854-9d72-8bf22af9fc64@amd.com/ Signed-off-by: Omokefe Emmanuel Onanaroghene <emmaonana18@gmail.com> Tested-by: Arnaud Bonnet <abo@medichon.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: validate SRAT subtables before parsingJiale Yao
The KFD SRAT walker reads the first subtable length without checking that a header is present and trusts subsequent lengths when accessing CPU and generic affinity records. Invalid firmware lengths can therefore cause out-of-bounds reads. Validate the table header, every generic subtable range, and each supported typed record before reading its fields. Fixes: ddec8d3be0f8 ("drm/amdkfd: add ACPI SRAT parsing for topology") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/pm: preserve committed OD features for SMU 14.0.2Kevin Wang
PMFW treats FeatureCtrlMask as the complete set of active OD features. Uploads containing only newly edited bits can drop earlier settings. Fix the OD state handling to: - preserve committed features across later commits - keep fan-curve and legacy-fan bits mutually exclusive - keep staged OD settings out of power-cap writes - update cached state only after successful uploads - clear restored features only after they return to defaults - restore PPT for the current AC/DC source after resume Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3625 Signed-off-by: Kevin Wang <kevin.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/pm: preserve committed OD features for SMU 13.0.0/13.0.7Kevin Wang
PMFW treats FeatureCtrlMask as the complete set of active OD features. Uploads containing only newly edited bits can drop earlier settings. Fix the OD state handling to: - preserve committed features across later commits - keep staged OD settings out of power-cap writes - update cached state only after successful uploads - clear restored features only after they return to defaults - restore PPT for the current AC/DC source after resume Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3625 Signed-off-by: Kevin Wang <kevin.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Tested-by: José Miguel Sarasola <alosarjos@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amd/display: Initialize missing TD-LUT programming inputsAvi Weiss
dml_core_mode_programming() memsets (clears) its scratch structure before calculating TD-LUT settings, but does not initialize tdlut_mpc_width_flag or is_gfx11. Both inputs therefore remain false regardless of the plane configuration which can result in incorrect calculations. Initialize both fields using the same sources as the mode support path (now both paths are aligned). Fixes: 70839da63605 ("drm/amd/display: Add new DCN401 sources") Signed-off-by: Avi Weiss <thnkslprpt@gmail.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: remove suspend/resume DRM clients during GPU recoveryPrike Liang
drm_client_dev_suspend()/resume() wait for clientlist_mutex, the fbdev damage work and the console lock. Their holders create, pin and lock the framebuffer BO or do blocking atomic commits, and the userq restore worker takes userq_mutex with BO reservations held, so GPU recovery ends up depending on userq_mutex and eviction fences: &dev->clientlist_mutex --> &userq_mgr->userq_mutex --> &reset_domain->sem Only notify the DRM clients from system suspend/resume. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: drop the unused firmware loading mutexPrike Liang
adev->firmware.mutex was added to serialize amdgpu_ucode_init_bo() between the PSP and powerplay firmware loaders. Powerplay no longer loads firmware through it, so the mutex no longer protects anything: its only users are psp_hw_init() and psp_resume(), which the IP init, resume and reset sequences already serialize. psp_hw_init() still allocates and reserves the PSP ring, TMR and TA buffers with it held, and GPU recovery takes the same mutex in psp_resume() while holding reset_domain->sem, so lockdep reports: &adev->firmware.mutex --> &userq_mgr->userq_mutex --> &reset_domain->sem Remove the mutex instead of keeping a lock that recovery shares with an allocating path. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: split vram_pages of SVM ranges prefetched without a GPU mappingJesse Zhang
When an SVM range is split, svm_range_split_pages() gives the new range the number of VRAM pages counted in its part of the dma_addr arrays and subtracts it from the old range. Pages migrated to VRAM by a prefetch have no dma_addr entries until the range is mapped on a GPU, e.g. with no ACCESS attribute, or with XNACK off before the delayed restore worker mapped it, so the new range gets 0 and the old one keeps the count for both. Migrating the parts back to system memory then gets the accounting wrong: the old part keeps a VRAM page count after all its pages are gone, so its svm_bo is never freed, and the new part underflows. On navi31, as an unprivileged process: prefetch 4 MiB to the GPU, prefetch the upper 2 MiB and then the lower 2 MiB back to system memory: Recorded vram pages(0x0) should not be less than migration pages(0x200). WARNING: ../amdkfd/kfd_migrate.c:922 at svm_migrate_vram_to_ram+0xbdc/0xcd0 [amdgpu] and /sys/class/kfd/kfd/proc/<pid>/vram_<gpu_id> stays at 4194304 until the process exits. Without dma_addr arrays, the split is still exact when the old range is completely in VRAM, which is what a prefetch of the whole range leaves. Give the new range all its pages in that case. The warning is gone and the VRAM usage drops back to 0. This doesn't cover a range that is only partly in VRAM without dma_addr arrays, e.g. after a partial migration, since svm_migrate_ram_to_vram() only counts the pages it actually migrated. That would need VRAM residency to be tracked per page independently of dma_addr. v2: - Rename counted to has_dma_addr and compare against old->npages (Philip) - Mention the XNACK off case and the partial migration limitation (Philip) Fixes: 006ad514a50c ("drm/amdkfd: Use partial hmm page walk during buffer validation in SVM") Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: reject CS chunks too large for kvmalloc()Jesse Zhang
The CS ioctl copies every chunk with vmemdup_array_user() before it looks at it, for whatever length_dw userspace gives. kvmalloc() warns about allocations above INT_MAX when called without __GFP_NOWARN, so any process with the render node can trigger a warning. On navi31, a CS with a chunk of length_dw 0x20000000 returns -ENOMEM after: WARNING: mm/slub.c:6841 at __kvmalloc_node_noprof+0x5a5/0x7d0 Reject such chunks with -EINVAL before trying to copy them. Fixes: 2098105ec65c ("drm: drop drm_[cm]alloc* helpers") Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: pass watchpoint addresses to MES for GFX12David Belanger
Update SET_SHADER_DEBUGGER packet with tcp_watch_addr_lo/hi fields. Remove direct TCP_WATCH register writes from set_address_watch(). v2: Add missing code for mes_v12_1.c Assisted-by: claude-code:claude-sonnet-4 Signed-off-by: David Belanger <david.belanger@amd.com> Reviewed-by: Michael Chen <michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: pass watchpoint addresses to MES for GFX11David Belanger
Update SET_SHADER_DEBUGGER packet with tcp_watch_addr_lo/hi fields. Remove direct TCP_WATCH register writes from set_address_watch(). Assisted-by: claude-code:claude-sonnet-4 Signed-off-by: David Belanger <david.belanger@amd.com> Reviewed-by: Michael Chen <michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysKEYS: Verify the key identity in __key_unlink_beginJarkko Sakkinen
When two keys have identical type and description, linking the second key replaces the first in a keyring. However, attempting to unlink the first key (no longer in the keyring) unlinks the second key. This happens because __key_unlink_begin() calls assoc_array_delete() with &key->index_key, matching only on type and description rather than the key's identity. Example: keyctl new_session >/dev/null keyctl newring ring_a @s keyctl newring ring_b @s A=$(keyctl add user A ss %:ring_a) B=$(keyctl add user A qq %:ring_b) keyctl newring R @s keyctl link $A %:R keyctl link $B %:R keyctl unlink $A %:R keyctl show Verify the key identity before unlinking, and return -ENOENT on mismatch, instead of unlinking the key with the wrong identity. Cc: stable@vger.kernel.org Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reviewed-by: David Howells <dhowells@redhat.com> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Link: https://lore.kernel.org/r/20261020174325.2229448-4-jarkko@kernel.org Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
4 daysKEYS: Reject descriptions larger than KEY_MAX_DESC_SIZEJarkko Sakkinen
KEY_MAX_DESC_SIZE includes the trailing NULL character. Descriptions generated from payloads and in-kernel paths bypass the userspace limit. Reject descriptions at or above KEY_MAX_DESC_SIZE with -EINVAL at the following sites: - key_alloc(): before quota calculation - __key_create_or_update(): before key_set_index_key() - keyring_search(): before match_preparse - request_key_and_link(): before match_preparse - request_key_rcu(): before check_cached_key() Cc: stable@vger.kernel.org Fixes: f771fde82051 ("keys: Simplify key description management") Reviewed-by: David Howells <dhowells@redhat.com> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Link: https://lore.kernel.org/r/20261020174325.2229448-3-jarkko@kernel.org Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
4 daysKEYS: Expand key->{datalen,quotalen} to unsigned intJarkko Sakkinen
In key_alloc() and key_payload_reserve(), key->quotalen and key->datalen can receive values larger than USHRT_MAX. Example: keyctl new_session >/dev/null owner=$(keyctl newring owner @s) keeper=$(keyctl newring keeper @s) for ((i=0; i<16384; i++)); do key=$(keyctl add user "k$i" x "$keeper") keyctl link "$key" "$owner" done awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users keyctl clear "$owner" awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users Because key->datalen wraps around 65535, the quota refunded upon clearing is truncated, causing quota bytes to leak in /proc/key-users. Change the types of key->datalen and key->quotalen from unsigned short to unsigned int so that they can carry the full payload length without truncation. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: David Howells <dhowells@redhat.com> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Link: https://lore.kernel.org/r/20261020174325.2229448-2-jarkko@kernel.org Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
4 daysdrm/amd/display: take a runtime PM reference only when a CRTC turns onLuigi Lauro
amdgpu_dm_commit_streams() takes a runtime PM reference for every active CRTC that needs a modeset and has a new stream, but amdgpu_dm_atomic_commit_tail() drops one only for each CRTC that goes from active to inactive. A modeset of a CRTC that is already active (a mode change, or anything else that needs a full modeset) therefore leaks one reference. Once that has happened, the usage count no longer returns to zero with every CRTC off, and the device cannot runtime suspend again until reboot. The two also disagree the other way when a CRTC turns on without a stream ("Failed to create new stream"): no reference is taken, but one is dropped when it turns off. Take the reference in the loop that counts the disabled CRTCs, on the mirror condition: when the CRTC goes from inactive to active, which is what the commit that added it intended ("every time we enable a previously disabled CRTC"). Each active CRTC then holds exactly one reference. Tested on an RX 9070 XT (Navi 48) over OCuLink, with the change backported to 7.2.9: an unplugged connector forced on, then mode A on a CRTC, mode B on the same active CRTC, and the CRTC off, three rounds in a row. The usage count rose by 3 with the stock module, by 0 with this patch, and by 3 again after reloading the stock module. Fixes: 97028037a38a ("drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5951 Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Luigi Lauro <luigi.lauro@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdgpu: guard VCE/UVD sched entity teardown on failed probeOlivier Kaloudoff
Since commit 037b98a2312e ("drm/amdgpu: move UVD and VCE sched entity init after sched init"), drm_sched_entity_init() for the VCE and UVD kernel entities runs in the scheduler-init phase, well after the IP-block sw_init phase has allocated the vcpu_bos. If probe fails between the two phases, amdgpu_device_fini_sw() still runs the per-IP sw_fini callbacks for blocks that did complete sw_init. Both amdgpu_vce_sw_fini() and amdgpu_uvd_sw_fini() then call drm_sched_entity_destroy() on an entity that was never initialized: entity->rq is NULL and drm_sched_entity_flush() dereferences it, oopsing in whatever context drove the failed probe. The hole was latent-but-safe until commit 2df5efb45425 ("drm/sched: Remove redundant entity->rq initialization and checks") removed the if (!entity->rq) early return that commit 1decbf6bb0b4 ("drm/sched: Fix entities with 0 rqs.") had put in drm_sched_entity_flush(), on the grounds that entity->rq can never be NULL. That holds only for entities that completed drm_sched_entity_init() — not for the never-initialized entity this teardown path reaches. Observed on real hardware: MI50 (Vega20, VCE 4.0 / UVD 7.2) behind a Thunderbolt link — a pciehp presence/link-change event re-probes the device; when the re-probe fails (-EINVAL here), the cleanup path NULL-derefs inside drm_sched_entity_flush() in the pciehp IRQ thread and takes the whole machine down (panic_on_oops, EFI pstore capture). Reproduced twice on 7.3-rc5, 2026-10-06 and 2026-10-09, identical signature; the faulting instruction is `mov (%rax),%r15` on rax = entity->rq == NULL, i.e. `sched = entity->rq->sched`: BUG: kernel NULL pointer dereference RIP: drm_sched_entity_flush+0x34/0x2d0 [gpu_sched] drm_sched_entity_destroy amdgpu_vce_sw_fini vce_v4_0_sw_fini amdgpu_device_fini_sw ... pciehp_configure_device pciehp_handle_presence_or_link_change Guard the entity teardown on entity->rq, which is set only by drm_sched_entity_init(). amdgpu_ring_fini() already self-guards via the rings[] registration, and the vcpu_bo/firmware cleanup still runs as before. v2: retarget Fixes: at commit 2df5efb45425 ("drm/sched: Remove redundant entity->rq initialization and checks") — the !entity->rq check from commit 1decbf6bb0b4 ("drm/sched: Fix entities with 0 rqs.") that Alex pointed to was removed by it in the 7.3 window, so this is a regression there, not a pre-existing hole. Fixes: 2df5efb45425 ("drm/sched: Remove redundant entity->rq initialization and checks") Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: stop restore retries on device unplugOlivier Kaloudoff
amdgpu_amdkfd_restore_userptr_worker() and svm_range_restore_work() reschedule themselves when validation fails with evicted objects pending. After a surprise removal the restore paths fail with -ENODEV permanently, so rescheduling just spins the worker uselessly until cancel_delayed_work_sync() in fini finally stops it - which can take a while, since process teardown itself is delayed by the dead device. Treat -ENODEV as terminal in both workers. Cc: Xiaogang Chen <xiaogang.chen@amd.com> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: tear down KFD processes before early fini_sw on disconnectOlivier Kaloudoff
On surprise removal, amdgpu_device_fini_hw() calls amdgpu_amdkfd_device_fini_sw() when pci_dev_is_disconnected() is true. fini_sw frees kfd.dev, but KFD processes may still be alive and hold references to it: kfd_process_destroy() dereferences kfd.dev via kfd_processes_remove(), and svm_range_list_fini() / kfd_process_free_outstanding_kfd_bos() touch per-device SVM state. The kfd_processes_count wait only happens later in kgd2kfd_teardown_processes(), called from the top-half remove path well after fini_sw. In the observed failure the killed KFD process (SIGBUS on unplug) stuck in D state on its exit path, so kfd_processes_count never drained and the PCIe removal thread wedged permanently in cond_resched(), producing soft-lockup and hung-task splats. Tear KFD processes down before freeing kfd.dev on the disconnect path, and guard kgd2kfd_teardown_processes() against kfd.dev already being gone when it runs a second time. Cc: Xiaogang Chen <xiaogang.chen@amd.com> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysMerge tag 'libnvdimm-for-7.4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull NVDIMM and DAX updates from Alison Schofield: "A small set of fixes: error handling corrections in the DAX core and bus code, a fix to the DAX file range comparison helpers, and two libnvdimm/pmem fixes for error and probe failure paths" * tag 'libnvdimm-for-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: dax: fix wrong error code returned from dax_dedupe_file_range_compare() dax/bus: Return errors for invalid mapping targets dax: fix dax_range_compare_iter() to use correct size and address offset dax: Return errors from dax_core_init() libnvdimm: Handle negative return from nvdimm_clear_poison() in nsio_rw_bytes() nvdimm/pmem: Release gendisk on probe failure
4 daysdrm/amdkfd: Validate the control stack of a restored queueWilliam Palacek
kfd_criu_restore_queue() takes the control stack size from the checkpoint image without the topology check create-queue does in kfd_queue_acquire_buffers(), which restore stopped calling in commit 1cafa8b29e02 ("drm/amdkfd: Don't acquire buffers during CRIU queue restore."). An image size of 0x300000 is accepted and sizes the MQD allocation, and 0xFFFFFFFF trips a page allocator warning in kmalloc(). restore_mqd() also keeps the image's cp_hqd_cntl_stack_size, cp_hqd_cntl_stack_offset and cp_hqd_wg_state_offset. With offset > size or wave state offset < size, get_wave_state() returns wrapped sizes. Take the per-XCC size from topology, 0 for queues without a control stack, and reject larger images. In restore_mqd(), set the size to it and bound both offsets as init_mqd() does. Fixes: 626f7b3190b4 ("drm/amdkfd: CRIU add queues support") Fixes: 42c6c48214b7 ("drm/amdkfd: CRIU checkpoint and restore queue mqds") Signed-off-by: William Palacek <William.Palacek@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
4 daysdrm/amdkfd: Enable IB execution for user-mode SDMA queuesYongqiang Sun
update_mqd_sdma() never sets IB_ENABLE in the SDMA queue IB_CNTL, so INDIRECT packets submitted on user-mode SDMA queues are not executed. Set IB_ENABLE on all MQD versions. On gfx10 and gfx11, also set SWITCH_INSIDE_IB, which was previously only set on gfx9 and gfx12, so that a long-running IB can be preempted. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>