| Age | Commit message (Collapse) | Author |
|---|
|
amdgpu_dm builds the new dc_state as a copy of the old one. When the last
stream is removed, dml1_validate() returns early on pipe_cnt == 0 and
never reaches dcn32_calculate_dlg_params(), so bw.dcn.clk keeps the
dramclk/dcfclk/fclk requirements of the display that was just turned off.
dcn32_update_clocks() then keeps those hard minimums applied.
On an RX 7900 XTX this leaves UCLK at 456 MHz and DCFCLK at 637 MHz with
the monitor off, and the board idles at 28.4 W. With this change they
drop to 96 MHz and 145 MHz and board power falls to 15.3 W.
Reset the clock requirements in that case, as calculate_dlg_params()
already does when no HUBP is active and as the DML2 path does for
stream_count == 0.
Signed-off-by: Misha Nasledov <misha@nasledov.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0261a0ef89f37ef962fbc9dbc724ebf65fe681cf)
Cc: stable@vger.kernel.org
|
|
[Why]
resource_get_otg_master_for_stream() can return NULL if no OTG master pipe
is found for a given stream. The current code dereferences this pointer
without a NULL check. This may lead to a possible NULL pointer
dereference.
[How]
Add an explicit NULL check and skip the stream if the OTG master is not
found. This is similar to dcn60_update_clocks_update_dtb_dto().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: b6d508533fa1 ("drm/amd/display: fix a crash when clock source is reference for non otg master pipe")
Signed-off-by: Roman Demidov <roman.demidov.nn@gmail.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ffde3d74c1faeeb645b66d02d02fdae3e073941b)
Cc: stable@vger.kernel.org
|
|
gfx_v12_0_update_spm_vmid() does a read-modify-write of RLC_SPM_MC_CNTL
over MMIO without keeping GFX powered, unlike gfx11. When GFX is in
GFXOFF at that point the update doesn't stick, and with the SPM VMID
programmed on submission again, the job of a process with a reserved
VMID can still run with the SPM writing through VMID 0.
On navi48, after a few other submissions and a VM fault on the same VM,
a COPY_DATA of RLC_SPM_MC_CNTL from such a job reads 0 although the
update was called for it:
$ amd_uapi_regression --run-subtest cs-secure-ib-compute,gem-mapping-info-high-va,gpuvm-fault-high-va,reserved-vmid-spm-vmid
amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:40 vmid:7 pasid:185)
amdgpu 0000:03:00.0: Faulty UTCL2 client ID: SDMA1 (0xe)
RLC_SPM_MC_CNTL in the job: 0x00000000
With GFXOFF disallowed around the update it reads the reserved VMID 15.
Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 907aebc5578ae09fa5c0e2f0784201295837e60b)
Cc: stable@vger.kernel.org
|
|
[WHY]
DC asserts with:
WARNING: dc/hubbub/dcn401/dcn401_hubbub.c at dcn401_program_compbuf_segments
Call Trace:
<TASK>
dcn401_program_outstanding_updates+0x36/0x60 [amdgpu]
hwss_process_outstanding_hw_updates+0x33/0x40 [amdgpu]
commit_planes_for_stream+0x171f/0x1ff0 [amdgpu]
dc_update_state_execute+0xaa/0x170 [amdgpu]
dc_update_planes_and_stream+0x42/0x70 [amdgpu]
amdgpu_dm_atomic_commit_tail+0x16a9/0x4020 [amdgpu]
commit_tail+0xc3/0x1b0 [drm_kms_helper]
The DET left by the VBIOS on a HUBP without a plane can be larger than
the DET planned for the new state. The compbuf is sized for the planned
DET, so DET + compbuf can exceed the CRB size. Programming the compbuf
then triggers the ASSERT and sets CONFIG_ERROR in hardware.
[HOW]
Release the DET of HUBPs without a plane before the compbuf is
programmed.
Add hwss_reset_unused_det() and call it in the commit and flip paths,
to cover both seamless and non-seamless boots.
Fixes: 7a1eb6680939 ("drm/amd/display: Perform outstanding programming on full updates")
Cc: Dillon Varone <dillon.varone@amd.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Roman Li <Roman.Li@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c93f6fc7175b445ba3b7c85a1fc31e4e4951bbc9)
Cc: stable@vger.kernel.org
|
|
[WHY]
dal_ddc_open() cleans up pins it acquires on later failures. If the
data-pin open fails, this attempt acquired nothing. If opening the
clock pin or configuring fails, dal_ddc_open() closes the pins it
opened. An extra dal_ddc_close() is unnecessary and unsafe:
GPIO_RESULT_ALREADY_OPENED can mean AUX owns the existing handles,
and closing them here would disrupt AUX.
[HOW]
Remove the extra dal_ddc_close() from the failed-open path.
Cc: Jerry Zuo <jerry.zuo@amd.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 175ae7772b68757b4932f34ff862923cab7abe21)
Cc: stable@vger.kernel.org
|
|
On SR-IOV, programming IH_RB_CNTL through PSP is slow enough for the
first MSI to arrive before ih->enabled is set. amdgpu_ih_process()
then drops the interrupt, rptr stays at 0, and RPTR_REARM never
generates another edge, so every ring hits the fence fallback timer.
Set ih->enabled before psp_reg_program() on the indirect IH path for
Navi10 and IH v6.0, and clear it if programming fails.
Signed-off-by: Danijel Slivka <Danijel.Slivka@amd.com>
Signed-off-by: Milan Milicevic <Milan.Milicevic@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b2f9434f9d17c94798e8d8957af3adc4a9949016)
Cc: stable@vger.kernel.org
|
|
[Why]
get_max_frl_rate() converts the DRM lane count / per-lane rate pair back
into the FRL rate index used by DC, but it only knows the rates up to
12 Gbps. A sink advertising 16, 20 or 24 Gbps per lane therefore falls
into the else branch and reports edid_caps.max_frl_rate = 0.
[How]
Map the remaining 4-lane rates to the matching hdmi_frl_link_rate values
(16 Gbps -> 7, 20 Gbps -> 8, 24 Gbps -> 9) and extend the KUnit coverage
alongside the existing per-rate cases.
Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 175fcf337795cccc52242e20c5a88ac4a51ebc22)
|
|
[Why]
drm_get_max_frl_rate() only decodes Max_FRL_Rate values 1-6, so a sink
advertising an HDMI 2.2 rate (7, 8 or 9) falls into the default case and
is reported as having no FRL support at all.
[How]
Decode the HDMI 2.2 Max_FRL_Rate values 7, 8 and 9 as 16, 20 and 24 Gbps
per lane over 4 lanes.
Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 12d5a58d5bd747da992a04da44cfcaf711c8fef9)
|
|
After the earlier patch exported IP discovery on probe failure, there was
an unexpected consequence where harvest info was not populated. The
early-exit in amdgpu_discovery_sysfs_init meant that we never called
amdgpu_discovery_get_harvest_info, which is where we set the actual
harvest value. The first time we call amdgpu_discovery_sysfs_recurse
with NULL instead of adev, most values can get set. The 2nd time
amdgpu_discovery_sysfs_recurse is called, we bail early.
To keep the logic of the first patch intact, ensuring that older kernels
can still discover the IP blocks, add a separate call in the early-exit
section that sets the harvest information.
This should be the only functionality that is missed in this flow, as the
rest of the calls either work fine with adev=NULL, or use the discovery_bin
directly.
Fixes: 402e04f11ff7 ("drm/amdgpu: Export ip_discovery sysfs on probe failure")
Assisted-by: LLM Claude
Signed-off-by: Kent Russell <kent.russell@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ca0812a625d112df556e37550e6accceea33e485)
Cc: stable@vger.kernel.org
|
|
amdgpu_device_halt_activities() only stops the ring schedulers after
amdgpu_amdkfd_pre_reset() and amdgpu_userq_pre_reset(). With a hung MES
every REMOVE_QUEUE in amdgpu_userq_pre_reset() waits for its timeout, so
the schedulers keep pushing jobs to the hardware for seconds after the
reset has started:
GPU reset begin!. Source: 6
MES failed to respond to msg=REMOVE_QUEUE fence_wait_ret=528494 status=0x0
WARNING: amdgpu_device.c:928 at amdgpu_device_skip_hw_access+0x73/0x90 [amdgpu]
Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]
Call Trace:
amdgpu_mm_wdoorbell64+0x20/0x70 [amdgpu]
sdma_v6_0_ring_set_wptr+0xa6/0x180 [amdgpu]
amdgpu_ring_commit+0x5b/0xa0 [amdgpu]
amdgpu_ib_schedule+0x64a/0x8f0 [amdgpu]
amdgpu_job_run+0xa2/0x220 [amdgpu]
drm_sched_run_job_work+0x10c/0x300 [gpu_sched]
Stop the schedulers of all devices in the reset list first. None of the
preparation steps needs them, and jobs submitted meanwhile simply wait
until amdgpu_device_sched_resume().
Fixes: 290f46cf5726 ("drm/amdgpu: Implement user queue reset functionality")
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Acked-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ea55250ab5594032541c455e1b84e8a7c15a2ba4)
Cc: stable@vger.kernel.org
|
|
Since commit 13d3783a55b7 ("io_uring: wait for in-flight requests on
ring release"), the task dropping the last reference to a ring waits
for every request on it to complete. A process that only received the
ring fd, e.g. over a UNIX socket, can then block in close(2) on
requests owned by other tasks, such as a read from an unresponsive
FUSE server.
Skip the wait for tasks that never attached to the ring and leave those
requests to io_ring_exit_work(), as before.
Fixes: 13d3783a55b7 ("io_uring: wait for in-flight requests on ring release")
Signed-off-by: Orkun Emin Sarı <sariorkunemin@gmail.com>
Link: https://patch.msgid.link/20261104-io-uring-wait-inflight-v2-1-f38f29fe8018@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Port this change to navi10_ih.c:
commit afbf7955ff01 ("drm/amdgpu: clear RB_OVERFLOW bit when enabling interrupts")
Setting IH_RB_WPTR to 0 does not clear RB_OVERFLOW if RB_ENABLE is not
set. Pulse WPTR_OVERFLOW_CLEAR after RB_ENABLE (and with
WPTR_OVERFLOW_ENABLE) so overflow is cleared when interrupts are
enabled.
Signed-off-by: Danijel Slivka <Danijel.Slivka@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Milan Milicevic <Milan.Milicevic@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 713fb4ab04f4d2af6120f8eb607c5673b2759b38)
Cc: stable@vger.kernel.org
|
|
Run GPU post-reset callbacks, including KFD and display-audio resume,
before restarting DRM scheduler workqueues. IP hardware initialization
already happens inside ASIC recovery; this change orders the remaining
callbacks before new scheduler submissions. Preserve the emergency-stop
and guity job completition path's callbacks without starting schedulers,
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Acked-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1f6433e2b264e75c56ae95f187788806201bdbc3)
Cc: stable@vger.kernel.org
|
|
[why]
Opening the CRTC CRC debugfs file programs every CRC engine. On
several generations the engine 1 window and data entries were missing,
so configure hits a zero field mask and WARNs. DCN4.2, DCN4.2B, and
DCN6.0 already had those entries, but configure still writes
OTG_CRC1_SELECT with no mask check. DCN6.0 also lacks OTG_CRC1_EN, so
optc1_configure_crc() writes OTG_CRC_EN instead. The ASIC headers
already define the addresses and fields. The driver tables did not
list them.
[how]
How the missing entries are filled in:
1. DCN3.0 through DCN3.0.3 use OPTC_COMMON_*_DCN3_BASE. Add the six
engine 1 addresses and the window, data, and OTG_CRC1_SELECT masks.
These headers have no OTG_CRC1_EN bit, so that field is not added.
2. DCN3.1 uses OPTC_COMMON_*_DCN3_1. Add the same addresses and masks,
including OTG_CRC1_EN. dcn_3_1_2 defines that bit. DCN3.1.5
and DCN3.1.6 expand DCN3_1 through DCN31X. DCN3.1.4 has its own
list. OTG_CRC1_EN was already on it, so only addresses, SELECT,
window, and data are added.
3. DCN3.2 and DCN3.2.1 already had OTG_CRC1_EN and OTG_CRC1_SELECT.
Add the window and data masks in the OPTC header and the addresses
in the resource header. DCN3.2 fills addresses at init from
ctx->dcn_reg_offsets[].
4. DCN4.0.1 also uses optc1_configure_crc() and was missing SELECT,
window, and data. Add those masks and the six addresses.
OTG_CRC1_EN was already present.
5. DCN3.5, DCN3.5.1, and DCN3.6 already have the addresses and program
engine 1 through optc35_configure_crc(). Their mask list included
DCN3.2 and then repeated the CRC1 window and data fields. Drop the
duplicates.
6. DCN2.0, DCN2.0.1, and DCN2.1 are left unchanged. They inherit the
DCN1.0 lists, which already name engine 1 window, data, and
OTG_CRC1_SELECT. Their headers have no OTG_CRC1_EN bit.
7. DCN4.2 and DCN4.2B use optc35_configure_crc(). Window, data, and
OTG_CRC1_EN were already present. Add OTG_CRC1_SELECT. DCN6.0 uses
optc1_configure_crc(). Window and data were already present. Add
OTG_CRC1_SELECT and OTG_CRC1_EN.
Fixes: ef45aaf73717 ("drm/amd/display: Configure all CRC engines in pipe CRC source path")
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Closes: https://lore.kernel.org/all/20260829085941.106318-1-mikhail.v.gavrilov@gmail.com/
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Assisted-by: Cursor:Grok 4.7
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> # Navi 31 (DCN3.2)
Reviewed-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
Cc: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f42edf63ba4456fa7a02e81a3aa7f2d410a28921)
Cc: stable@vger.kernel.org
|
|
An individual BO of a user queue VM, i.e. one which doesn't share the
root reservation, goes to the individual needs_update list when it is
evicted. The user queue restore looked at vm->invalidated for them, which
the VM state machine rework turned into the always_valid evicted list and
commit 18decfc9e8cc ("drm/amdgpu/userq: actually validate userq BOs")
into the individual evicted one. That list only holds imported DMA-bufs of
compute VMs though, so for a user queue VM nothing is validated.
The restore then neither locks such a BO nor moves it back. Its PTEs are
updated to wherever it is now, cleared if it went to system memory, and
it doesn't get the new eviction fence, so it can move again under the
running queue.
On navi48, once the BOs of an SDMA user queue are evicted from GTT
(debugfs amdgpu_evict_gtt) the queue faults on its ring and rptr:
amdgpu 0000:03:00.0: in page starting at address 0x0000000100000000 from client 10
amdgpu 0000:03:00.0: Faulty UTCL2 client ID: SDMA0 (0xd)
amdgpu 0000:03:00.0: in page starting at address 0x0000000100101000 from client 10
Validate the BOs on the individual needs_update list like before.
Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4")
Fixes: 18decfc9e8cc ("drm/amdgpu/userq: actually validate userq BOs")
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>
(cherry picked from commit eb0d94765d4be18d41e93ad09947dd9cc06ed31a)
Cc: stable@vger.kernel.org
|
|
amdgpu_dma_buf_move_notify() touches the page tables without first
calling amdgpu_vm_ready(). When a process is SIGKILLed, its VM entities
are stopped. Teardown of an imported dma-buf then tries to clear PTEs by
submitting to one of those stopped entities. That eventually hangs the
task.
Commit aa5fc4362fac ("drm/amdgpu: fix task hang from failed job
submission during process kill") added the stopped entity check in
amdgpu_vm_ready() and used it in amdgpu_cs_vm_handling(). That did not
cover a call in amdgpu_dma_buf_move_notify(), what was already mentioned
in:
https://lists.freedesktop.org/archives/amd-gfx/2025-October/133076.html
Tested by SIGKILLing a GPU workload holding imported dma-bufs. Without
the patch "Trying to push to a killed entity" errors are logged, then a
task hangs. With the patch there are no hung tasks. This was tested on a
6.18 kernel.
Fixes: aa5fc4362fac ("drm/amdgpu: fix task hang from failed job submission during process kill")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com>
Assisted-by: LLM
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bee5c9d7a34cb1b510ad3b4c18c30f9d38b0ab7d)
Cc: stable@vger.kernel.org
|
|
When hw_init() fails, amdgpu_device_ip_fini_early() skips hw_fini()
because status.hw was never set. For VCN, UVD (including UVD ENC), VCE,
and JPEG, hw_fini() is where cancel_delayed_work_sync() is called. Any
idle work queued during the partial hw_init() is therefore left pending
after sw_fini() frees the adev state the handler touches.
Cancel the idle work in each hw_init() error path, immediately before
returning the error, so that hw_fini() remains the sole cancel site on
the normal teardown path with no duplication.
Link: https://github.com/ROCm/amdgpu/issues/234
Fixes: 416e1fab4752 ("drm/amdgpu: drop redundant cancel_delayed_work_sync call")
Assisted-by: Claude:Claude-Sonnet-4.6
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7ff2327fde029e97d0050fcb94e3f4063c318547)
Cc: stable@vger.kernel.org
|
|
The user queue map and unmap helpers talk to the MES, but only the
create path holds reset_domain->sem around them. The eviction, restore,
destroy and suspend paths can submit to the MES while a GPU reset is in
progress:
WARNING: amdgpu_device.c:928 at amdgpu_device_skip_hw_access+0x73/0x90 [amdgpu]
Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu]
Call Trace:
amdgpu_mm_wdoorbell64+0x20/0x70 [amdgpu]
mes_v11_0_ring_set_wptr+0x71/0x80 [amdgpu]
amdgpu_ring_commit+0x5b/0xa0 [amdgpu]
mes_v11_0_submit_pkt_and_poll_completion.constprop.0+0x207/0x520 [amdgpu]
mes_v11_0_remove_hw_queue+0xd9/0x100 [amdgpu]
mes_userq_unmap+0xc3/0x140 [amdgpu]
amdgpu_userq_unmap_helper+0x67/0x280 [amdgpu]
amdgpu_userq_evict+0x52/0xf0 [amdgpu]
amdgpu_eviction_fence_suspend_worker+0x55/0xe0 [amdgpu]
Take the semaphore for read in the helpers instead, around both the MES
call and the queue state check and update. The reset changes the queue
state from amdgpu_userq_pre_reset()/post_reset(), so every caller now
waits for a running reset and acts on the state it left behind.
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e6a8b8588f43bd4d7054ac47cccc35f56ad2df90)
Cc: stable@vger.kernel.org
|
|
The IB tests run inside GPU recovery, which must not allocate memory with
reclaim, take BO reservation locks or depend on eviction. The direct IB
pool and the job allocation use GFP_ATOMIC for this reason.
amdgpu_uvd_send_msg() still passes the UVD scheduler entity for direct
submissions, so drm_sched_job_init() allocates a scheduler fence with
GFP_KERNEL that the direct submission never uses. It also reserves the
message BO and adds the fence to it, which takes the reservation lock,
can allocate a fence slot with GFP_KERNEL and falls back to a blocking
dma_fence_wait().
Only pass the entity for scheduled submissions. The direct message BO is
only used by the IB test, which waits for each fence itself, so only fence
the BO for scheduled submissions.
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>
(cherry picked from commit 1473ee6ae24d5b61c3165c444167a9d2069e1ab9)
|
|
amdgpu_mes_userq_notify_unmap_work_handler() submits a MES misc op
without holding reset_domain->sem, so it can ring the MES doorbell while
the GPU is being reset:
WARNING: amdgpu_device.c:928 at amdgpu_device_skip_hw_access+0x73/0x90 [amdgpu]
Workqueue: events amdgpu_mes_userq_notify_unmap_work_handler [amdgpu]
Call Trace:
amdgpu_mm_wdoorbell64+0x20/0x70 [amdgpu]
mes_v11_0_ring_set_wptr+0x71/0x80 [amdgpu]
amdgpu_ring_commit+0x5b/0xa0 [amdgpu]
mes_v11_0_submit_pkt_and_poll_completion.constprop.0+0x207/0x520 [amdgpu]
mes_v11_0_misc_op+0x8b/0x240 [amdgpu]
amdgpu_mes_notify_unmap_queue+0xa3/0x110 [amdgpu]
amdgpu_mes_userq_notify_unmap_work_handler+0x24/0x70 [amdgpu]
Only send the notification when reset_domain->sem can be trylocked. The
work re-arms itself while the HW queues are oversubscribed, so the
notification is retried once the reset has finished.
Fixes: c0431e1aecdb ("drm/amdgpu/userq: create the same workaround of oversubscription timer")
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Cc: Eric Huang <jinhuieric.huang@amd.com>
Reviewed-by: Eric Huang <jinhuieric.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6c7eee33c1487ed68a41d9d0a5bd932ad32b15d1)
Cc: stable@vger.kernel.org
|
|
amdgpu_amdkfd_map_gtt_bo_to_gart() removes the eviction fence of
bo->vm_bo->vm->process_info from the WPTR BO of a new queue. bo->vm_bo
is the VM which opened the BO last, not necessarily the KFD process' VM,
and a render node VM has no process info.
On navi31, an unprivileged process which exports its WPTR BO with
AMDKFD_IOC_EXPORT_DMABUF and imports it on a second render node fd
oopses in AMDKFD_IOC_CREATE_QUEUE:
BUG: kernel NULL pointer dereference, address: 0000000000000060
RIP: 0010:amdgpu_amdkfd_map_gtt_bo_to_gart+0x86/0x1a0 [amdgpu]
init_user_queue.part.0+0x180/0x250 [amdgpu]
pqm_create_queue+0x32d/0x730 [amdgpu]
kfd_ioctl_create_queue+0x583/0x9f0 [amdgpu]
Pass the process info of the queue instead. With the fix, the queue is
created and destroyed normally.
Fixes: 7f347e3f8217 ("drm/amdkfd: Fix NULL pointer error for GC 11.0.1 on mGPU")
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>
(cherry picked from commit 6b4157498a176bd1c6083f6bb5aaf8a257a2027e)
Cc: stable@vger.kernel.org
|
|
The CS ioctl hands the GPU the GART address of the user fence BO, but
since the BO keeps its own preferred and allowed domains, it no longer
makes sure the BO is in GTT. A user fence in a VRAM BO, which only needs
to be a page in size, gets its address from amdgpu_bo_gpu_offset(), which
warns about non-contiguous VRAM. On navi31, a CS with a user fence in a
4K VRAM BO, or in one created with AMDGPU_GEM_CREATE_VM_ALWAYS_VALID:
WARNING: amdgpu_object.c:1531 at amdgpu_bo_gpu_offset+0x86/0xb0 [amdgpu], CPU#11: cs_gem_checks/18393
RIP: 0010:amdgpu_bo_gpu_offset+0x86/0xb0 [amdgpu]
Call Trace:
<TASK>
amdgpu_cs_parser_bos.isra.0+0x4eb/0x850 [amdgpu]
amdgpu_cs_ioctl+0x97e/0x2510 [amdgpu]
drm_ioctl_kernel+0xac/0x110 [drm]
drm_ioctl+0x2c6/0x5b0 [drm]
__x64_sys_ioctl+0xa0/0xf0
do_syscall_64+0xa3/0x4d0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
and BOs which can't be in GTT at all, like GWS or OA ones of a page in
size, pass the checks as well.
Only take BOs which can't be anywhere else than in GTT as user fence,
which the CS then validates there along with its other BOs. While at it,
detect userptrs with amdgpu_ttm_tt_is_userptr(); amdgpu_ttm_tt_get_usermm()
returns NULL once the task which created the userptr is gone.
v2: only take BOs which can only be in GTT instead of special casing the
user fence BO in the validation, use amdgpu_ttm_tt_is_userptr()
(Christian)
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>
(cherry picked from commit f16989def9561d04d0f2e77216f5319112d29bf1)
Cc: stable@vger.kernel.org
|
|
For rings which parse or patch the IBs on the CPU, like JPEG and VCN,
the CS looks the IB up through its VA mapping and maps the BO, but
ignores the offset in the BO the mapping starts at. It then parses
other data than the GPU executes. On navi31, an IB of JPEG NOPs in the
second page of a BO, mapped with offset_in_bo 4096, is parsed from the
zeros in the first page and rejected:
amdgpu 0000:03:00.0: Invalid packet [0x00000000]!
while the same IB submitted through a mapping of the whole BO works.
Add the mapping offset when locating the IB in the BO.
Fixes: 4802ce117786 ("drm/amdgpu: fix UVD/VCE VM emulation")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 74ba1d87d67d0a38d8248928241c3e1c73d0d53b)
Cc: stable@vger.kernel.org
|
|
GEM_VA takes the GPU virtual addresses above the VA hole sign extended,
like the rest of the UAPI, but GET_MAPPING_INFO reports them without the
upper bits, so they land in the hole. Mappings in the upper half of the
address space can't be recreated or removed with what it returns. On
navi31:
MAP at 0xffff800100000000 -> 0
GET_MAPPING_INFO -> addr 0x800100000000
UNMAP at 0x800100000000 -> -EINVAL
Sign extend the addresses before handing them out.
Fixes: 4d82724f7f2b ("drm/amdgpu: Add mapping info option for GEM_OP ioctl")
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>
(cherry picked from commit 9d5524a339390da9145b19bfb40da45640332fb3)
Cc: stable@vger.kernel.org
|
|
After legacy ACA support was retired, some ASICs systems may trigger
security violations during driver load when
amdgpu_ras_reset_error_count() is invoked in debug mode.
The function only checks whether RAS is supported for the target
block before proceeding. In debug mode, ACA/RAS handling is not
available and attempting to access the reset path can lead to
unexpected HW accesses, resulting in security violation reports
during driver initialization.
Prevent this by treating debug mode as unsupported for RAS error
count reset and return -EOPNOTSUPP early.
Fixes: af1ae7d0beaf ("drm/amdgpu: retire legacy ACA support")
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>
(cherry picked from commit af6b6f1a14dca860468b0fe2a55b7194702d5fa0)
Cc: stable@vger.kernel.org
|
|
AMDGPU_UALINK_ACCEL_STATE_ERROR is ordered after ACTIVE, so the
"state < ACTIVE" check in deactivate_accelerator() lets an accelerator
in the error state through to the full teardown. The NPA VM and
workqueue are only created when the accelerator is activated, and an
accelerator in the error state either never got there (invalid pPod or
vPod configuration) or was already deactivated on the config update
error path.
Tearing it down again calls destroy_workqueue() on a NULL or freed
npa_wq and amdgpu_vm_fini() on an uninitialized or freed NPA VM. This
is reachable from driver unload (hw_fini), a later failing config
update, removal from the vPod and a pPod setup commit.
Only deactivate an accelerator that is actually active.
Fixes: 0e8eb0dcea51 ("drm/amdgpu: Assign accel state based on ASP config")
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0abb988dd7162e56e66e36c55780035be7d34b94)
|
|
Had no validation before. libdrm_amdgpu memsets this, even
for the raw/raw2 functions.
We have a lot of functions touching the ioctl struct, no
strong opinion on where this is placed, but I thought
early would be good.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4d01e15e76358f60ef6734462d2b6d9972b9dfbc)
Cc: stable@vger.kernel.org
|
|
Add IORING_FEAT_REGBUF_TYPES, a feature flag that tells whether extended
buffer registration and dma-buf buffers are available (see
IO_REGBUF_TYPE_* and struct io_uring_regbuf_desc).
Fixes: 62e4bf5b25d44 ("io_uring/rsrc: add dmabuf backed registered buffers")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/1b3ca4acc350aa5a397325d066533c4e5743a0f7.1793623347.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
When io_cqring_wait() gets to the point of sleeping and the wait's timeout
has already passed, io_cqring_schedule_timeout() still arms an hrtimer
for it and calls schedule(). The timer fires right away, but only after
the task has switched to idle, so getting -ETIME back costs a round trip
through idle plus a timer interrupt.
NAPI busy polling hits this on every wait that times out.
__io_napi_busy_loop() caps the busy poll at the remaining timeout, so when
the loop runs to its end without a completion, the timeout has expired by
the time we get here. The task then stops polling for several usec, and
packets that arrive meanwhile are left to the device interrupt. This
affects one of our production workloads, which currently works around it
by having another thread signal an eventfd on the ring before the timeout
expires.
A wait with a zero timeout, or one that runs out before the task gets to
sleep, pays the same cost. io_uring_wait_cqe_timeout() with nothing to
reap and a zero timeout takes ~11 usec and a voluntary context switch on
a Zen 5 desktop.
Return -ETIME without arming the timer once the timeout has passed, as
ep_poll() already does with ep_schedule_timeout(). A passed timeout ends
the wait with -ETIME whether or not a min_timeout is set, so the check
covers both. It costs one io_get_time() per wait that is about to sleep
with a timeout.
Signed-off-by: Ioannis Coward <ioanniscrd@gmail.com>
Link: https://patch.msgid.link/20261104104707.2031280-1-ioanniscrd@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
io_files_update_with_index_alloc() installs a fixed file via
io_fixed_fd_install(), which drops ->uring_lock when the request runs on
io-wq, then put_user()s the allocated slot back to userspace. If that
faults, the error path calls __io_close_fixed() by slot index after
re-taking the lock.
The slot can be closed and reused between the install and that cleanup:
another fixed CLOSE plus open/accept/pipe/socket, or a FILES_UPDATE, can
put an unrelated file into the same slot. The error path then removes
that file instead of the one this request installed, ending an unrelated
file's fixed-table reference early. This is a correctness/DoS issue, not
a use-after-free: fixed-file requests hold an io_rsrc_node reference, so
the node and file stay alive until they are done.
Hold ->uring_lock across __io_fixed_fd_install() and put_user(), and do
the failure cleanup with io_fixed_fd_remove() under the same lock. This
is the same class as the io_pipe_fixed() fix in a3d7ee11289f. Faulting
while holding ->uring_lock is fine, the registration paths already do
it.
Fixes: a7c41b4687f5 ("io_uring: let IORING_OP_FILES_UPDATE support choosing fixed file slots")
Signed-off-by: Yuansheng Yang <0xbeac@gmail.com>
Link: https://patch.msgid.link/20261104154655.81876-1-0xbeac@gmail.com
[axboe: various touch-ups]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
On the ADATA XPG GAMMIX S70 BLADE (PCI 1cc1:5370, firmware 03020P5E)
every Write with the FUA bit set takes 200, 400 or 600 ms to complete,
always a multiple of ~200 ms, while a plain Write completes in
0.0-0.4 ms and a Flush in ~1.3 ms. Tracing nvme_setup_cmd and
nvme_complete_rq shows the whole delay is between submission and
completion, i.e. inside the device (e.g. FUA write, control 0x4000:
598.3 ms).
Because ext4/jbd2 issue FUA for every journal commit, fsync() on this
drive stalls for 250-890 ms and desktop applications freeze.
Add NVME_QUIRK_NO_FUA, which stops advertising BLK_FEAT_FUA while
keeping the volatile write cache enabled, so the block layer emulates
FUA with a Write followed by a Flush. Durability semantics are
unchanged. Apply it to the S70 BLADE through nvme_id_table.
With the quirk applied, 4 KiB O_DIRECT|O_DSYNC writes and
create+write+fsync drop from 250-890 ms to a 0.82-0.85 ms median
(30 samples, two partitions on the same drive).
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Hugo Deco <hugodeco@sufficit.com.br>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
nvmet_ns_disable() kills the namespace's percpu ref, waits in
synchronize_rcu() for anyone looking the namespace up under
rcu_read_lock(), and then waits for the ref to drop to zero.
Killing a percpu ref that is still in percpu mode, as the namespace
ref always is until then, switches it to atomic mode from an RCU
callback, so the ref can't drop to zero before a grace period has
passed since the kill. synchronize_rcu() thus adds a second grace
period in a row, about 4 ms here, and disabling the namespaces of a
subsystem one by one takes about 9 ms each.
Drop synchronize_rcu() and rely on the wait for the ref to cover the
RCU readers as well.
Disabling 64 namespaces through configfs, median of 3 runs on each of
two boots per kernel:
host connected before after
none 588 / 590 ms 409 / 409 ms
nvme-tcp 617 / 619 ms 542 / 511 ms
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Call key_put() before returning -EKEYREVOKED, as the reference count gets
incremented by key_lookup().
Cc: stable@vger.kernel.org # v6.12+
Fixes: 5bc46b49c828 ("nvme-tcp: check for invalidated or revoked key")
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
io_uring_prep_cmd() puts the optval pointer into the 64-bit optval field
of the SQE with a plain cast, which warns on 32-bit architectures:
mini_liburing.h:272:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
Cast through uintptr_t, and include <stdint.h> for it.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Link: https://patch.msgid.link/20261104144623.3803717-1-sashal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
ublk_ctrl_uring_cmd_permission() is missing the UBLK_CMD_DEL_DEV_ASYNC
case, causing the command to always return -EINVAL for unprivileged
ublk devices. Fix it by adding the missing case.
Fixes: 13fe8e6825e4 ("ublk: add UBLK_CMD_DEL_DEV_ASYNC")
Cc: stable@vger.kernel.org
Signed-off-by: Yitang Yang <yi1tang.yang@gmail.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/20260901142438.237586-1-yi1tang.yang@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
kublk puts pointers into 64-bit UAPI and SQE fields with a plain (__u64)
cast. ublk builds with -Werror, so it fails to build on 32-bit
architectures:
batch.c:379:42: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
Cast through uintptr_t. kublk also passes 64-bit user copy offsets,
which start at UBLKSRV_IO_BUF_OFFSET (2 GB), to pread() and pwrite(),
and with glibc those are truncated to a 32-bit off_t there. Build with
-D_FILE_OFFSET_BITS=64 as well.
Signed-off-by: Sasha Levin <sashal@kernel.org>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/20261103163928.641519-1-sashal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
A peer can lower the link MTU to TIPC_MIN_BEARER_MTU (100 bytes, plus
the UDP encapsulation header) with the max_pkt field of a RESET or
ACTIVATE message; tipc_link_proto_rcv() only checks the lower bound
returned by tipc_bearer_min_mtu(). The same bound is applied to the
device MTU when a bearer is enabled.
That bound predates two later reductions of the link MSS:
tipc_link_mss() = mtu - INT_H_SIZE (tunnel header)
- EMSG_OVERHEAD (CONFIG_TIPC_CRYPTO)
With CONFIG_TIPC_CRYPTO=y, which is the default, an MTU of 100 gives an
MSS of 28. Once the link comes up, tipc_named_node_up() calls
named_distribute(), which computes
msg_dsz = ((tipc_node_get_mtu() - INT_H_SIZE) / ITEM_SIZE) * ITEM_SIZE;
For an MSS of 28 the subtraction is negative and the result truncates to
0xfffffff0; for an MSS between 40 and 59 it is 0. named_prepare_buf()
then allocates a buffer with no room for any item (the u32 size wraps),
and msg_rem never reaches zero, so every cluster-scope publication on
the node is written with publ_to_item() past the end of that one skb,
over skb_shared_info and into adjacent memory.
Without crypto the MSS is at least 60, which still does not hold the
first fragment built by tipc_msg_build(): INT_H_SIZE fragment header
plus a message header of up to MAX_H_SIZE. With pktmax below that, the
header copies run past the pktmax bytes allocated for the fragment.
Raise TIPC_MIN_BEARER_MTU to MAX_H_SIZE + 2 * INT_H_SIZE so the MSS can
always hold INT_H_SIZE + MAX_H_SIZE, which also leaves room for name
table items, and add tipc_bearer_mtu_floor(), which adds EMSG_OVERHEAD
on top for CONFIG_TIPC_CRYPTO=y. Use it for the device MTU check
(tipc_mtu_bad()), the UDP MTU check, the netlink MTU setting and
tipc_bearer_min_mtu(), which also bounds the max_pkt negotiation.
Found by manual code review and reproduced with KASAN using two network
namespaces joined by a veth pair (see below).
Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
Fixes: 2320bcdae628 ("tipc: fix changeover issues due to large packet")
Suggested-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Signed-off-by: Joas Antonio dos Santos <joasantonio108@gmail.com>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Link: https://patch.msgid.link/179340438471.4412.6707287163192409104@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
tcp_fastopen_create_child() hands the SYN packet itself to
subflow_syn_recv_sock(). For an MP_JOIN request this takes the
fatal fallback: the cloned child is destroyed and handed back with
drop_req flagged, but tcp_fastopen_create_child() does not check
the flag and queues it, so accept() can expose the freed child.
MP_JOIN cannot use Fast Open: data on a subflow requires the
completed HMAC exchange (RFC 8684, sec. 3.2). Refuse it (only the
TFO path passes a SYN skb here) and let tcp_conn_request() fall
back to the regular MP_JOIN handshake; also strip the Fast Open
cookie from MP_JOIN SYN/ACKs.
Fixes: 90bf45134d55 ("mptcp: add new sock flag to deal with join subflows")
Cc: stable@vger.kernel.org
Reported-by: Kimi Security Team <bug-report@moonshot.ai>
Suggested-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Yilin Zhang <yilinzhang@moonshot.ai>
[ Moving code to avoid clearing TS and consolidating checks. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20261030-mptcp-tfo-mpj-v4-1-e6eff2027342@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The device uses the same zero-duty report format for both legitimate 0%
duty GET responses and SET confirmation ACKs on cooler and controller
duty channels. To distinguish them, rog_ryujin_raw_event() checks
!completion_done() on cooler_duty_set and controller_duty_set, assuming
this is only true while a SET command is awaiting confirmation.
However, init_completion() initializes the completion count to zero, so
!completion_done() evaluates to true from probe until the first SET
command completes. Likewise, if rog_ryujin_execute_cmd() fails to send a
command, times out, or is interrupted after reinit_completion(), the
completion remains uncompleted. When a valid 0% duty GET response then
arrives, rog_ryujin_raw_event() consumes it as a SET confirmation and
leaves the pending *_duty_received completion uncompleted, causing
rog_ryujin_execute_cmd() to wait 1.5 seconds and fail with -ETIMEDOUT.
Mark all completions as done with complete_all() after initialization in
rog_ryujin_probe(), and complete status_completion on error in
rog_ryujin_execute_cmd(), so !completion_done() is only true while a
command is actively awaiting a response.
Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler")
Cc: Aleksa Savic <savicaleksa83@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
When IPV6_FL_F_REFLECT is set on a listener, or the
net.ipv6.flowlabel_reflect sysctl has FLOWLABEL_REFLECT_ESTABLISHED,
tcp_v6_send_synack() reflects the flowlabel of the SYN packet,
reading it from the skb stored in ireq->pktopts.
Since commit 079096f103fa ("tcp/dccp: install syn_recv requests
into ehash table"), request sockets are processed without holding
the listener lock. A cpu can then process a retransmitted SYN for a
request socket, and send a SYNACK from tcp_check_req(), while another
cpu receives the ACK completing the 3WHS. tcp_v6_syn_recv_sock()
consumes ireq->pktopts when it wins the hashdance, and the first cpu
reads a freed skb:
BUG: KASAN: slab-use-after-free in tcp_v6_send_synack (include/linux/skbuff.h:3152 include/linux/ipv6.h:110 net/ipv6/tcp_ipv6.c:582)
Read of size 8 at addr ffff88802b08b608 by task poc-ipv6-pktopt/5076
Call Trace:
<IRQ>
tcp_v6_send_synack (include/linux/skbuff.h:3152 include/linux/ipv6.h:110 net/ipv6/tcp_ipv6.c:582)
tcp_rtx_synack (net/ipv4/tcp_output.c:4719)
tcp_check_req (net/ipv4/tcp_minisocks.c:762)
tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1826)
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479)
ip6_input_finish (net/ipv6/ip6_input.c:534)
ip6_input (include/linux/netfilter.h:325 include/linux/netfilter.h:319 net/ipv6/ip6_input.c:545)
ipv6_rcv (include/net/dst.h:481 net/ipv6/ip6_input.c:119 include/linux/netfilter.h:325 include/linux/netfilter.h:319 net/ipv6/ip6_input.c:351)
Freed by task 5074 on cpu 0 at 15.412249s:
kmem_cache_free (include/linux/kasan.h:235 mm/slub.c:2780 mm/slub.c:6630 mm/slub.c:6757)
tcp_v6_syn_recv_sock (net/ipv6/tcp_ipv6.c:1528)
tcp_check_req (net/ipv4/tcp_minisocks.c:934)
tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1826)
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479)
ip6_input_finish (net/ipv6/ip6_input.c:534)
Request socket migration has the same issue: reqsk_migrate_reset()
transfers ireq->pktopts to the clone, which can be freed while
another cpu holding a reference on the old request socket is still
sending a SYNACK.
The SYNACK timer itself is not an issue, because
inet_csk_reqsk_queue_drop() calls timer_delete_sync().
Save the flowlabel of the SYN in the request socket instead, so that
tcp_v6_send_synack() no longer needs ireq->pktopts.
As a side effect, the flowlabel is also reflected for SYN packets
reusing a TIME_WAIT socket, as ireq->pktopts is not set in this case.
Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets")
Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")
Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.")
Reported-by: Anvik Loitongbam <permissiontogallop@gmail.com>
Reported-by: Yingjie Wang <x-professor@outlook.com>
Closes: https://lore.kernel.org/netdev/82c31e4d5043f3dbd11b44177cfba779d335aae3.1793599929.git.x-professor@outlook.com/
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20261102075441.3771550-1-edumazet@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Kuniyuki Iwashima says:
====================
ip: Fix route leak and unregister_netdevice() stuck.
Jason Zhang fed commit 0346ec2f080b ("ipv6: Prevent
rt6_insert_exception() for dying fib6_info.") to LLM to
find tricks to cause the same symptom:
unregister_netdevice: waiting for gre6 to become free. Usage count = 4
ref_tracker: netdev@000000009652f190 has 1/3 users at
dst_alloc+0x14b/0x490
ip6_rt_cache_alloc+0x27b/0x670
__ip6_rt_update_pmtu+0x572/0x850
This series treats them.
====================
Link: https://patch.msgid.link/20261101064418.2055158-1-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Since the cited commit, ip_route_input_slow() could call
rt_dst_alloc() with vrf in the local_input: path.
If res->fi != NULL and one of the following is true,
- a non-zero itag from fib_validate_source_reason()
(realms/classid)
- RTN_BROADCAST with BC_FORWARDING enabled
do_cache is set to false.
Then, the route is not added to rt_uncached_list, so the
route cannot be removed from rt_flush_dev().
If the route is cached in sk->sk_rx_dst, removing the
vrf device gets stuck. [0]
Let's call rt_add_uncached_list() if !do_cache in
ip_route_input_slow().
[0]:
unregister_netdevice: waiting for vrf0 to become free. Usage count = 2
ref_tracker: netdev@000000008b304ac4 has 1/1 users at
dst_alloc+0x14b/0x490
ip_route_input_rcu+0x1540/0x2530
ip_route_input_noref+0x5a/0x90
ip_rcv_finish_core+0x4b0/0x1140
ip_rcv_finish+0xe6/0x190
ip_rcv+0x6c/0x130
__netif_receive_skb+0x121/0x300
process_backlog+0x2df/0x5e0
__napi_poll+0x8c/0x380
net_rx_action+0x43c/0xab0
handle_softirqs+0x19f/0x520
do_softirq+0x46/0x60
__local_bh_enable_ip+0x79/0x80
__dev_queue_xmit+0x1b0e/0x24c0
ip_finish_output2+0x8b2/0xcd0
ip_output+0xf2/0x1e0
Fixes: f5a0aab84b74 ("net: ipv4: dst for local input routes should use l3mdev if relevant")
Reported-by: Jason Zhang <jdz@google.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20261101064418.2055158-4-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When a device is unregistered, rt6_uncached_list_flush_dev()
iterates over uncached routes and switches the dying dev
with blackhole_netdev.
However, rt->from could be cached via sk->sk_rx_dst and
hold the device reference.
Then, unregister_netdevice() gets stuck with the splat
below. [0]
Let's release rt->from in rt6_uncached_list_flush_dev().
Note that ip6_rt_copy_init() could set rt->from even if
in6_dev_get() returns NULL (e.g. mtu < IPV6_MIN_MTU is
set concurrently).
Also, rt->from->nh could be replaced with another device
than rt_dev and rt_idev->dev, and in such a case,
nexthop_flush_dev() sets fib6_destroying before
rt6_uncached_list_flush_dev().
[0]:
unregister_netdevice: waiting for dummy2 to become free. Usage count = 2
ref_tracker: netdev@000000006fb9da8c has 1/1 users at
netdev_get_by_index+0x14c/0x170
fib6_nh_init+0x1ae/0x1950
ip6_route_info_create_nh+0x15d/0x780
ip6_route_add+0x55/0x150
inet6_rtm_newroute+0x15d/0x1360
rtnetlink_rcv_msg+0x606/0x710
netlink_rcv_skb+0x14f/0x2f0
netlink_unicast+0x71b/0x940
netlink_sendmsg+0x595/0x840
__sock_sendmsg+0x119/0x150
____sys_sendmsg+0x3e9/0x5c0
___sys_sendmsg+0x157/0x1a0
__x64_sys_sendmsg+0x119/0x170
do_syscall_64+0x109/0x330
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
Reported-by: Jason Zhang <jdz@google.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20261101064418.2055158-3-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The following creates a cyclic reference between IPv6 route
and nexthop:
1. create a nexthop A
2. create a nexthop group w/ A
3. create an IPv6 route with the nexthop group
4. create an exception route w/ A
5. replace A with a new nexthop B in the nexthop group
6. remove the IPv6 route
7. replace B with A in the nexthop group
8. remove the nexthop group
Then, removing a device tied to the route gets stuck and
triggers the splat below. [0]
At 5., fib6_nh_release_dsts() is called, but it does not
flush exception routes, so the nexthop A continues to grab
the IPv6 route reference.
nh_A->rt6i_exception_bucket[] -> rt6_ex->rt6i->from
At 6., fib6_purge_rt() calls rt6_flush_exceptions(), but it
only purges exceptions tied to nexthop B. Also, the route is
unlinked from the nexthop group by list_del_init(&rt->nh_list).
-> f6i->nh -> nhg->nh_entries[]
At 8., __remove_nexthop_fib() cannot find the IPv6 route, and
remove_nexthop_group() calls list_del_init(&nhge->nh_list) to
unlink the group from the nexthop A's nhe->grp_list.
nhg->nh_entries[] -> nh_A -> ... -> f6i
Here, the nexthop A is reachable from net->nexthop.devhash[],
but remove_nexthop_from_groups() cannot find the nexthop group,
leaking the whole chain.
Let's call fib6_nh_flush_exceptions() in fib6_nh_release_dsts().
[0]:
unregister_netdevice: waiting for gre6 to become free. Usage count = 4
ref_tracker: netdev@000000009652f190 has 1/3 users at
dst_alloc+0x14b/0x490
ip6_rt_cache_alloc+0x27b/0x670
__ip6_rt_update_pmtu+0x572/0x850
ip6_tnl_xmit+0x8c5/0x1b70
__gre6_xmit+0x7af/0xaa0
ip6gre_tunnel_xmit+0x685/0xdc0
dev_hard_start_xmit+0x204/0x5a0
__dev_queue_xmit+0xe8a/0x2550
ip6_finish_output+0x232/0x570
ip6_output+0x226/0x3b0
ip6_send_skb+0x133/0x250
rawv6_push_pending_frames+0x503/0x6f0
rawv6_sendmsg+0xdf0/0x1310
sock_sendmsg_nosec+0xde/0x130
__sys_sendto+0x27f/0x320
__x64_sys_sendto+0xd9/0xf0
Fixes: 7bf4796dd099 ("nexthops: add support for replace")
Reported-by: Jason Zhang <jdz@google.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20261101064418.2055158-2-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
vhost_vsock_alloc_skb() sizes the skb from iov_length(), the total guest
descriptor length. virtio_transport_inc_rx_pkt() instead adds hdr->len to
rx_bytes and buf_used, and budgets each queued skb as SKB_TRUESIZE(0). The
guest controls the descriptor length and hdr->len independently.
A guest can therefore provide a 64 KiB descriptor while declaring a zero
payload. The descriptor-sized skb remains queued, rx_bytes and buf_used
remain unchanged, and only the fixed queue-entry budget limits retention.
This is not a lifetime leak: the skb is freed when dequeued or at socket
teardown. Repeating this across connections can nevertheless exhaust host
memory. On Linux v7.2, 455 such descriptors retained 30,255,680 bytes for
a 262,144-byte receive buffer; a full-payload control retained 265,984
bytes.
Vhost previously read hdr->len and allocated pkt->buf from that value. The
conversion from virtio_vsock_pkt to sk_buff instead allocated receive skbs
from the descriptor length, introducing the allocation-accounting mismatch.
Copy the header into a stack object and validate hdr->len before allocating
the skb. Size the allocation as sizeof(hdr) + payload_len so descriptor
capacity no longer determines queued memory. Check payload_len against
len - sizeof(hdr) to avoid addition overflow on 32-bit hosts.
Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
Cc: stable@vger.kernel.org
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://patch.msgid.link/20261004235101.1464007-1-4ncienth@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
skb_mpls_dec_ttl() decrements the u8 TTL before checking whether it
expired. An incoming TTL of zero wraps to 255, causing the TC MPLS
dec_ttl action to pass an expired packet instead of dropping it.
Reject a zero TTL before the decrement while preserving the existing
behavior for TTL one and valid TTL values.
Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
Reviewed-by: Xia Yan <yanxia@cmss.chinamobile.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261031114135.3784868-2-thnkslprpt@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
A few fixes to start with:
- wext: fix notifier netns interaction
- rsi: avoid TID OOB access
- mac80211: reload pointer, fix A-MPDU flags
- brcmfmac: fix DMA regression
- cfg80211: fix regdb validation
* tag 'wireless-2026-11-02' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
wifi: mac80211: reinstate IEEE80211_TX_CTL_AMPDU flag in ieee80211_tx_prep_agg()
wifi: cfg80211: fix out-of-bounds read in valid_rule()
wifi: rsi: Skip TX aggregation setup for non-QoS frames
wifi: wext: Limit notifier event flushes to the device's netns
wifi: brcmfmac: map msgbuf RX packet IDs bidirectional
wifi: mac80211: reload TDLS header pointer after skb_linearize()
====================
Link: https://patch.msgid.link/20261102104649.727621-3-johannes@sipsolutions.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When receiving a pure ack from a peer that also sends data, we can
have SEG.SEQ > SND.WL1, even though the segment contains no data. This
makes tcp_may_update_window() return true (because of the
"after(ack_seq, tp->snd_wl1)" condition), and tcp_ack_update_window()
then adds FLAG_WIN_UPDATE to the segment set of flags, even when
there's no window update.
Since FLAG_WIN_UPDATE prevents the segment from being considered as
dup-ack (as it's part of FLAG_NOT_DUP), this can inhibit fast
retransmit on non-SACK connections, making recovery very slow as it
now entirely relies on RTO.
The "DUPLICATE ACKNOWLEDGMENT" definition of RFC 5681, section 2,
says that lack of window update is a necessary condition for a dup ack:
"(e) the advertised window in the incoming acknowledgment equals the
advertised window in the last incoming acknowledgment.". Spurious
window updates can thus prevent dup ack detection and, in the end, fast
retransmit.
Avoid this scenario by setting FLAG_WIN_UPDATE only when a window
update actually occurs. Pure acks with SEG.SEQ > SND.WL1 can now
be detected as dup-ack and trigger fast retransmission.
Also, stop setting FLAG_WIN_UPDATE in tcp_ack()'s header prediction
path. One of the conditions for header prediction to happen is that
received segments don't trigger a window update. This flag update was
thus wrong to begin with. Now that tcp_ack_update_window() sets
FLAG_WIN_UPDATE only if a window update actually occurred, we need the
header prediction path to stop reporting spurious window updates too.
Otherwise BPF programs would get inconsistent window update information
(CA_ACK_WIN_UPDATE) between fast an slow paths.
Finally, add FLAG_SND_UNA_ADVANCED to the definition of FLAG_NOT_DUP.
This is necessary for the case where an incoming segment acknowledges
less than a full segment of the retransmit queue. Such segments were
not considered dubious by tcp_ack_is_dubious() because of the spurious
FLAG_WIN_UPDATE flag, which prevented the segment from being seen as a
duplicate ack. Now that FLAG_WIN_UPDATE doesn't cover this scenario
anymore, we need another way to mark these acks as non-duplicate.
Adding FLAG_SND_UNA_ADVANCED to FLAG_NOT_DUP is the natural way of
doing this, since, by definition, a segment advancing SND.UNA, even by
a small amount, cannot be a duplicate ack.
A side effect of this patch is that repeated zero window acks received
from peer can now be considered duplicate acks (because of the the
"|| !win" condition in tcp_may_update_window()). Therefore, they can
now trigger fast retransmission and fast recovery, including congestion
window reduction, when the peer is stalled. This is RFC compliant and
shouldn't have any negative effect.
Add packetdrill selftest. Before this patch, the 1001:2001 segment was
retransmitted upon RTO, now it's sent right after reception of the
third duplicate ack.
Thanks to Tom Williams for the investigation help and initial
reproducer.
Reported-by: Tom Williams <Tom.D.Williams@MorganStanley.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/6426d558e45fc6ab724c40af62e4a8793215dd8a.1793219189.git.gnault@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Commit 0fe4573c822c ("spi: ljca: validate the response length before
copying the data") made ljca_spi_read_write() reject any response whose
payload, as announced by r_packet->len, is not contained in the data
received.
That is right for reads, but the adapter acknowledges a write with only
the packet header: r_packet->len holds the number of bytes written and
no payload follows. The reply is 2 bytes long, so
"ret < sizeof(*r_packet) + r_packet->len" is true and every write fails
with -EIO.
Where the Intel Visual Sensing Controller (IVSC) is connected through
the LJCA, as on the Dell XPS 13 9340, its initialisation fails and the
camera behind it is lost:
spi_ljca usb_ljca.ljca-spi.0: transfer failed len: 256
vsc-tp spi-INTC10D0:00: SPI transfer failed: -5
intel_vsc intel_vsc: error -ENODEV: init hw failed
Only require the payload to be present when there is a receive buffer
to copy it into. Write acks are still checked for a non-zero length that
does not exceed the request.
Fixes: 0fe4573c822c ("spi: ljca: validate the response length before copying the data")
Cc: stable@vger.kernel.org # 6.8+
Signed-off-by: Arpith Alexander <arpith99@gmail.com>
Reviewed-by: Weibin Liu <liuwb@xiaopeng.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/20261103131435.21838-1-arpith99@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
qdisc_pkt_len_segs_init() stores skb_transport_offset(), or the inner
offset, in the unsigned hdr_len. A header in front of skb->data gives a
negative offset. For an offset a little below zero, pskb_may_pull() gets a
small length and succeeds. Then a 64-bit kernel reads the TCP header far
after the skb and can crash. Further below zero pskb_may_pull() fails.
Commit 28a57fb2c5df ("net: iptunnel: fix stale transport header during
tunnel decapsulation") fixed one source of such offsets. Other code that
removes bytes from the front of a packet can leave the same stale header.
Return SKB_DROP_REASON_SKB_BAD_GSO for a negative offset in the TCP branch.
SKB_GSO_UDP_L4 and the other GSO types read no header and still get a wrong
qdisc_pkt_len(). On a 64-bit kernel only packets that cause the read after
the skb today get a new result. Then __dev_queue_xmit() drops them and
returns -EINVAL, but sch_handle_ingress() ignores the result. Their content
can be valid. Thus the code that leaves the header stale needs its own fix.
Fixes: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
CC: stable@vger.kernel.org
Link: https://patch.msgid.link/20261101194433.2637113-1-alexei.starovoitov@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
