Age | Commit message (Collapse) | Author |
|
Currently the array size is only limited by the largest kmalloc size which
is incorrect. This change will also return a more specific error message
than ENOMEM to userspace.
Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240808200634.1074083-1-ian.forbes@broadcom.com
|
|
This reverts commit f790b5c09665cab0d51dfcc84832d79d2b1e6c0e.
The reverted commit was not ready to be applied due to dependency on other
OPP/pmdomain changes that didn't make it for the last release cycle. Let's
revert it to fix the behaviour.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20241002122232.194245-2-ulf.hansson@linaro.org
|
|
Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if
necessary") initializes deferred I/O only if it is used.
drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()
unconditionally with struct fb_info.fbdefio == NULL. KASAN with the
out-of-tree Apple silicon display driver posts following warning from
__flush_work() of a random struct work_struct instead of the expected
NULL pointer derefs.
[ 22.053799] ------------[ cut here ]------------
[ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580
[ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram
[ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev
[ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)
[ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 22.078567] pc : __flush_work+0x4d8/0x580
[ 22.079471] lr : __flush_work+0x54/0x580
[ 22.080345] sp : ffffc000836ef820
[ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128
[ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358
[ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470
[ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000
[ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005
[ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000
[ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e
[ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001
[ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020
[ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000
[ 22.096955] Call trace:
[ 22.097505] __flush_work+0x4d8/0x580
[ 22.098330] flush_delayed_work+0x80/0xb8
[ 22.099231] fb_deferred_io_cleanup+0x3c/0x130
[ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper]
[ 22.101559] unregister_framebuffer+0x210/0x2f0
[ 22.102575] drm_fb_helper_unregister_info+0x48/0x60
[ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper]
[ 22.105147] drm_client_dev_unregister+0x1cc/0x230
[ 22.106217] drm_dev_unregister+0x58/0x570
[ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm]
[ 22.108199] component_del+0x1f8/0x3a8
[ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp]
[ 22.110357] platform_shutdown+0x70/0x90
[ 22.111219] device_shutdown+0x368/0x4d8
[ 22.112095] kernel_restart+0x6c/0x1d0
[ 22.112946] __arm64_sys_reboot+0x1c8/0x328
[ 22.113868] invoke_syscall+0x78/0x1a8
[ 22.114703] do_el0_svc+0x124/0x1a0
[ 22.115498] el0_svc+0x3c/0xe0
[ 22.116181] el0t_64_sync_handler+0x70/0xc0
[ 22.117110] el0t_64_sync+0x190/0x198
[ 22.117931] ---[ end trace 0000000000000000 ]---
Signed-off-by: Janne Grunau <j@jannau.net>
Fixes: 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary")
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/ZwLNuZL-8Gh5UUQb@robin
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-6.12-2024-10-08:
amdgpu:
- Fix invalid UBSAN warnings
- Fix artifacts in MPO transitions
- Hibernation fix
amdkfd:
- Fix an eviction fence leak
radeon:
- Add late register for connectors
- Always set GEM function pointers
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241008142831.3739244-1-alexander.deucher@amd.com
|
|
The intent of this debugfs entry is to allow modification of wedging
behavior, either from IGT tests or during manual debug; it should be
marked as writable to properly reflect this. In practice this hasn't
caused a problem because we always access wedged_mode as root, which
ignores file permissions, but it's still misleading to have the entry
incorrectly marked as RO.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: 6b8ef44cc0a9 ("drm/xe: Introduce the wedged_mode debugfs")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241002230620.1249258-2-matthew.d.roper@intel.com
(cherry picked from commit 93d93813422758f6c99289de446b19184019ef5a)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
As part of a Wa_22019338487, ensure that GT freq is restored
even when GSC reload is not successful.
Fixes: 3b1592fb7835 ("drm/xe/lnl: Apply Wa_22019338487")
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240925204918.1989574-1-vinay.belgaumkar@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit 491418a258322bbd7f045e36884d2849b673f23d)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Looks like we are meant to use xa_err() to extract the error encoded in
the ptr.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241001084346.98516-7-matthew.auld@intel.com
(cherry picked from commit f040327238b1a8311598c40ac94464e77fff368c)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Looks like we are meant to use xa_err() to extract the error encoded in
the ptr.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241001084346.98516-6-matthew.auld@intel.com
(cherry picked from commit 1aa4b7864707886fa40d959483591f3d3937fa28)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Ensure we serialize with completion side to prevent UAF with fence going
out of scope on the stack, since we have no clue if it will fire after
the timeout before we can erase from the xa. Also we have some dependent
loads and stores for which we need the correct ordering, and we lack the
needed barriers. Fix this by grabbing the ct->lock after the wait, which
is also held by the completion side.
v2 (Badal):
- Also print done after acquiring the lock and seeing timeout.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241001084346.98516-5-matthew.auld@intel.com
(cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Make sure to always set the GEM function pointer even for in kernel
allocations. This fixes a NULL pointer deref caused by switching to GEM
references.
Signed-off-by: Christian König <christian.koenig@amd.com>
Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs")
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 01b64bc063d014641631867a7e0edd8ac55282d4)
|
|
The `nouveau_dmem_copy_one` function ensures that the copy push command is
sent to the device firmware but does not track whether it was executed
successfully.
In the case of a copy error (e.g., firmware or hardware failure), the
copy push command will be sent via the firmware channel, and
`nouveau_dmem_copy_one` will likely report success, leading to the
`migrate_to_ram` function returning a dirty HIGH_USER page to the user.
This can result in a security vulnerability, as a HIGH_USER page that may
contain sensitive or corrupted data could be returned to the user.
To prevent this vulnerability, we allocate a zero page. Thus, in case of
an error, a non-dirty (zero) page will be returned to the user.
Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")
Signed-off-by: Yonatan Maman <Ymaman@Nvidia.com>
Co-developed-by: Gal Shalom <GalShalom@Nvidia.com>
Signed-off-by: Gal Shalom <GalShalom@Nvidia.com>
Reviewed-by: Ben Skeggs <bskeggs@nvidia.com>
Cc: stable@vger.kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241008115943.990286-3-ymaman@nvidia.com
|
|
When `nouveau_dmem_copy_one` is called, the following error occurs:
[272146.675156] nouveau 0000:06:00.0: fifo: PBDMA9: 00000004 [HCE_PRIV]
ch 1 00000300 00003386
This indicates that a copy push command triggered a Host Copy Engine
Privileged error on channel 1 (Copy Engine channel). To address this
issue, modify the Copy Engine channel to allow privileged push commands
Fixes: 6de125383a5c ("drm/nouveau/fifo: expose runlist topology info on all chipsets")
Signed-off-by: Yonatan Maman <Ymaman@Nvidia.com>
Co-developed-by: Gal Shalom <GalShalom@Nvidia.com>
Signed-off-by: Gal Shalom <GalShalom@Nvidia.com>
Reviewed-by: Ben Skeggs <bskeggs@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241008115943.990286-2-ymaman@nvidia.com
|
|
Since, two suspend-resume cycles are required to enter hibernate and,
since we only need to enable idle optimizations in the first cycle
(which is pretty much equivalent to s2idle). We can check in_s0ix, to
prevent the system from entering idle optimizations before it actually
enters hibernate (from display's perspective). Also, call
dc_set_power_state() before dc_allow_idle_optimizations(), since it's
safer to do so because dc_set_power_state() writes to DMUB.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 2fe79508d9c393bb9931b0037c5ecaee09a8dc39)
Cc: stable@vger.kernel.org # 6.10+
|
|
[Why]
Since the surface/stream update flags aren't cleared after applying
updates, those same updates may be applied again in a future call to
update surfaces/streams for surfaces/streams that aren't actually part
of that update (i.e. applying an update for one surface/stream can
trigger unintended programming on a different surface/stream).
For example, when an update results in a call to
program_front_end_for_ctx, that function may call program_pipe on all
pipes. If there are surface update flags that were never cleared on the
surface some pipe is attached to, then the same update will be
programmed again.
[How]
Clear the surface and stream update flags after applying the updates.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3441
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3616
Cc: Melissa Wen <mwen@igalia.com>
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Josip Pavic <Josip.Pavic@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7671f62c10f2a4c77d89b39fd50fab7f918d6809)
Cc: stable@vger.kernel.org
|
|
Partially revert
commit 0ca9f757a0e2 ("drm/amd/pm: powerplay: Add `__counted_by` attribute for flexible arrays")
The count attribute for these arrays does not get set until
after the arrays are allocated and populated leading to false
UBSAN warnings.
Fixes: 0ca9f757a0e2 ("drm/amd/pm: powerplay: Add `__counted_by` attribute for flexible arrays")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3662
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8a5ae927b653b43623e55610d2215ee94c027e8c)
Cc: stable@vger.kernel.org
|
|
The patch is to solve null dereference in 'aux.dev', which is
introduced in recent radeon rework. By having 'late_register',
the connector should be registered after 'drm_dev_register'
automatically, where in before it is the opposite.
Fixes: 90985660ba48 ("drm/radeon: remove load callback from kms_driver")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3665
Tested-by: Hans de Goede <hdegoede@redhat.com>
Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Wu Hoi Pok <wuhoipok@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b4c1ad70e279bacbc772a468033bdecce2f5e0dc)
|
|
Only creating a new reference for each process instead of each VM.
Fixes: 9a1c1339abf9 ("drm/amdkfd: Run restore_workers on freezable WQs")
Suggested-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Lang Yu <lang.yu@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5fa436289483ae56427b0896c31f72361223c758)
Cc: stable@vger.kernel.org
|
|
Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4->active_perfmon`) is still
retained.
If we open a new file descriptor and submit a few jobs with performance
monitors, the driver will attempt to stop the active performance monitor
using the stale pointer in `vc4->active_perfmon`. However, this pointer
is no longer valid because the previous process has already terminated,
and all performance monitors associated with it have been destroyed and
freed.
To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.
Cc: stable@vger.kernel.org # v4.17+
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Juan A. Suarez Romero <jasuarez@igalia.com>
Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcanal@igalia.com
|
|
When running `kmscube` with one or more performance monitors enabled
via `GALLIUM_HUD`, the following kernel panic can occur:
[ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4
[ 55.008368] Mem abort info:
[ 55.008377] ESR = 0x0000000096000005
[ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits
[ 55.008402] SET = 0, FnV = 0
[ 55.008412] EA = 0, S1PTW = 0
[ 55.008421] FSC = 0x05: level 1 translation fault
[ 55.008434] Data abort info:
[ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000
[ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper
gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb
drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight
[ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1
[ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608
[ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608
[ 55.008895] sp : ffffffc080673cf0
[ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28
[ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148
[ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38
[ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000
[ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90
[ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0
[ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04
[ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857
[ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470
[ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470
[ 55.013292] Call trace:
[ 55.013959] __mutex_lock.constprop.0+0x90/0x608
[ 55.014646] __mutex_lock_slowpath+0x1c/0x30
[ 55.015317] mutex_lock+0x50/0x68
[ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d]
[ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d]
[ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched]
[ 55.017921] kthread+0x11c/0x128
[ 55.018554] ret_from_fork+0x10/0x20
[ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401)
[ 55.019776] ---[ end trace 0000000000000000 ]---
[ 55.020411] note: v3d_bin[166] exited with preempt_count 1
This issue arises because, upon closing the file descriptor (which happens
when we interrupt `kmscube`), the active performance monitor is not
stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`,
the active performance monitor's pointer (`v3d->active_perfmon`) is still
retained.
If `kmscube` is run again, the driver will attempt to stop the active
performance monitor using the stale pointer in `v3d->active_perfmon`.
However, this pointer is no longer valid because the previous process has
already terminated, and all performance monitors associated with it have
been destroyed and freed.
To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.
Cc: stable@vger.kernel.org # v5.15+
Closes: https://github.com/raspberrypi/linux/issues/6389
Fixes: 26a4dc29b74a ("drm/v3d: Expose performance counters to userspace")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241004130625.918580-2-mcanal@igalia.com
|
|
We acquire a connector reference before scheduling an HDCP prop work,
and expect the work function to release the reference.
However, if the work was already queued, it won't be queued multiple
times, and the reference is not dropped.
Release the reference immediately if the work was already queued.
Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org # v5.10+
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240924153022.2255299-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit abc0742c79bdb3b164eacab24aea0916d2ec1cb5)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Pull drm fixes from Dave Airlie:
"Weekly fixes, xe and amdgpu lead the way, with panthor, and few core
components getting various fixes. Nothing seems too out of the
ordinary.
atomic:
- Use correct type when reading damage rectangles
display:
- Fix kernel docs
dp-mst:
- Fix DSC decompression detection
hdmi:
- Fix infoframe size
sched:
- Update maintainers
- Fix race condition whne queueing up jobs
- Fix locking in drm_sched_entity_modify_sched()
- Fix pointer deref if entity queue changes
sysfb:
- Disable sysfb if framebuffer parent device is unknown
amdgpu:
- DML2 fix
- DSC fix
- Dispclk fix
- eDP HDR fix
- IPS fix
- TBT fix
i915:
- One fix for bitwise and logical "and" mixup in PM code
xe:
- Restore pci state on resume
- Fix locking on submission, queue and vm
- Fix UAF on queue destruction
- Fix resource release on freq init error path
- Use rw_semaphore to reduce contention on ASID->VM lookup
- Fix steering for media on Xe2_HPM
- Tuning updates to Xe2
- Resume TDR after GT reset to prevent jobs running forever
- Move id allocation to avoid userspace using a guessed number to
trigger UAF
- Fix OA stream close preventing pbatch buffers to complete
- Fix NPD when migrating memory on LNL
- Fix memory leak when aborting binds
panthor:
- Fix locking
- Set FOP_UNSIGNED_OFFSET in fops instance
- Acquire lock in panthor_vm_prepare_map_op_ctx()
- Avoid uninitialized variable in tick_ctx_cleanup()
- Do not block scheduler queue if work is pending
- Do not add write fences to the shared BOs
vbox:
- Fix VLA handling"
* tag 'drm-fixes-2024-10-04' of https://gitlab.freedesktop.org/drm/kernel: (41 commits)
drm/xe: Fix memory leak when aborting binds
drm/xe: Prevent null pointer access in xe_migrate_copy
drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close
drm/xe/queue: move xa_alloc to prevent UAF
drm/xe/vm: move xa_alloc to prevent UAF
drm/xe: Clean up VM / exec queue file lock usage.
drm/xe: Resume TDR after GT reset
drm/xe/xe2: Add performance tuning for L3 cache flushing
drm/xe/xe2: Extend performance tuning to media GT
drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM
drm/xe: Use helper for ASID -> VM in GPU faults and access counters
drm/xe: Convert to USM lock to rwsem
drm/xe: use devm_add_action_or_reset() helper
drm/xe: fix UAF around queue destruction
drm/xe/guc_submit: add missing locking in wedged_fini
drm/xe: Restore pci state upon resume
drm/amd/display: Fix system hang while resume with TBT monitor
drm/amd/display: Enable idle workqueue for more IPS modes
drm/amd/display: Add HDR workaround for specific eDP
drm/amd/display: avoid set dispclk to 0
...
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Driver Changes:
- Restore pci state on resume (Rodrigo Vivi)
- Fix locking on submission, queue and vm (Matthew Auld, Matthew Brost)
- Fix UAF on queue destruction (Matthew Auld)
- Fix resource release on freq init error path (He Lugang)
- Use rw_semaphore to reduce contention on ASID->VM lookup (Matthew Brost)
- Fix steering for media on Xe2_HPM (Gustavo Sousa)
- Tuning updates to Xe2 (Gustavo Sousa)
- Resume TDR after GT reset to prevent jobs running forever (Matthew Brost)
- Move id allocation to avoid userspace using a guessed number
to trigger UAF (Matthew Auld, Matthew Brost)
- Fix OA stream close preventing pbatch buffers to complete (José)
- Fix NPD when migrating memory on LNL (Zhanjun Dong)
- Fix memory leak when aborting binds (Matthew Brost)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2fiv63yanlal5mpw3mxtotte6yvkvtex74c7mkjxca4bazlyja@o4iejcfragxy
|
|
The mutex field has two following semicolons, replace this with just
one semicolon.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240917120856.1877733-1-colin.i.king@gmail.com
|
|
Make sure to call xe_pt_update_ops_fini in xe_pt_update_ops_abort to
free any memory the bind allocated.
Caught by kmemleak when running Vulkan CTS tests on LNL. The leak
seems to happen only when there's some kind of failure happening, like
the lack of memory. Example output:
unreferenced object 0xffff9120bdf62000 (size 8192):
comm "deqp-vk", pid 115008, jiffies 4310295728
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 1b 05 f9 28 01 00 00 40 ...........(...@
00 00 00 00 00 00 00 00 1b 15 f9 28 01 00 00 40 ...........(...@
backtrace (crc 7a56be79):
[<ffffffff86dd81f0>] __kmalloc_cache_noprof+0x310/0x3d0
[<ffffffffc08e8211>] xe_pt_new_shared.constprop.0+0x81/0xb0 [xe]
[<ffffffffc08e8309>] xe_pt_insert_entry+0xb9/0x140 [xe]
[<ffffffffc08eab6d>] xe_pt_stage_bind_entry+0x12d/0x5b0 [xe]
[<ffffffffc08ecbca>] xe_pt_walk_range+0xea/0x280 [xe]
[<ffffffffc08eccea>] xe_pt_walk_range+0x20a/0x280 [xe]
[<ffffffffc08eccea>] xe_pt_walk_range+0x20a/0x280 [xe]
[<ffffffffc08eccea>] xe_pt_walk_range+0x20a/0x280 [xe]
[<ffffffffc08eccea>] xe_pt_walk_range+0x20a/0x280 [xe]
[<ffffffffc08e9eff>] xe_pt_stage_bind.constprop.0+0x25f/0x580 [xe]
[<ffffffffc08eb21a>] bind_op_prepare+0xea/0x6e0 [xe]
[<ffffffffc08ebab8>] xe_pt_update_ops_prepare+0x1c8/0x440 [xe]
[<ffffffffc08ffbf3>] ops_execute+0x143/0x850 [xe]
[<ffffffffc0900b64>] vm_bind_ioctl_ops_execute+0x244/0x800 [xe]
[<ffffffffc0906467>] xe_vm_bind_ioctl+0x1877/0x2370 [xe]
[<ffffffffc05e92b3>] drm_ioctl_kernel+0xb3/0x110 [drm]
unreferenced object 0xffff9120bdf72000 (size 8192):
comm "deqp-vk", pid 115008, jiffies 4310295728
hex dump (first 32 bytes):
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
backtrace (crc 23b2f0b5):
[<ffffffff86dd81f0>] __kmalloc_cache_noprof+0x310/0x3d0
[<ffffffffc08e8211>] xe_pt_new_shared.constprop.0+0x81/0xb0 [xe]
[<ffffffffc08e8453>] xe_pt_stage_unbind_post_descend+0xb3/0x150 [xe]
[<ffffffffc08ecd26>] xe_pt_walk_range+0x246/0x280 [xe]
[<ffffffffc08eccea>] xe_pt_walk_range+0x20a/0x280 [xe]
[<ffffffffc08eccea>] xe_pt_walk_range+0x20a/0x280 [xe]
[<ffffffffc08eccea>] xe_pt_walk_range+0x20a/0x280 [xe]
[<ffffffffc08ece31>] xe_pt_walk_shared+0xc1/0x110 [xe]
[<ffffffffc08e7b2a>] xe_pt_stage_unbind+0x9a/0xd0 [xe]
[<ffffffffc08e913d>] unbind_op_prepare+0xdd/0x270 [xe]
[<ffffffffc08eb9f6>] xe_pt_update_ops_prepare+0x106/0x440 [xe]
[<ffffffffc08ffbf3>] ops_execute+0x143/0x850 [xe]
[<ffffffffc0900b64>] vm_bind_ioctl_ops_execute+0x244/0x800 [xe]
[<ffffffffc0906467>] xe_vm_bind_ioctl+0x1877/0x2370 [xe]
[<ffffffffc05e92b3>] drm_ioctl_kernel+0xb3/0x110 [drm]
[<ffffffffc05e95a0>] drm_ioctl+0x280/0x4e0 [drm]
Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2877
Fixes: a708f6501c69 ("drm/xe: Update PT layer with better error handling")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240927232228.3255246-1-matthew.brost@intel.com
(cherry picked from commit 63e0695597a044c96bf369e4d8ba031291449d95)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
xe_migrate_copy designed to copy content of TTM resources. When source
resource is null, it will trigger a NULL pointer dereference in
xe_migrate_copy. To avoid this situation, update lacks source flag to
true for this case, the flag will trigger xe_migrate_clear rather than
xe_migrate_copy.
Issue trace:
<7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14,
sizes: 4194304 & 4194304
<7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15,
sizes: 4194304 & 4194304
<1> [317.128055] BUG: kernel NULL pointer dereference, address:
0000000000000010
<1> [317.128064] #PF: supervisor read access in kernel mode
<1> [317.128066] #PF: error_code(0x0000) - not-present page
<6> [317.128069] PGD 0 P4D 0
<4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
<4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted:
G U N 6.11.0-rc7-xe #1
<4> [317.128078] Tainted: [U]=USER, [N]=TEST
<4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client
Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024
<4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe]
<4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8
fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31
ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff
<4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246
<4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX:
0000000000000000
<4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI:
0000000000000000
<4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09:
0000000000000001
<4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12:
ffff88814e7b1f08
<4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15:
0000000000000001
<4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000)
knlGS:0000000000000000
<4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4:
0000000000770ef0
<4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
<4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:
0000000000000400
<4> [317.128184] PKRU: 55555554
<4> [317.128185] Call Trace:
<4> [317.128187] <TASK>
<4> [317.128189] ? show_regs+0x67/0x70
<4> [317.128194] ? __die_body+0x20/0x70
<4> [317.128196] ? __die+0x2b/0x40
<4> [317.128198] ? page_fault_oops+0x15f/0x4e0
<4> [317.128203] ? do_user_addr_fault+0x3fb/0x970
<4> [317.128205] ? lock_acquire+0xc7/0x2e0
<4> [317.128209] ? exc_page_fault+0x87/0x2b0
<4> [317.128212] ? asm_exc_page_fault+0x27/0x30
<4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe]
<4> [317.128263] ? __lock_acquire+0xb9d/0x26f0
<4> [317.128265] ? __lock_acquire+0xb9d/0x26f0
<4> [317.128267] ? sg_free_append_table+0x20/0x80
<4> [317.128271] ? lock_acquire+0xc7/0x2e0
<4> [317.128273] ? mark_held_locks+0x4d/0x80
<4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0
<4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60
<4> [317.128281] ? __pm_runtime_resume+0x60/0xa0
<4> [317.128284] xe_bo_move+0x682/0xc50 [xe]
<4> [317.128315] ? lock_is_held_type+0xaa/0x120
<4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm]
<4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm]
<4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe]
<4> [317.128360] ? find_held_lock+0x31/0x90
<4> [317.128363] ? lock_release+0xd1/0x2a0
<4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10
[kunit]
<4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe]
<4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit]
<4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0
<4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60
<4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [kunit]
<4> [317.128407] kthread+0xf5/0x130
<4> [317.128410] ? __pfx_kthread+0x10/0x10
<4> [317.128412] ret_from_fork+0x39/0x60
<4> [317.128415] ? __pfx_kthread+0x10/0x10
<4> [317.128416] ret_from_fork_asm+0x1a/0x30
<4> [317.128420] </TASK>
Fixes: 266c85885263 ("drm/xe/xe2: Handle flat ccs move for igfx.")
Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240927161308.862323-2-zhanjun.dong@intel.com
(cherry picked from commit 59a1c9c7e1d02b43b415ea92627ce095b7c79e47)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Mesa testing on Xe2+ revealed that when OA metrics are collected for an
exec_queue, after the OA stream is closed, future batch buffers submitted
on that exec_queue do not complete. Not resetting OAC_CONTEXT_ENABLE on OA
stream close resolves these hangs and should not have any adverse effects.
v2: Make the change that we don't reset the bit clearer (Ashutosh)
Also make the same fix for OAC as OAR (Ashutosh)
Bspec: 60314
Fixes: 2f4a730fcd2d ("drm/xe/oa: Add OAR support")
Fixes: 14e077f8006d ("drm/xe/oa: Add OAC support")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2821
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240924213713.3497992-1-ashutosh.dixit@intel.com
(cherry picked from commit 0c8650b09a365f4a31fca1d1d1e9d99c56071128)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Evil user can guess the next id of the queue before the ioctl completes
and then call queue destroy ioctl to trigger UAF since create ioctl is
still referencing the same queue. Move the xa_alloc all the way to the end
to prevent this.
v2:
- Rebase
Fixes: 2149ded63079 ("drm/xe: Fix use after free when client stats are captured")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240925071426.144015-4-matthew.auld@intel.com
(cherry picked from commit 16536582ddbebdbdf9e1d7af321bbba2bf955a87)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Evil user can guess the next id of the vm before the ioctl completes and
then call vm destroy ioctl to trigger UAF since create ioctl is still
referencing the same vm. Move the xa_alloc all the way to the end to
prevent this.
v2:
- Rebase
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240925071426.144015-3-matthew.auld@intel.com
(cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Both the VM / exec queue file lock protect the lookup and reference to
the object, nothing more. These locks are not intended anything else
underneath them. XA have their own locking too, so no need to take the
VM / exec queue file lock aside from when doing a lookup and reference
get.
Add some kernel doc to make this clear and cleanup a few typos too.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240921011712.2681510-1-matthew.brost@intel.com
(cherry picked from commit fe4f5d4b661666a45b48fe7f95443f8fefc09c8c)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Not starting the TDR after GT reset on exec queue which have been
restarted can lead to jobs being able to be run forever. Fix this by
restarting the TDR.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240724235919.1917216-1-matthew.brost@intel.com
(cherry picked from commit 8ec5a4e5ce97d6ee9f5eb5b4ce4cfc831976fdec)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
A recommended performance tuning for LNL related to L3 cache flushing
was recently introduced in Bspec. Implement it.
Unlike the other existing tuning settings, we limit this one for LNL
only, since there is no info about whether this would be applicable to
other platforms yet. In the future we can come back and use IP version
ranges if applicable.
v2:
- Fix reference to Bspec. (Sai Teja, Tejas)
- Use correct register name for "Tuning: L3 RW flush all Cache". (Sai
Teja)
- Use SCRATCH3_LBCF (with the underscore) for better readability.
v3:
- Limit setting to LNL only. (Matt)
Bspec: 72161
Cc: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240920211459.255181-5-gustavo.sousa@intel.com
(cherry picked from commit 876253165f3eaaacacb8c8bed16a9df4b6081479)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
With exception of "Tuning: L3 cache - media", we are currently applying
recommended performance tuning settings only for the primary GT. Let's
also implement them for the media GT when applicable.
According to our spec, media GT registers CCCHKNREG1 and L3SQCREG* exist
only in Xe2_LPM and their offsets do not match their primary GT
counterparts. Furthermore, the range where CCCHKNREG1 belongs is not
listed as a multicast range on the media GT. As such, we need to have
Xe2_LPM-specific definitions for those registers and apply the setting
only for that specific IP.
Both Xe2_HPM and Xe2_LPM contain STATELESS_COMPRESSION_CTRL and the
offset on the media GT matches the one on the primary one. So we can
simply have a copy of "Tuning: Stateless compression control" for the
media GT.
v2:
- Fix implementation with respect to multicast vs non-multicast
registers. (Matt)
- Add missing XE2LPM_CCCHKNREG1 on second action of "Tuning:
Compression Overfetch - media".
v3:
- STATELESS_COMPRESSION_CTRL on Xe2_HPM is also a multicast register,
do not define a XE2HPM_STATELESS_COMPRESSION_CTRL register. (Tejas)
Bspec: 72161
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240920211459.255181-3-gustavo.sousa@intel.com
(cherry picked from commit e1f813947ccf2326cfda4558b7d31430d7860c4b)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
According to Bspec, Xe2 steering tables must be used for Xe2_HPM, just
as it is with Xe2_LPM. Update our driver to reflect that.
Bspec: 71186
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240920211459.255181-2-gustavo.sousa@intel.com
(cherry picked from commit 21ae035ae5c33ef176f4062bd9d4aa973dde240b)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Normalize both code paths with a helper. Fixes a possible leak access
counter path too.
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240918160503.2021315-1-matthew.brost@intel.com
(cherry picked from commit dc0dce6d63d22e8319e27b6a41be7368376f9471)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Remove contention from GPU fault path for ASID->VM lookup.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240918054436.1971839-1-matthew.brost@intel.com
(cherry picked from commit 1378c633a3fbfeb344c486ffda0e920a21e62712)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Use devm_add_action_or_reset() to release resources in case of failure,
because the cleanup function will be automatically called.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: He Lugang <helugang@uniontech.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9631BC17D1E028A2+20240911102215.84865-1-helugang@uniontech.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit fdc81c43f0c14ace6383024a02585e3fcbd1ceba)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
We currently do stuff like queuing the final destruction step on a
random system wq, which will outlive the driver instance. With bad
timing we can teardown the driver with one or more work workqueue still
being alive leading to various UAF splats. Add a fini step to ensure
user queues are properly torn down. At this point GuC should already be
nuked so queue itself should no longer be referenced from hw pov.
v2 (Matt B)
- Looks much safer to use a waitqueue and then just wait for the
xa_array to become empty before triggering the drain.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2317
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240923145647.77707-2-matthew.auld@intel.com
(cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Any non-wedged queue can have a zero refcount here and can be running
concurrently with an async queue destroy, therefore dereferencing the
queue ptr to check wedge status after the lookup can trigger UAF if
queue is not wedged. Fix this by keeping the submission_state lock held
around the check to postpone the free and make the check safe, before
dropping again around the put() to avoid the deadlock.
Fixes: 8ed9aaae39f3 ("drm/xe: Force wedged state and block GT reset upon any GPU hang")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240924150947.118433-2-matthew.auld@intel.com
(cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
The pci state was saved, but not restored. Restore
right after the power state transition request like
every other driver.
v2: Use right fixes tag, since this was there initialy, but
accidentally removed.
Fixes: f6761c68c0ac ("drm/xe/display: Improve s2idle handling.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240912214507.456897-1-rodrigo.vivi@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit ec2d1539e159f53eae708e194c449cfefa004994)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes
- One fix for bitwise and logical "and" mixup in PM code
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/Zv1l75s9Z4Gl4lDH@jlahtine-mobl.ger.corp.intel.com
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
Short summary of fixes pull:
panthor:
- Set FOP_UNSIGNED_OFFSET in fops instance
- Acquire lock in panthor_vm_prepare_map_op_ctx()
- Avoid ninitialized variable in tick_ctx_cleanup()
- Do not block scheduler queue if work is pending
- Do not add write fences to the shared BOs
scheduler:
- Fix locking in drm_sched_entity_modify_sched()
- Fix pointer deref if entity queue changes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20241002151528.GA300287@linux.fritz.box
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-6.12-2024-10-02:
amdgpu:
- DML2 fix
- DSC fix
- Dispclk fix
- eDP HDR fix
- IPS fix
- TBT fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241002135831.2510790-1-alexander.deucher@amd.com
|
|
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
|
|
Now that drm sched uses a single lockdep map for all submit_wq, drop the
GuC submit_wq pool hack.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241002131639.3425022-3-matthew.brost@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
|
Avoid leaking a lockdep map on each drm sched creation and destruction
by using a single lockdep map for all drm sched allocated submit_wq.
v2:
- Use alloc_ordered_workqueue_lockdep_map (Tejun)
Cc: Luben Tuikov <ltuikov89@gmail.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241002131639.3425022-2-matthew.brost@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
[Why]
Connected with a Thunderbolt monitor and do the suspend and the system
may hang while resume.
The TBT monitor HPD will be triggered during the resume procedure
and call the drm_client_modeset_probe() while
struct drm_connector connector->dev->master is NULL.
It will mess up the pipe topology after resume.
[How]
Skip the TBT monitor HPD during the resume procedure because we
currently will probe the connectors after resume by default.
Reviewed-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)
Cc: stable@vger.kernel.org
|
|
[Why]
There are more IPS modes other than DMUB_IPS_ENABLE that enables IPS. We
need to enable the hotplug detect idle workqueue for those modes as
well.
[How]
Modify the if condition to initialize the workqueue in all IPS modes
except for DMUB_IPS_DISABLE_ALL.
Fixes: 65444581a4ae ("drm/amd/display: Determine IPS mode by ASIC and PMFW versions")
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Roman Li <roman.li@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 181db30bcfed097ecc680539b1eabe935c11f57f)
Cc: stable@vger.kernel.org
|
|
[WHY & HOW]
Some eDP panels suffer from flicking when HDR is enabled in KDE. This
quirk works around it by skipping VSC that is incompatible with eDP
panels.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3151
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4d4257280d7957727998ef90ccc7b69c7cca8376)
Cc: stable@vger.kernel.org
|
|
[why]
set dispclk to 0 cause stability issue.
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1c6b16ebf5eb2bc5740be9e37b3a69f1dfe1dded)
Cc: stable@vger.kernel.org
|
|
Existing last step of dsc policy is to restore pbn value under minimum compression
when try to greedily disable dsc for a stream failed to fit in MST bw.
Optimized dsc params result from optimization step is not necessarily the minimum compression,
therefore it is not correct to restore the pbn under minimum compression rate.
Restore the pbn under minimum compression instead of the value from optimized pbn could result
in the dsc params not correct at the modeset where atomic_check failed due to not
enough bw. One or more monitors connected could not light up in such case.
Restore the optimized pbn value, instead of using the pbn value under minimum
compression.
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 352c3165d2b75030169e012461a16bcf97f392fc)
Cc: stable@vger.kernel.org
|