summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-13ASoC: rockchip: rockchip_i2s: Use dev_err_probe() for error handlingbui duc phuc
Replace dev_err() with dev_err_probe() to prevent log spam when probe returns -EPROBE_DEFER. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260806052136.21034-4-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13ASoC: rockchip: rk3288_hdmi_analog: Use dev_err_probe() for error handlingbui duc phuc
Replace dev_err() with dev_err_probe() to prevent log spam when probe returns -EPROBE_DEFER. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260806052136.21034-3-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13ASoC: rockchip: rk3288_hdmi_analog: Drop redundant probe error messagesbui duc phuc
Remove the probe error messages to avoid duplicate error reporting, since the error is already reported by the called functions. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260806052136.21034-2-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13ASoC: meson: Drop __force castTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop a superfluous cast. Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-15-tiwai@suse.de
2026-08-13ASoC: mediatek: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-14-tiwai@suse.de
2026-08-13ASoC: Intel: avs: Drop __force castTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop a superfluous cast. Acked-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-13-tiwai@suse.de
2026-08-13ASoC: fsl: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Reviewed-by: Shengjiu Wang <shengjiu.wang@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-12-tiwai@suse.de
2026-08-13ALSA: emu10k1: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for control parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-11-tiwai@suse.de
2026-08-13ALSA: asihpi: Drop __force castTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop a superfluous cast. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-10-tiwai@suse.de
2026-08-13ALSA: hda: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM and control parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-9-tiwai@suse.de
2026-08-13ALSA: aloop: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-8-tiwai@suse.de
2026-08-13ALSA: kunit: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-7-tiwai@suse.de
2026-08-13ALSA: oss: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-6-tiwai@suse.de
2026-08-13ALSA: control: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for control parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-5-tiwai@suse.de
2026-08-13ALSA: pcm: Avoid macros for SNDRV_PCM_FMTBIT and SNDRV_PCM_SUBFMTBITTakashi Iwai
Avoid macros to define SNDRV_PCM_FMTBIT_* and SNDRV_PCM_SUBFMTBIT_* contants but use plain bit shifts, instead. This allows bindgen and other tools aware of those definitions. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-4-tiwai@suse.de
2026-08-13ALSA: pcm: Drop __force castsTakashi Iwai
Now that the bitwise parameter definitions are gone for PCM parameters, we don't have to cast with ugly __force prefix. Simply drop those superfluous casts. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-3-tiwai@suse.de
2026-08-13ALSA: uapi: Drop __bitwise and __force prefixTakashi Iwai
We've used __bitwise and __force for some integer parameters for sanity-checks via sparse, with a hope that it'll reduce the misuse or incorrect assignments. This worked in principle, but OTOH, it's been quite a PITA, making the code much uglier than its gain, too, because one had to cast with __force everywhere. Also, Rust-binding would skip those defines because of __force usage, which will become more pains in near future. So let's drop __bitwise and __force prefix usages. In this patch, we start cleaning up the UAPI headers at first. The former bit-wised typedefs are still kept for compatibility for now. As it's only markers for sparse, the changes are absolutely safe, per se. Only that we'll need to watch out more carefully about the variable usage for PCM format type, etc. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260812060557.80445-2-tiwai@suse.de
2026-08-13Merge tag 'firewire-fixes-7.2-final' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: "Fix a NULL pointer dereference in 1394 OHCI PCI driver when probe() returns early with an error, as detected by Syzkaller" * tag 'firewire-fixes-7.2-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: fix NULL pointer dereference in ar_context_release
2026-08-13Merge tag 'gpio-fixes-for-v7.2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - use raw_spinlock_t in gpio-ml-ioh to avoid locking context issues - fix a race condition in gpio-ml-ioh by sharing the register locks across channels - fix a use-after-free bug in unbind path in gpio-sloppy-logic-analyzer * tag 'gpio-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind gpio: ml-ioh: share the register lock across channels gpio: ml-ioh: use raw_spinlock_t for the register lock gpiolib: Check gc->get_direction() before calling gpiod_get_direction()
2026-08-13s390/vfio-ap: Fix NULL deref in status_show() during queue probeAnthony Krowiak
When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds. Fixes: 260f3ea141382 ("s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removedAnthony Krowiak
The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmapAnthony Krowiak
The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap on the stack without zero-initializing it. In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function is only called to initialize and populate apm_filtered if either filter_adapters or filter_domains is true. If the hot plug configuration change only adds control domains (meaning filter_cdoms is true, but filter_adapters and filter_domains are both false), vfio_ap_mdev_filter_matrix() is bypassed. Consequently, apm_filtered is passed to reset_queues_for_apids() with uninitialized stack garbage. This can cause reset_queues_for_apids() to interpret arbitrary stack garbage bits as valid APIDs to reset, potentially performing unintended guest hardware queue resets. Fix this by zero-initializing the apm_filtered bitmap at the beginning of vfio_ap_mdev_hot_plug_cfg() using bitmap_zero(). Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_removeAnthony Krowiak
The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev objectAnthony Krowiak
In the vfio_ap_mdev_cfg_add function, the apm_add, aqm_add and adm_add fields of an ap_matrix_mdev object fields are modified while not holding the matrix_dev->mdevs_lock. This lock must be held while making these to guard against a race condition with another caller that may be concurrently modifying these fields or any of the fields in the matrix_mdev->matrix. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objectsAnthony Krowiak
In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree. Fixes: 2c1ee8983aa3 ("s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULLAnthony Krowiak
The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration. Fixes: eeb386aeb5b7c ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13s390/vfio-ap: Fix stale do_remove flag across iterations in ↵Anthony Krowiak
vfio_ap_mdev_cfg_remove The do_remove flag in vfio_ap_mdev_cfg_remove() is initialised to zero before the loop that iterates over the list of matrix mdevs, but is never reset at the start of each iteration. Since do_remove is OR-accumulated across iterations, a positive result from one mdev carries over to subsequent mdevs. The fix is to set the do_remove flag with the first call to bitmap_and; for example: do_remove = bitmap_an rather than do_remove |= bitmap_and. Fixes: eeb386aeb5b7 ("s390/vfio-ap: handle config changed and scan complete notification") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-08-13Merge tag 'm68k-for-v7.2-tag2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k Pull m68k fix from Geert Uytterhoeven: "Define NR_CPUS to 1. This fixes a long-standing but never critical before oddity on m68k, that turned into a serious configuration issue after a recent erofs change" * tag 'm68k-for-v7.2-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k: Define NR_CPUS to 1
2026-08-13drm/log: Fix infinite loop when scale is too large for displayShixiong Ou
When scale is large enough that scaled_font exceeds the display dimensions, rows or columns become 0. A columns value of 0 causes an infinite loop in drm_log_draw_kmsg_record() because the loop never decrements len. Check for zero rows/columns in drm_log_setup_modeset() and return an error, cleaning up the already allocated buffer to avoid a leak. Fixes: 8a4b913df427 ("drm/log: Add integer scaling support") Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260729084815.692944-1-oushixiong1025@163.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2026-08-13drm/log: Fix out-of-bounds read on empty message lengthShixiong Ou
drm_log_draw_kmsg_record() accesses s[len - 1] to strip the trailing newline, but len is unsigned int. If len is 0, the subtraction wraps to UINT_MAX, causing an out-of-bounds read. Add an early return when len is 0. Fixes: 25e2c2a3eff5 ("drm/log: Color the timestamp, to improve readability") Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260729084520.688087-1-oushixiong1025@163.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2026-08-13drm/log: Fix division by zero when scale module parameter is 0Shixiong Ou
The scale module parameter can be set to 0 via kernel command line. When scale is 0, scaled_font_h and scaled_font_w become 0, causing a division by zero in the rows/columns calculation. Since the scale module parameter is read-only (0444 permissions), it cannot be changed at runtime via sysfs. Clamp it to 1 once in drm_log_register(). Fixes: 8a4b913df427 ("drm/log: Add integer scaling support") Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patch.msgid.link/20260730014440.66323-1-oushixiong1025@163.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2026-08-13Merge tag 'asoc-fix-v7.2-rc7' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.2 This set of fixes is bulked out quite a bit by the inclusion of a lot of quirks for various x86 platforms, though there are a few driver specific fixes in here too. Nothing here is terribly critical, we should be fine waiting for the merge window if it's too much.
2026-08-13iommu/iommufd: Fix NULL pointer deref in iommufd_ioas_change_process when ↵Peiyang He
racing with iopt_map_file_pages iommufd_ioas_change_process() iterates every IOAS area while only holding every IOAS iova_rwsem, so it assumes every area has a non-NULL pages pointer. That assumption can be false when it runs concurrently with iopt_map_file_pages(). iopt_map_pages() executes in two phases. It first creates the area and inserts it into the interval tree under iova_rwsem, with area->pages still NULL. It then drops iova_rwsem and later fills area->pages under domains_rwsem. This leaves a window between area creation and area->pages fill where a concurrent iommufd_ioas_change_process() can observe the area and dereference a NULL area->pages pointer, leading to a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 00000000000000c0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4b655067 P4D 4b655067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 11841 Comm: syz.1.628 Not tainted 7.1.0 #3 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:iommufd_ioas_change_process+0x419/0xd50 drivers/iommu/iommufd/ioas.c:538 Code: 48 89 c3 48 85 c0 0f 84 cc 00 00 00 e8 10 f5 cb fd 48 8d 7b 68 e8 a7 b5 eb fd 48 8b 6b 68 48 8d bd c0 00 00 00 e8 17 b2 eb fd <8b> ad c0 00 00 00 bf 01 00 00 00 89 ee e8 85 ef cb fd 83 fd 01 74 RSP: 0018:ffffc90015c17d28 EFLAGS: 00010246 RAX: ffff8880186d5328 RBX: ffff88801d25e240 RCX: 0000000080000000 RDX: 00000000000002d7 RSI: ffffffff83ba9e10 RDI: 00000000000000c0 RBP: 0000000000000000 R08: ffffffff8e781eb8 R09: 0000000000000000 R10: 00000000000000c0 R11: ffffffff83ba9e29 R12: ffff88802e216008 R13: ffff88802e216000 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f4aea3f66c0(0000) GS:ffff8880b1fa1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 000000004b75c000 CR4: 0000000000350ef0 Call Trace: <TASK> iommufd_fops_ioctl+0x287/0x400 drivers/iommu/iommufd/main.c:533 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x120/0x170 fs/ioctl.c:583 x64_sys_call+0x1092/0x1fb0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x10a/0x680 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4aec1a82bd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4aea3f6018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f4aec436090 RCX: 00007f4aec1a82bd RDX: 0000200000000180 RSI: 0000000000003b92 RDI: 0000000000000003 RBP: 00007f4aec250295 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f4aec436128 R14: 00007f4aec436090 R15: 00007ffd04ef23e0 </TASK> Modules linked in: CR2: 00000000000000c0 ---[ end trace 0000000000000000 ]--- RIP: 0010:iommufd_ioas_change_process+0x419/0xd50 drivers/iommu/iommufd/ioas.c:538 Code: 48 89 c3 48 85 c0 0f 84 cc 00 00 00 e8 10 f5 cb fd 48 8d 7b 68 e8 a7 b5 eb fd 48 8b 6b 68 48 8d bd c0 00 00 00 e8 17 b2 eb fd <8b> ad c0 00 00 00 bf 01 00 00 00 89 ee e8 85 ef cb fd 83 fd 01 74 RSP: 0018:ffffc90015c17d28 EFLAGS: 00010246 RAX: ffff8880186d5328 RBX: ffff88801d25e240 RCX: 0000000080000000 RDX: 00000000000002d7 RSI: ffffffff83ba9e10 RDI: 00000000000000c0 RBP: 0000000000000000 R08: ffffffff8e781eb8 R09: 0000000000000000 R10: 00000000000000c0 R11: ffffffff83ba9e29 R12: ffff88802e216008 R13: ffff88802e216000 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f4aea3f66c0(0000) GS:ffff8880b1fa1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 000000004b75c000 CR4: 0000000000350ef0 ---------------- Code disassembly (best guess): 0: 48 89 c3 mov %rax,%rbx 3: 48 85 c0 test %rax,%rax 6: 0f 84 cc 00 00 00 je 0xd8 c: e8 10 f5 cb fd call 0xfdcbf521 11: 48 8d 7b 68 lea 0x68(%rbx),%rdi 15: e8 a7 b5 eb fd call 0xfdebb5c1 1a: 48 8b 6b 68 mov 0x68(%rbx),%rbp 1e: 48 8d bd c0 00 00 00 lea 0xc0(%rbp),%rdi 25: e8 17 b2 eb fd call 0xfdebb241 * 2a: 8b ad c0 00 00 00 mov 0xc0(%rbp),%ebp <-- trapping instruction 30: bf 01 00 00 00 mov $0x1,%edi 35: 89 ee mov %ebp,%esi 37: e8 85 ef cb fd call 0xfdcbefc1 3c: 83 fd 01 cmp $0x1,%ebp 3f: 74 .byte 0x74 Fix by mirroring the handling logic in iopt_unmap_iova_range(), i.e. return -EBUSY if area->pages is NULL. Fixes: 829ed626499c ("iommufd: Add IOMMU_IOAS_CHANGE_PROCESS") Link: https://patch.msgid.link/r/7344B7A7B9957A65+20260806045059.1884737-1-peiyang_he@smail.nju.edu.cn Cc: stable@vger.kernel.org Signed-off-by: Peiyang He <peiyang_he@smail.nju.edu.cn> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-13drm/xe/mcr: Take vcs1/vecs1 into account for first media sliceAshutosh Dixit
vcs1 and vecs1 may also be present on the first media slice, so take vcs1/vecs1 also into account when determining if the first media slice is absent. Bspec: 67103, 77977 Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260729230645.3052178-2-ashutosh.dixit@intel.com (cherry picked from commit 1dff677209f6ed48779f4ac2ba130a207540a435) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-13Merge branch 'netconsole-replace-target_list_lock-by-rcu-on-userdata-hot-path'Paolo Abeni
Breno Leitao says: ==================== netconsole: replace target_list_lock by RCU on userdata hot path I would like to move netconsole to use RCU on the hot path for a while instead of target_list_lock. My goal is to have no lock on the tx side at all and eventually drop CON_NBCON_ATOMIC_UNSAFE, if that is possible [1]. Start removing target_list_lock on certain parts of the code. This patch transforms the userdata array into a RCU-protected pointer, and uses the dynamic mutex as the write lock. Added a selftest, given we didn't have any netconsole selftest for userdata operations. Feel free to drop it if this is not useful, dear maintainers. Link: https://lore.kernel.org/all/20251121-nbcon-v1-0-503d17b2b4af@debian.org/[1] Signed-off-by: Breno Leitao <leitao@debian.org> ==================== Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-0-f65557f769ce@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13selftests: netconsole: add a userdata torture testBreno Leitao
The userdata payload is rebuilt and republished on every configfs write, including while the target is enabled and messages are being sent. Add netcons_userdata.sh that runs random tests with userdata. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com> Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-2-f65557f769ce@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13netconsole: publish the userdata payload with RCUBreno Leitao
update_userdata() takes target_list_lock to swap nt->userdata and nt->userdata_length, then frees the old buffer. Since commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") that lock is also the console's device_lock, so writing a userdata value from configfs serialises against the printk core emitting messages. The buffer is immutable once published, which is what RCU is for. Move the string and its length into a single netcons_userdata object and publish it with rcu_replace_pointer(), freeing the old one with kfree_rcu(). New userdata design: 0) Unify the userdata fields into a struct netcons_userdata 1) update_userdata() no longer needs target_list_lock. 2) writers stay serialised by dynamic_netconsole_mutex. 3) reading userdata needs an RCU read lock. No functional change intended. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com> Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-1-f65557f769ce@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13drm/xe: Fix xe_device_probe() failureRaag Jadav
Currently, xe_device_probe() jumps to err_unregister_display label in case of failure except for its last call, which directly returns the error without required cleanup handling. This results in stale drm device that isn't cleaned up on unwind. Fix it. [ 810.194180] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 810.194183] CPU: 9 UID: 0 PID: 5616 Comm: modprobe Kdump: loaded Tainted: G S U E 7.2.0-rc2-xe #382 PREEMPT(full) [ 810.194185] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER, [E]=UNSIGNED_MODULE [ 810.194186] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1805 10/30/2024 [ 810.194186] Call Trace: [ 810.194187] <TASK> [ 810.194188] dump_stack_lvl+0xe0/0x100 [ 810.194195] dump_stack+0x14/0x20 [ 810.194197] sysfs_warn_dup+0x5f/0x80 [ 810.194204] sysfs_create_dir_ns+0xbe/0xd0 [ 810.194210] kobject_add_internal+0xbc/0x2b0 [ 810.194215] kobject_add+0x7c/0xe0 [ 810.194220] ? get_device_parent+0xcf/0x1e0 [ 810.194227] device_add+0xe3/0x870 [ 810.194231] ? __pfx_drm_gem_name_info+0x10/0x10 [drm] [ 810.194280] drm_minor_register+0x73/0x130 [drm] [ 810.194322] drm_dev_register+0x76/0x2a0 [drm] Cc: stable@vger.kernel.org Fixes: da3799c97572 ("drm/xe: Use GuC to do GGTT invalidations for the GuC firmware") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260810123821.105605-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 5ce3042c67c539480882567137ff8d56118885d6) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe: Fix a bug in pc_adjust_freq_bounds()Vinay Belgaumkar
In cases where min frequency was actually greater than BMG_MIN_FREQ, we were not using the updated min frequency as there was a missing call to pc_action_query_task_state() between the two settings of min frequency. Since we know what min_freq was last set, use that cached value while comparing to BMG_MIN_FREQ to fix this issue. v2: pc->freq_ready is not set until after pc_adjust_freq_bounds(). Stay with pc_action_query_task_state() instead. v3: Update commit message (Stuart) Fixes: bdde16c9ac5c ("drm/xe/bmg: Update Wa_14022085890") Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260805234649.2076384-1-vinay.belgaumkar@intel.com (cherry picked from commit a2c2d2b13a9ea9494d2d76b46273833111749507) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe/oa: Check managed mutex initialization errorsLinmao Li
drmm_mutex_init() can fail while registering its managed cleanup action. On failure, the reset path destroys the mutex, so continuing OA setup leaves an unusable lock that later paths may acquire. Return the error from per-GT OA initialization and abort device-wide OA initialization if the metrics lock cannot be initialized. Fixes: a9f905ae7b6f ("drm/xe/oa/uapi: Initialize OA units") Fixes: cdf02fe1a94a ("drm/xe/oa/uapi: Add/remove OA config perf ops") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260713083053.321091-1-lilinmao@kylinos.cn (cherry picked from commit 360b293de27bfdd0d07047f8efd5ba8e91fa90b7) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe/oa: Fix sync entry leak on OA config emit failureLinmao Li
xe_oa_emit_oa_config() releases the sync entries and the syncs array only on its success path. When it fails before the point of no return (fence allocation, config buffer allocation or batch submission), it returns without touching stream->syncs. The stream open path handles such failures in the caller, but xe_oa_config_locked() propagates the error without any cleanup, so the syncs array and the fence references held by the parsed entries are leaked. The next config ioctl overwrites stream->syncs, making the memory unreachable for good. Clean up the parsed syncs when xe_oa_emit_oa_config() fails, matching the cleanup done by the stream open error path. Fixes: 9920c8b88c5c ("drm/xe/oa: Add syncs support to OA config ioctl") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260731011932.3426219-1-lilinmao@kylinos.cn (cherry picked from commit 8af97b3da2cfce04e6b457c6eb17ed3c1daf912b) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe/lrc: document sentinel and make CTX_TIMESTAMP read TOCTOU-safeGajendra Uttamchand
Problem: CTX_TIMESTAMP MMIO reads could be stale if a context switched out between check and read; LRC stores a sentinel while a context starts that must not be treated as a real timestamp. Fix: Check the LRC-stored sentinel before and after the MMIO read; return the LRC value if the context switched out to avoid TOCTOU. Note: Keep XE_LRC_CTX_TIMESTAMP_ACTIVE in xe_lrc.h as the canonical sentinel. Fixes: d243ef6a39c6 ("drm/xe/lrc: Refactor xe_lrc_timestamp to simplify logic") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7956 Assisted-by: GitHub-Copilot:claude-sonnet-5 Signed-off-by: Gajendra Uttamchand <gajendra.uttamchand@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260810071812.213358-4-gajendra.uttamchand@intel.com (cherry picked from commit a806534474df071a730d930df479976a812b699d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe/pxp: add termination on resumeDaniele Ceraolo Spurio
Suspend/resume causes the PXP keys to become invalid, but doesn't actually kill the session. The driver also doesn't explicitly kill and re-start the session until a new PXP request comes in, which means that the "zombie" session can potentially stick around if there are no new requests from userspace. While this is not an issue for PXP, HDCP has a new behavior starting on PTL where a communication is sent to GSC if a session is active at suspend time (even if it doesn't have a valid key), which can lead to delays in the suspend flow if we suspend while the zombie session is still active. To avoid this, we can trigger a termination on resume and kill the zombie session immediately, instead of delaying the termination to the next PXP request. Due to restrictions in the rpm suspend/resume flow, we can't call the termination flow from within the resume call itself, so the pxp irq worker is expanded to cover this scenario. The existing logic in the worker doesn't work as-is for the new flow, because the pm_get_if_active will fail if the worker runs before the pci_resume call has completed (which is possible, since we queue it from within that call) or after we're started to suspend again. Given that we always want to run the worker after a resume (differently from the irq case, where we want to skip if we're suspended), we can solve this by just taking the PM reference before queueing the worker. As part of this rework, the pxp->events variable has been moved to atomic, to avoid having to take xe->irq.lock from non-irq related paths. Fixes: b1dcec9bd8a1 ("drm/xe/ptl: Enable PXP for PTL") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Julia Filipchuk <julia.filipchuk@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patch.msgid.link/20260720222757.3876338-2-daniele.ceraolospurio@intel.com (cherry picked from commit 757bda2b8b93fa36ad9b2c7993081d5f9d0d6e3b) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe: Order ring writes before ring tail updatesMatthew Brost
The ring buffer and the LRC context image are both mapped WC, so the ring tail update can become visible to the device before the ring contents it is meant to publish. The GuC CT send does contain an xe_device_wmb(), so sending the H2G would flush the ring contents. The problem is that it comes too late: xe_lrc_set_ring_tail() publishes the tail before the H2G is sent, and the device samples the tail from the context image independently of it, either at context switch-in or while the context is already resident. A submitter which is interrupted between updating the tail and sending its H2G therefore leaves the device free to observe the new tail while the ring contents behind it are not yet visible: 1. Thread A emits a job into the ring, sets the tail to T_A and sends the H2G, which flushes A's ring contents. The GuC starts scheduling the context in, but it is not executing yet. 2. Thread B emits a job into ring[T_A..T_B]. Those writes are not yet visible to the device. 3. Thread B updates the ring tail to T_B. That write targets a different page and becomes visible first. 4. Thread B is interrupted before it sends its H2G, so the flush which would have published ring[T_A..T_B] has not happened yet. 5. The context is switched in and samples the ring tail from the context image, picking up T_B rather than T_A. 6. The GPU executes A's job, advances HEAD to T_A, and continues on to ring[T_A..T_B], which still holds the previous wrap's contents, so the CS parses stale commands. The result is command stream corruption, which typically manifests as a hang or a spurious pagefault rather than anything that points back at the submission path. Kernel jobs are by far the most likely to hit this. Kernel queues such as the migration queue are shared and can be driven by many threads concurrently, producing back-to-back submissions on an LRC which is already executing. User queues are typically tied to a single submitting thread, so the same interleaving is much harder to produce. Add an xe_device_wmb() at the end of xe_lrc_write_ring() so that it covers every ring tail publication site, and so the invariant is local: once xe_lrc_write_ring() returns, the ring contents are visible to the device. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8651 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7810 Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Assisted-by: GitHub_Copilot:claude-opus-5 Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260807171716.140475-1-matthew.brost@intel.com (cherry picked from commit 136360290f314890428a3fbf31aaa8e4f1d43567) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe/guc_ads: use uncached mapping for UM queue BOJia Yao
On Pre-Xe3p platform, the GAM write the UM queue through DPA using UC. if GuC reads the queue via GGTT (WB), stale data may be observed when the cacheline has been polluted by another agent. To match the GAM's UC writes, configure the GuC mapping as UC as well. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v6.12+ Signed-off-by: Jia Yao <jia.yao@intel.com> Reviewed by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260804165057.129529-4-jia.yao@intel.com (cherry picked from commit 9daa302a82590eeee7bdc68023ddad302df4b88c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe/guc_ads: allocate UM queues in VRAM on dGFXJia Yao
On iGPU, the UM queue BO is allocated in system memory. On dGFX, the BO was previously created in system memory and later reallocated in xe_guc_realloc_post_hwconfig(). Allocate the UM queue BO directly in VRAM on dGFX, where it is ultimately required. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v6.12+ Signed-off-by: Jia Yao <jia.yao@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260804165057.129529-3-jia.yao@intel.com (cherry picked from commit ace076ef0a854ab5940bacc539bf66afd61d118c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe/guc_ads: allocate UM queues in a separate BOJia Yao
Move the UM queues into a dedicated BO (ads->um_queue_bo) and avoid CPU memset operations on it, which eliminates the CPU as a potential cacheline-polluting agent and helps maintain consistency between GAM writes and GuC reads. We also need to ensure the base_dpa for the queue is contiguous on hw where this is used instead of a GGTT address. Another good reason to split this out to a separate BO. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v6.12+ Signed-off-by: Jia Yao <jia.yao@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260804165057.129529-2-jia.yao@intel.com (cherry picked from commit 6af05de0dc19bbf3aaeec2020fe48b37c834b811) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe: Fix DPT allocation paths.Maarten Lankhorst
Remove the fallback for VRAM to system memory, I tested it and that doesn't work at all, only a black screen with pipe fault errors were observed. On systems with media GT, extra latency is added when accessing stolen memory when the GT is in MC6. Since we additionally aren't counting how much memory is used for stolen and we could in theory fill up the entire stolen area with DPT's, avoid using stolen and only use the default memory region. Using stolen may also result in random system hangs under load. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513 Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+") Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Matthew Brost <matthew.brost@intel.com> #teams (cherry picked from commit a196406a3831291598fe8e73245914f7acffdfe0) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-08-13drm/xe: Fix a bug in pc_adjust_freq_bounds()Vinay Belgaumkar
In cases where min frequency was actually greater than BMG_MIN_FREQ, we were not using the updated min frequency as there was a missing call to pc_action_query_task_state() between the two settings of min frequency. Since we know what min_freq was last set, use that cached value while comparing to BMG_MIN_FREQ to fix this issue. v2: pc->freq_ready is not set until after pc_adjust_freq_bounds(). Stay with pc_action_query_task_state() instead. v3: Update commit message (Stuart) Fixes: bdde16c9ac5c ("drm/xe/bmg: Update Wa_14022085890") Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260805234649.2076384-1-vinay.belgaumkar@intel.com (cherry picked from commit a2c2d2b13a9ea9494d2d76b46273833111749507) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-08-13drm/xe: Fix xe_device_probe() failureRaag Jadav
Currently, xe_device_probe() jumps to err_unregister_display label in case of failure except for its last call, which directly returns the error without required cleanup handling. This results in stale drm device that isn't cleaned up on unwind. Fix it. [ 810.194180] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/renderD128' [ 810.194183] CPU: 9 UID: 0 PID: 5616 Comm: modprobe Kdump: loaded Tainted: G S U E 7.2.0-rc2-xe #382 PREEMPT(full) [ 810.194185] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER, [E]=UNSIGNED_MODULE [ 810.194186] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1805 10/30/2024 [ 810.194186] Call Trace: [ 810.194187] <TASK> [ 810.194188] dump_stack_lvl+0xe0/0x100 [ 810.194195] dump_stack+0x14/0x20 [ 810.194197] sysfs_warn_dup+0x5f/0x80 [ 810.194204] sysfs_create_dir_ns+0xbe/0xd0 [ 810.194210] kobject_add_internal+0xbc/0x2b0 [ 810.194215] kobject_add+0x7c/0xe0 [ 810.194220] ? get_device_parent+0xcf/0x1e0 [ 810.194227] device_add+0xe3/0x870 [ 810.194231] ? __pfx_drm_gem_name_info+0x10/0x10 [drm] [ 810.194280] drm_minor_register+0x73/0x130 [drm] [ 810.194322] drm_dev_register+0x76/0x2a0 [drm] Cc: stable@vger.kernel.org Fixes: da3799c97572 ("drm/xe: Use GuC to do GGTT invalidations for the GuC firmware") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260810123821.105605-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 5ce3042c67c539480882567137ff8d56118885d6) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>