April 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] scsi: ufs: qcom: fix dev reference leaked through" failed to apply to 6.13-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.13-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.13.y git checkout FETCH_HEAD git cherry-pick -x ded40f32b55f7f2f4ed9627dd3c37a1fe89ed8c6 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025041838-fruit-gaming-0562@gregkh' --subject-prefix 'PATCH 6.13.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ded40f32b55f7f2f4ed9627dd3c37a1fe89ed8c6 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus <tudor.ambarus(a)linaro.org> Date: Fri, 17 Jan 2025 14:18:52 +0000 Subject: [PATCH] scsi: ufs: qcom: fix dev reference leaked through of_qcom_ice_get The driver leaks the device reference taken with of_find_device_by_node(). Fix the leak by using devm_of_qcom_ice_get(). Fixes: 56541c7c4468 ("scsi: ufs: ufs-qcom: Switch to the new ICE API") Cc: stable(a)vger.kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Reviewed-by: Abel Vesa <abel.vesa(a)linaro.org> Acked-by: Martin K. Petersen <martin.petersen(a)oracle.com> # SCSI Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Link: https://lore.kernel.org/r/20250117-qcom-ice-fix-dev-leak-v2-3-1ffa5b6884cb@… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c index 23b9f6efa047..a455a95f65fc 100644 --- a/drivers/ufs/host/ufs-qcom.c +++ b/drivers/ufs/host/ufs-qcom.c @@ -125,7 +125,7 @@ static int ufs_qcom_ice_init(struct ufs_qcom_host *host) int err; int i; - ice = of_qcom_ice_get(dev); + ice = devm_of_qcom_ice_get(dev); if (ice == ERR_PTR(-EOPNOTSUPP)) { dev_warn(dev, "Disabling inline encryption support\n"); ice = NULL;

2 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] scsi: ufs: qcom: fix dev reference leaked through" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x ded40f32b55f7f2f4ed9627dd3c37a1fe89ed8c6 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025041838-sandbag-violation-167f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ded40f32b55f7f2f4ed9627dd3c37a1fe89ed8c6 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus <tudor.ambarus(a)linaro.org> Date: Fri, 17 Jan 2025 14:18:52 +0000 Subject: [PATCH] scsi: ufs: qcom: fix dev reference leaked through of_qcom_ice_get The driver leaks the device reference taken with of_find_device_by_node(). Fix the leak by using devm_of_qcom_ice_get(). Fixes: 56541c7c4468 ("scsi: ufs: ufs-qcom: Switch to the new ICE API") Cc: stable(a)vger.kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus(a)linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Reviewed-by: Abel Vesa <abel.vesa(a)linaro.org> Acked-by: Martin K. Petersen <martin.petersen(a)oracle.com> # SCSI Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Link: https://lore.kernel.org/r/20250117-qcom-ice-fix-dev-leak-v2-3-1ffa5b6884cb@… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c index 23b9f6efa047..a455a95f65fc 100644 --- a/drivers/ufs/host/ufs-qcom.c +++ b/drivers/ufs/host/ufs-qcom.c @@ -125,7 +125,7 @@ static int ufs_qcom_ice_init(struct ufs_qcom_host *host) int err; int i; - ice = of_qcom_ice_get(dev); + ice = devm_of_qcom_ice_get(dev); if (ice == ERR_PTR(-EOPNOTSUPP)) { dev_warn(dev, "Disabling inline encryption support\n"); ice = NULL;

2 months, 1 week

1
0
0 0

Re: Patch "selftests: mptcp: close fd_in before returning in main_loop" has been added to the 5.15-stable tree

by Matthieu Baerts

Hi Greg, On 17/04/2025 15:57, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > selftests: mptcp: close fd_in before returning in main_loop > > to the 5.15-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > selftests-mptcp-close-fd_in-before-returning-in-main_loop.patch > and it can be found in the queue-5.15 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Thank you for having backported this patch to stable, but can it be dropped from the v5.15 queue please (see below)? > From c183165f87a486d5879f782c05a23c179c3794ab Mon Sep 17 00:00:00 2001 > From: Geliang Tang <tanggeliang(a)kylinos.cn> > Date: Fri, 28 Mar 2025 15:27:18 +0100 > Subject: selftests: mptcp: close fd_in before returning in main_loop > > From: Geliang Tang <tanggeliang(a)kylinos.cn> > > commit c183165f87a486d5879f782c05a23c179c3794ab upstream. > > The file descriptor 'fd_in' is opened when cfg_input is configured, but > not closed in main_loop(), this patch fixes it. > > Fixes: 05be5e273c84 ("selftests: mptcp: add disconnect tests") This "Fixes" commit has been introduced in v5.17. From what I see, it has not been backported to v5.15. Cheers, Matt -- Sponsored by the NGI0 Core fund.

2 months, 1 week

2
1
0 0

[tip: x86/urgent] x86/boot/sev: Avoid shared GHCB page for early memory acceptance

by tip-bot2 for Ard Biesheuvel

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: a718833cb4567fffec26bc62633081b27fa5f90a Gitweb: https://git.kernel.org/tip/a718833cb4567fffec26bc62633081b27fa5f90a Author: Ard Biesheuvel <ardb(a)kernel.org> AuthorDate: Thu, 17 Apr 2025 22:21:21 +02:00 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Fri, 18 Apr 2025 09:53:32 +02:00 x86/boot/sev: Avoid shared GHCB page for early memory acceptance Communicating with the hypervisor using the shared GHCB page requires clearing the C bit in the mapping of that page. When executing in the context of the EFI boot services, the page tables are owned by the firmware, and this manipulation is not possible. So switch to a different API for accepting memory in SEV-SNP guests, one which is actually supported at the point during boot where the EFI stub may need to accept memory, but the SEV-SNP init code has not executed yet. For simplicity, also switch the memory acceptance carried out by the decompressor when not booting via EFI - this only involves the allocation for the decompressed kernel, and is generally only called after kexec, as normal boot will jump straight into the kernel from the EFI stub. Fixes: 6c3211796326 ("x86/sev: Add SNP-specific unaccepted memory support") Tested-by: Tom Lendacky <thomas.lendacky(a)amd.com> Co-developed-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: <stable(a)vger.kernel.org> Cc: Dionna Amalie Glaze <dionnaglaze(a)google.com> Cc: Kevin Loughlin <kevinloughlin(a)google.com> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: linux-efi(a)vger.kernel.org Link: https://lore.kernel.org/r/20250404082921.2767593-8-ardb+git@google.com # discussion thread #1 Link: https://lore.kernel.org/r/20250410132850.3708703-2-ardb+git@google.com # discussion thread #2 Link: https://lore.kernel.org/r/20250417202120.1002102-2-ardb+git@google.com # final submission --- arch/x86/boot/compressed/mem.c | 5 +- arch/x86/boot/compressed/sev.c | 67 +++++++-------------------------- arch/x86/boot/compressed/sev.h | 2 +- 3 files changed, 21 insertions(+), 53 deletions(-) diff --git a/arch/x86/boot/compressed/mem.c b/arch/x86/boot/compressed/mem.c index dbba332..f676156 100644 --- a/arch/x86/boot/compressed/mem.c +++ b/arch/x86/boot/compressed/mem.c @@ -34,11 +34,14 @@ static bool early_is_tdx_guest(void) void arch_accept_memory(phys_addr_t start, phys_addr_t end) { + static bool sevsnp; + /* Platform-specific memory-acceptance call goes here */ if (early_is_tdx_guest()) { if (!tdx_accept_memory(start, end)) panic("TDX: Failed to accept memory\n"); - } else if (sev_snp_enabled()) { + } else if (sevsnp || (sev_get_status() & MSR_AMD64_SEV_SNP_ENABLED)) { + sevsnp = true; snp_accept_memory(start, end); } else { error("Cannot accept memory: unknown platform\n"); diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c index bb55934..89ba168 100644 --- a/arch/x86/boot/compressed/sev.c +++ b/arch/x86/boot/compressed/sev.c @@ -164,10 +164,7 @@ bool sev_snp_enabled(void) static void __page_state_change(unsigned long paddr, enum psc_op op) { - u64 val; - - if (!sev_snp_enabled()) - return; + u64 val, msr; /* * If private -> shared then invalidate the page before requesting the @@ -176,6 +173,9 @@ static void __page_state_change(unsigned long paddr, enum psc_op op) if (op == SNP_PAGE_STATE_SHARED) pvalidate_4k_page(paddr, paddr, false); + /* Save the current GHCB MSR value */ + msr = sev_es_rd_ghcb_msr(); + /* Issue VMGEXIT to change the page state in RMP table. */ sev_es_wr_ghcb_msr(GHCB_MSR_PSC_REQ_GFN(paddr >> PAGE_SHIFT, op)); VMGEXIT(); @@ -185,6 +185,9 @@ static void __page_state_change(unsigned long paddr, enum psc_op op) if ((GHCB_RESP_CODE(val) != GHCB_MSR_PSC_RESP) || GHCB_MSR_PSC_RESP_VAL(val)) sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PSC); + /* Restore the GHCB MSR value */ + sev_es_wr_ghcb_msr(msr); + /* * Now that page state is changed in the RMP table, validate it so that it is * consistent with the RMP entry. @@ -195,11 +198,17 @@ static void __page_state_change(unsigned long paddr, enum psc_op op) void snp_set_page_private(unsigned long paddr) { + if (!sev_snp_enabled()) + return; + __page_state_change(paddr, SNP_PAGE_STATE_PRIVATE); } void snp_set_page_shared(unsigned long paddr) { + if (!sev_snp_enabled()) + return; + __page_state_change(paddr, SNP_PAGE_STATE_SHARED); } @@ -223,56 +232,10 @@ static bool early_setup_ghcb(void) return true; } -static phys_addr_t __snp_accept_memory(struct snp_psc_desc *desc, - phys_addr_t pa, phys_addr_t pa_end) -{ - struct psc_hdr *hdr; - struct psc_entry *e; - unsigned int i; - - hdr = &desc->hdr; - memset(hdr, 0, sizeof(*hdr)); - - e = desc->entries; - - i = 0; - while (pa < pa_end && i < VMGEXIT_PSC_MAX_ENTRY) { - hdr->end_entry = i; - - e->gfn = pa >> PAGE_SHIFT; - e->operation = SNP_PAGE_STATE_PRIVATE; - if (IS_ALIGNED(pa, PMD_SIZE) && (pa_end - pa) >= PMD_SIZE) { - e->pagesize = RMP_PG_SIZE_2M; - pa += PMD_SIZE; - } else { - e->pagesize = RMP_PG_SIZE_4K; - pa += PAGE_SIZE; - } - - e++; - i++; - } - - if (vmgexit_psc(boot_ghcb, desc)) - sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PSC); - - pvalidate_pages(desc); - - return pa; -} - void snp_accept_memory(phys_addr_t start, phys_addr_t end) { - struct snp_psc_desc desc = {}; - unsigned int i; - phys_addr_t pa; - - if (!boot_ghcb && !early_setup_ghcb()) - sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PSC); - - pa = start; - while (pa < end) - pa = __snp_accept_memory(&desc, pa, end); + for (phys_addr_t pa = start; pa < end; pa += PAGE_SIZE) + __page_state_change(pa, SNP_PAGE_STATE_PRIVATE); } void sev_es_shutdown_ghcb(void) diff --git a/arch/x86/boot/compressed/sev.h b/arch/x86/boot/compressed/sev.h index fc725a9..4e463f3 100644 --- a/arch/x86/boot/compressed/sev.h +++ b/arch/x86/boot/compressed/sev.h @@ -12,11 +12,13 @@ bool sev_snp_enabled(void); void snp_accept_memory(phys_addr_t start, phys_addr_t end); +u64 sev_get_status(void); #else static inline bool sev_snp_enabled(void) { return false; } static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { } +static inline u64 sev_get_status(void) { return 0; } #endif

2 months, 1 week

1
0
0 0

[PATCH 1/1] usb: gadget: tegra-xudc: ACK ST_RC after clearing CTRL_RUN

by Wayne Chang

We identified a bug where the ST_RC bit in the status register was not being acknowledged after clearing the CTRL_RUN bit in the control register. This could lead to unexpected behavior in the USB gadget drivers. This patch resolves the issue by adding the necessary code to explicitly acknowledge ST_RC after clearing CTRL_RUN based on the programming sequence, ensuring proper state transition. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Cc: stable(a)vger.kernel.org Signed-off-by: Wayne Chang <waynec(a)nvidia.com> --- drivers/usb/gadget/udc/tegra-xudc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/gadget/udc/tegra-xudc.c b/drivers/usb/gadget/udc/tegra-xudc.c index c7fdbc55fb0b..2957316fd3d0 100644 --- a/drivers/usb/gadget/udc/tegra-xudc.c +++ b/drivers/usb/gadget/udc/tegra-xudc.c @@ -1749,6 +1749,10 @@ static int __tegra_xudc_ep_disable(struct tegra_xudc_ep *ep) val = xudc_readl(xudc, CTRL); val &= ~CTRL_RUN; xudc_writel(xudc, val, CTRL); + + val = xudc_readl(xudc, ST); + if (val & ST_RC) + xudc_writel(xudc, ST_RC, ST); } dev_info(xudc->dev, "ep %u disabled\n", ep->index); -- 2.25.1

2 months, 1 week

1
0
0 0

Re: Question about back-porting '8be091338971 crypto: hisilicon/debugfs - Fix debugfs uninit process issue'

by Cliff Liu

Hi, I think this patch is not applicable for 5.15 and 5.10. Could you give me any opinions? Any helps from maintainers are very appreciated. Thanks, Cliff On 2025/4/8 15:45, Cliff Liu wrote: > Hi Chenghai, > > I am trying to back-port commit 8be091338971 ("crypto: > hisilicon/debugfs - Fix debugfs uninit process issue") to 5.15.y and > 5.10.y. After reviewed the patch and code context, I found there is > no "drivers/crypto/hisilicon/debugfs.c" on both 5.15 and 5.10. So I > think the fix is not suitable for 5.15 and 5.10. > > What do you think? Your opinion is very important to me. > > Thanks, > > Cliff >

2 months, 1 week

3
7
0 0

Re: [PATCH 6.14 197/449] HID: pidff: Stop all effects before enabling actuators

by Greg Kroah-Hartman

On Thu, Apr 17, 2025 at 08:47:05PM +0200, Jules Noirant wrote: > Hi, > > Thanks for the review. Technically, that patch should at least be Co-authored by me since it's a slightly reworded rebase of a patch I submitted last year: https://lore.kernel.org/lkml/20240304195745.10195-1-jules.noirant@orange.fr… This is just a copy of what went into Linus's tree, sorry. greg k-h

2 months, 1 week

1
0
0 0

[merged mm-hotfixes-stable] writeback-fix-false-warning-in-inode_to_wb.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: writeback: fix false warning in inode_to_wb() has been removed from the -mm tree. Its filename was writeback-fix-false-warning-in-inode_to_wb.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Andreas Gruenbacher <agruenba(a)redhat.com> Subject: writeback: fix false warning in inode_to_wb() Date: Sat, 12 Apr 2025 18:39:12 +0200 inode_to_wb() is used also for filesystems that don't support cgroup writeback. For these filesystems inode->i_wb is stable during the lifetime of the inode (it points to bdi->wb) and there's no need to hold locks protecting the inode->i_wb dereference. Improve the warning in inode_to_wb() to not trigger for these filesystems. Link: https://lkml.kernel.org/r/20250412163914.3773459-3-agruenba@redhat.com Fixes: aaa2cacf8184 ("writeback: add lockdep annotation to inode_to_wb()") Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Reviewed-by: Andreas Gruenbacher <agruenba(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/backing-dev.h | 1 + 1 file changed, 1 insertion(+) --- a/include/linux/backing-dev.h~writeback-fix-false-warning-in-inode_to_wb +++ a/include/linux/backing-dev.h @@ -249,6 +249,7 @@ static inline struct bdi_writeback *inod { #ifdef CONFIG_LOCKDEP WARN_ON_ONCE(debug_locks && + (inode->i_sb->s_iflags & SB_I_CGROUPWB) && (!lockdep_is_held(&inode->i_lock) && !lockdep_is_held(&inode->i_mapping->i_pages.xa_lock) && !lockdep_is_held(&inode->i_wb->list_lock))); _ Patches currently in -mm which might be from agruenba(a)redhat.com are

2 months, 1 week

1
0
0 0

[merged mm-hotfixes-stable] mm-gup-fix-wrongly-calculated-returned-value-in-fault_in_safe_writeable.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/gup: fix wrongly calculated returned value in fault_in_safe_writeable() has been removed from the -mm tree. Its filename was mm-gup-fix-wrongly-calculated-returned-value-in-fault_in_safe_writeable.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Baoquan He <bhe(a)redhat.com> Subject: mm/gup: fix wrongly calculated returned value in fault_in_safe_writeable() Date: Thu, 10 Apr 2025 11:57:14 +0800 Not like fault_in_readable() or fault_in_writeable(), in fault_in_safe_writeable() local variable 'start' is increased page by page to loop till the whole address range is handled. However, it mistakenly calculates the size of the handled range with 'uaddr - start'. Fix it here. Andreas said: : In gfs2, fault_in_iov_iter_writeable() is used in : gfs2_file_direct_read() and gfs2_file_read_iter(), so this potentially : affects buffered as well as direct reads. This bug could cause those : gfs2 functions to spin in a loop. Link: https://lkml.kernel.org/r/20250410035717.473207-1-bhe@redhat.com Link: https://lkml.kernel.org/r/20250410035717.473207-2-bhe@redhat.com Signed-off-by: Baoquan He <bhe(a)redhat.com> Fixes: fe673d3f5bf1 ("mm: gup: make fault_in_safe_writeable() use fixup_user_fault()") Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Andreas Gruenbacher <agruenba(a)redhat.com> Cc: Yanjun.Zhu <yanjun.zhu(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/gup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/gup.c~mm-gup-fix-wrongly-calculated-returned-value-in-fault_in_safe_writeable +++ a/mm/gup.c @@ -2207,8 +2207,8 @@ size_t fault_in_safe_writeable(const cha } while (start != end); mmap_read_unlock(mm); - if (size > (unsigned long)uaddr - start) - return size - ((unsigned long)uaddr - start); + if (size > start - (unsigned long)uaddr) + return size - (start - (unsigned long)uaddr); return 0; } EXPORT_SYMBOL(fault_in_safe_writeable); _ Patches currently in -mm which might be from bhe(a)redhat.com are mm-gup-remove-unneeded-checking-in-follow_page_pte.patch mm-gup-remove-gup_fast_pgd_leaf-and-clean-up-the-relevant-codes.patch mm-gup-clean-up-codes-in-fault_in_xxx-functions.patch mm-gup-clean-up-codes-in-fault_in_xxx-functions-v5.patch

2 months, 1 week

1
0
0 0

[PATCH] iommu: intel: apply quirk_iommu_igfx for 8086:0044 (QM57/QS57)

by Mingcong Bai

On the Lenovo ThinkPad X201, when Intel VT-d is enabled in the BIOS, the kernel boots with errors related to DMAR, the graphical interface appeared quite choppy, and the system resets erratically within a minute after it booted: DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Write NO_PASID] Request device [00:02.0] fault addr 0xb97ff000 [fault reason 0x05] PTE Write access is not set Upon comparing boot logs with VT-d on/off, I found that the Intel Calpella quirk (`quirk_calpella_no_shadow_gtt()') correctly applied the igfx IOMMU disable/quirk correctly: pci 0000:00:00.0: DMAR: BIOS has allocated no shadow GTT; disabling IOMMU for graphics Whereas with VT-d on, it went into the "else" branch, which then triggered the DMAR handling fault above: ... else if (!disable_igfx_iommu) { /* we have to ensure the gfx device is idle before we flush */ pci_info(dev, "Disabling batched IOTLB flush on Ironlake\n"); iommu_set_dma_strict(); } Now, this is not exactly scientific, but moving 0x0044 to quirk_iommu_igfx seems to have fixed the aforementioned issue. Running a few `git blame' runs on the function, I have found that the quirk was originally introduced as a fix specific to ThinkPad X201: commit 9eecabcb9a92 ("intel-iommu: Abort IOMMU setup for igfx if BIOS gave no shadow GTT space") Which was later revised twice to the "else" branch we saw above: - 2011: commit 6fbcfb3e467a ("intel-iommu: Workaround IOTLB hang on Ironlake GPU") - 2024: commit ba00196ca41c ("iommu/vt-d: Decouple igfx_off from graphic identity mapping") I'm uncertain whether further testings on this particular laptops were done in 2011 and (honestly I'm not sure) 2024, but I would be happy to do some distro-specific testing if that's what would be required to verify this patch. P.S., I also see IDs 0x0040, 0x0062, and 0x006a listed under the same `quirk_calpella_no_shadow_gtt()' quirk, but I'm not sure how similar these chipsets are (if they share the same issue with VT-d or even, indeed, if this issue is specific to a bug in the Lenovo BIOS). With regards to 0x0062, it seems to be a Centrino wireless card, but not a chipset? I have also listed a couple (distro and kernel) bug reports below as references (some of them are from 7-8 years ago!), as they seem to be similar issue found on different Westmere/Ironlake, Haswell, and Broadwell hardware setups. Cc: stable(a)vger.kernel.org Fixes: 6fbcfb3e467a ("intel-iommu: Workaround IOTLB hang on Ironlake GPU") Fixes: ba00196ca41c ("iommu/vt-d: Decouple igfx_off from graphic identity mapping") Link: https://bugzilla.kernel.org/show_bug.cgi?id=197029 Link: https://groups.google.com/g/qubes-users/c/4NP4goUds2c?pli=1 Link: https://bugs.archlinux.org/task/65362 Link: https://bbs.archlinux.org/viewtopic.php?id=230323 Reported-by: Wenhao Sun <weiguangtwk(a)outlook.com> Signed-off-by: Mingcong Bai <jeffbai(a)aosc.io> --- drivers/iommu/intel/iommu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index b29da2d96d0b..64935e14b9ec 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -4432,6 +4432,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_igfx); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_igfx); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_igfx); +/* QM57/QS57 integrated gfx malfunctions with dmar */ +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044, quirk_iommu_igfx); + /* Broadwell igfx malfunctions with dmar */ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1606, quirk_iommu_igfx); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x160B, quirk_iommu_igfx); @@ -4509,7 +4512,6 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev) } } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0040, quirk_calpella_no_shadow_gtt); -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044, quirk_calpella_no_shadow_gtt); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062, quirk_calpella_no_shadow_gtt); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a, quirk_calpella_no_shadow_gtt); -- 2.49.0

2 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025