For kernels compiled with CONFIG_INIT_STACK_NONE=y, the value of __reserved
field in zen_patch_rev union on the stack may be garbage. If so, it will
prevent correct microcode check when consulting p.ucode_rev, resulting in
incorrect mitigation selection.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Michael Zhivich <mzhivich(a)akamai.com>
Fixes: 7a0395f6607a5 ("x86/bugs: Add a Transient Scheduler Attacks mitigation")
---
Changes in v2:
- Rework patch per feedback
- Add Cc: stable
arch/x86/kernel/cpu/amd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index efd42ee9d1cc..289ff197b1b3 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -378,6 +378,8 @@ static bool amd_check_tsa_microcode(void)
p.model = c->x86_model;
p.ext_model = c->x86_model >> 4;
p.stepping = c->x86_stepping;
+ /* reserved bits are expected to be 0 in test below */
+ p.__reserved = 0;
if (cpu_has(c, X86_FEATURE_ZEN3) ||
cpu_has(c, X86_FEATURE_ZEN4)) {
--
2.34.1
From: Imre Deak <imre.deak(a)intel.com>
After the commit in the Fixes: line below, HPD polling stopped working
on i915, since after that change calling drm_kms_helper_poll_enable()
doesn't restart drm_mode_config::output_poll_work if the work was
stopped (no connectors needing polling) and enabling polling for a
connector (during runtime suspend or detecting an HPD IRQ storm).
After the above change calling drm_kms_helper_poll_enable() is a nop
after it's been called already and polling for some connectors was
disabled/re-enabled.
Fix this by calling drm_kms_helper_poll_reschedule() added in the
previous patch instead, which reschedules the work whenever expected.
Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled")
CC: stable(a)vger.kernel.org # 6.4+
Cc: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>
Cc: dri-devel(a)lists.freedesktop.org
Reviewed-by: Jouni Högander <jouni.hogander(a)intel.com>
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230822113015.41224-2-imre.d…
(cherry picked from commit 50452f2f76852322620b63e62922b85e955abe94)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Partial-Backport-by: Nicusor Huhulea <nicusor.huhulea(a)siemens.com>
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c
index f7a2f485b177c..6ba2d7b0cd1b7 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -208,7 +208,7 @@ intel_hpd_irq_storm_switch_to_polling(struct drm_i915_private *dev_priv)
/* Enable polling and queue hotplug re-enabling. */
if (hpd_disabled) {
- drm_kms_helper_poll_enable(dev);
+ drm_kms_helper_poll_reschedule(&dev_priv->drm);
mod_delayed_work(system_wq, &dev_priv->display.hotplug.reenable_work,
msecs_to_jiffies(HPD_STORM_REENABLE_DELAY));
}
@@ -638,7 +638,7 @@ static void i915_hpd_poll_init_work(struct work_struct *work)
drm_connector_list_iter_end(&conn_iter);
if (enabled)
- drm_kms_helper_poll_enable(dev);
+ drm_kms_helper_poll_reschedule(&dev_priv->drm);
mutex_unlock(&dev->mode_config.mutex);
--
2.39.2
Commit fb5873b779dd ("iommu/vt-d: Restore context entry setup order
for aliased devices") was incorrectly backported: the domain_attached
assignment was mistakenly placed in device_set_dirty_tracking()
instead of original identity_domain_attach_dev().
Fix this by moving the assignment to the correct function as in the
original commit.
Fixes: fb5873b779dd ("iommu/vt-d: Restore context entry setup order for aliased devices")
Closes: https://lore.kernel.org/linux-iommu/721D44AF820A4FEB+722679cb-2226-4287-883…
Cc: stable(a)vger.kernel.org
Reported-by: Ban ZuoXiang <bbaa(a)bbaa.fun>
Signed-off-by: Ban ZuoXiang <bbaa(a)bbaa.fun>
---
drivers/iommu/intel/iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 56e9f125cda9..af4e6c1e55db 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4414,9 +4414,6 @@ static int device_set_dirty_tracking(struct list_head *devices, bool enable)
break;
}
- if (!ret)
- info->domain_attached = true;
-
return ret;
}
@@ -4600,6 +4597,9 @@ static int identity_domain_attach_dev(struct iommu_domain *domain, struct device
ret = device_setup_pass_through(dev);
}
+ if (!ret)
+ info->domain_attached = true;
+
return ret;
}
--
2.50.1
Hi all,
We've identified a regression affecting PCI passthrough / SR-IOV virtualization starting from Linux v6.12.35.
A user reported that [1], beginning with this version, SR-IOV virtual functions fail to initialize properly inside the guest. The issue appears to some MMIO operations not completing correctly in the guest.
> [ 2.152320] i915 0000:07:00.0: [drm] *ERROR* GT0: GUC: mmio request 0x4509: failure 306/0
> [ 2.152327] i915 0000:07:00.0: [drm] *ERROR* GuC initialization failed (-ENXIO)
> [ 2.152330] i915 0000:07:00.0: [drm] *ERROR* GT0: Failed to initialize GPU, declaring it wedged!
Here is the |git bisect| log:
> # bad: [fbad404f04d758c52bae79ca20d0e7fe5fef91d3] Linux 6.12.37
> # good: [e03ced99c437f4a7992b8fa3d97d598f55453fd0] Linux 6.12.33
> git bisect start 'HEAD' 'v6.12.33'
> # bad: [b01a29a80cca28f0c7d0864e2d62fb9616051bfc] ACPI: bus: Bail out if acpi_kobj registration fails
> git bisect bad b01a29a80cca28f0c7d0864e2d62fb9616051bfc
> # bad: [b01a29a80cca28f0c7d0864e2d62fb9616051bfc] ACPI: bus: Bail out if acpi_kobj registration fails
> git bisect bad b01a29a80cca28f0c7d0864e2d62fb9616051bfc
> # good: [35f116a4658f787bea7e82fdd23e2e9789254f5e] drm/xe: Make xe_gt_freq part of the Documentation
> git bisect good 35f116a4658f787bea7e82fdd23e2e9789254f5e
> # good: [261f2a655b709e59a8d759ce9fa478778d9e84f4] crypto: qat - add shutdown handler to qat_c3xxx
> git bisect good 261f2a655b709e59a8d759ce9fa478778d9e84f4
> # good: [4d0686b53cc9342be3f8ce06336fd5ab0d206355] ata: ahci: Disallow LPM for Asus B550-F motherboard
> git bisect good 4d0686b53cc9342be3f8ce06336fd5ab0d206355
> # bad: [ce4ef0274cb66a4750000f33f2d316c0dbaf4515] KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY
> git bisect bad ce4ef0274cb66a4750000f33f2d316c0dbaf4515
> # bad: [8d0645b59b19d97a3b7c5a3fb8dae0c89e98cde9] parisc/unaligned: Fix hex output to show 8 hex chars
> git bisect bad 8d0645b59b19d97a3b7c5a3fb8dae0c89e98cde9
> # good: [fed611bd8c7b76b070aa407d0c7558e20d9e1f68] f2fs: fix to do sanity check on ino and xnid
> git bisect good fed611bd8c7b76b070aa407d0c7558e20d9e1f68
> # good: [8a008c89e5e5c5332e4c0a33d707db9ddd529f8a] net/sched: fix use-after-free in taprio_dev_notifier
> git bisect good 8a008c89e5e5c5332e4c0a33d707db9ddd529f8a
> # bad: [3f2098f4fba7718eb2501207ca6e99d22427f25a] fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var
> git bisect bad 3f2098f4fba7718eb2501207ca6e99d22427f25a
> # bad: [fb5873b779dd5858123c19bbd6959566771e2e83] iommu/vt-d: Restore context entry setup order for aliased devices
> git bisect bad fb5873b779dd5858123c19bbd6959566771e2e83
> # good: [81c64c2f84ab581d1c45dbbbca941c13128faee6] net: ftgmac100: select FIXED_PHY
> git bisect good 81c64c2f84ab581d1c45dbbbca941c13128faee6
> # first bad commit: [fb5873b779dd5858123c19bbd6959566771e2e83] iommu/vt-d: Restore context entry setup order for aliased devices
>
> commit fb5873b779dd5858123c19bbd6959566771e2e83
> Author: Lu Baolu <baolu.lu(a)linux.intel.com>
> Date: Tue May 20 15:58:49 2025 +0800
>
> iommu/vt-d: Restore context entry setup order for aliased devices
>
> commit 320302baed05c6456164652541f23d2a96522c06 upstream.
This commit was introduced in [2], and the issue only affects stable kernels prior to v6.15. Besides, the Ubuntu v6.14-series kernel used by Proxmox also appears to be affected [3].
Best regards,
Ban ZuoXiang
[1]: https://github.com/strongtz/i915-sriov-dkms/issues/320
[2]: https://lore.kernel.org/r/20250514060523.2862195-1-baolu.lu@linux.intel.com
[3]: https://github.com/strongtz/i915-sriov-dkms/issues/312
Add the 'mediatek,ufs-disable-mcq' property to the UFS device-tree
bindings. This flag corresponds to the UFS_MTK_CAP_DISABLE_MCQ host
capability recently introduced in the UFS host driver, allowing it
to disable the Multiple Circular Queue (MCQ) feature when present.
The binding schema has also been updated to resolve DTBS check errors.
Cc: stable(a)vger.kernel.org
Fixes: 46bd3e31d74b ("scsi: ufs: mediatek: Add UFS_MTK_CAP_DISABLE_MCQ")
Signed-off-by: Macpaul Lin <macpaul.lin(a)mediatek.com>
---
Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml | 4 ++++
1 file changed, 4 insertions(+)
Changes for v2:
- Split new property from the origin patch.
- Add dependency description. Since the code in ufs-mediatek.c
has been backport to stable tree. The dt-bindings should be backport
to the same stable tree as well.
diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
index 32fd535a514a..20f341d25ebc 100644
--- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
@@ -33,6 +33,10 @@ properties:
vcc-supply: true
+ mediatek,ufs-disable-mcq:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: The mask to disable MCQ (Multi-Circular Queue) for UFS host.
+
required:
- compatible
- clocks
--
2.45.2