October 2023 - Linux-stable-mirror

[tip: x86/platform] x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDs

by tip-bot2 for Yazen Ghannam

The following commit has been merged into the x86/platform branch of tip: Commit-ID: 2a565258b3f4bbdc7a3c09cd02082cb286a7bffc Gitweb: https://git.kernel.org/tip/2a565258b3f4bbdc7a3c09cd02082cb286a7bffc Author: Yazen Ghannam <yazen.ghannam(a)amd.com> AuthorDate: Thu, 03 Aug 2023 10:04:30 -05:00 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Tue, 03 Oct 2023 11:25:01 +02:00 x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDs Three PCI IDs for DF Function 4 were defined but not used. Add them to the "link" list. Fixes: f8faf3496633 ("x86/amd_nb: Add AMD PCI IDs for SMN communication") Fixes: 23a5b8bb022c ("x86/amd_nb: Add PCI ID for family 19h model 78h") Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20230803150430.3542854-1-yazen.ghannam@amd.com --- arch/x86/kernel/amd_nb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c index 10c2a3c..43238ac 100644 --- a/arch/x86/kernel/amd_nb.c +++ b/arch/x86/kernel/amd_nb.c @@ -116,6 +116,9 @@ static const struct pci_device_id amd_nb_link_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M10H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M40H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M50H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M60H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M70H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M78H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M00H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_MI200_DF_F4) },

9 months, 3 weeks

1
0
0 0

[PATCH v2 2/2] arm64: dts: mt7986: fix emmc hs400 mode without uboot initialization

by Frank Wunderlich

From: Eric Woudstra <ericwouds(a)gmail.com> Eric reports errors on emmc with hs400 mode when booting linux on bpi-r3 without uboot [1]. Booting with uboot does not show this because clocks seem to be initialized by uboot. Fix this by adding assigned-clocks and assigned-clock-parents like it's done in uboot [2]. [1] https://forum.banana-pi.org/t/bpi-r3-kernel-fails-setting-emmc-clock-to-416… [2] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/mt7986.dtsi#L287 Cc: stable(a)vger.kernel.org Fixes: 513b49d19b34 ("arm64: dts: mt7986: add mmc related device nodes") Signed-off-by: Eric Woudstra <ericwouds(a)gmail.com> Signed-off-by: Frank Wunderlich <frank-w(a)public-files.de> --- arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi index 68539ea788df..207510abda89 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi @@ -374,6 +374,10 @@ mmc0: mmc@11230000 { reg = <0 0x11230000 0 0x1000>, <0 0x11c20000 0 0x1000>; interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; + assigned-clocks = <&topckgen CLK_TOP_EMMC_416M_SEL>, + <&topckgen CLK_TOP_EMMC_250M_SEL>; + assigned-clock-parents = <&apmixedsys CLK_APMIXED_MPLL>, + <&topckgen CLK_TOP_NET1PLL_D5_D2>; clocks = <&topckgen CLK_TOP_EMMC_416M_SEL>, <&infracfg CLK_INFRA_MSDC_HCK_CK>, <&infracfg CLK_INFRA_MSDC_CK>, -- 2.34.1

9 months, 3 weeks

3
2
0 0

[PULL 01/24] optionrom: Remove build-id section

by Paolo Bonzini

From: Fabiano Rosas <farosas(a)suse.de> Our linker script for optionroms specifies only the placement of the .text section, leaving the linker free to place the remaining sections at arbitrary places in the file. Since at least binutils 2.39, the .note.gnu.build-id section is now being placed at the start of the file, which causes label addresses to be shifted. For linuxboot_dma.bin that means that the PnP header (among others) will not be found when determining the type of ROM at optionrom_setup(): (0x1c is the label _pnph, where the magic "PnP" is) $ xxd /usr/share/qemu/linuxboot_dma.bin | grep "PnP" 00000010: 0000 0000 0000 0000 0000 1c00 2450 6e50 ............$PnP $ xxd pc-bios/optionrom/linuxboot_dma.bin | grep "PnP" 00000010: 0000 0000 0000 0000 0000 4c00 2450 6e50 ............$PnP ^bad Using a freshly built linuxboot_dma.bin ROM results in a broken boot: SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org) Booting from Hard Disk... Boot failed: could not read the boot disk Booting from Floppy... Boot failed: could not read the boot disk No bootable device. We're not using the build-id section, so pass the --build-id=none option to the linker to remove it entirely. Note: In theory, this same issue could happen with any other section. The ideal solution would be to have all unused sections discarded in the linker script. However that would be a larger change, specially for the pvh rom which uses the .bss and COMMON sections so I'm addressing only the immediate issue here. Reported-by: Vasiliy Ulyanov <vulyanov(a)suse.de> Signed-off-by: Fabiano Rosas <farosas(a)suse.de> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Message-ID: <20230926192502.15986-1-farosas(a)suse.de> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- pc-bios/optionrom/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile index b1fff0ba6c8..30d07026c79 100644 --- a/pc-bios/optionrom/Makefile +++ b/pc-bios/optionrom/Makefile @@ -36,7 +36,7 @@ config-cc.mak: Makefile $(call cc-option,-Wno-array-bounds)) 3> config-cc.mak -include config-cc.mak -override LDFLAGS = -nostdlib -Wl,-T,$(SRC_DIR)/flat.lds +override LDFLAGS = -nostdlib -Wl,--build-id=none,-T,$(SRC_DIR)/flat.lds pvh.img: pvh.o pvh_main.o -- 2.41.0

9 months, 3 weeks

1
0
0 0

Letter of Intent (LOI) (03-10-2023)

by Ahmad R Deeb

Attn: stable(a)vger.kernel.org Date: 03-10-2023 Subject: Letter of Intent (LOI) (03-10-2023) This is a Letter of Intent concerning my Board of investors intent to fund some of your available investment projects. If this is of any interest to you then kindly advise. Yours Faithfully, Ahmad R. Deeb Head of Investment Team

9 months, 3 weeks

1
0
0 0

[PATCH v2 1/4] x86: KVM: SVM: always update the x2avic msr interception

by Maxim Levitsky

The following problem exists since x2avic was enabled in the KVM: svm_set_x2apic_msr_interception is called to enable the interception of the x2apic msrs. In particular it is called at the moment the guest resets its apic. Assuming that the guest's apic was in x2apic mode, the reset will bring it back to the xapic mode. The svm_set_x2apic_msr_interception however has an erroneous check for '!apic_x2apic_mode()' which prevents it from doing anything in this case. As a result of this, all x2apic msrs are left unintercepted, and that exposes the bare metal x2apic (if enabled) to the guest. Oops. Remove the erroneous '!apic_x2apic_mode()' check to fix that. This fixes CVE-2023-5090 Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable(a)vger.kernel.org Signed-off-by: Maxim Levitsky <mlevitsk(a)redhat.com> --- arch/x86/kvm/svm/svm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 9507df93f410a63..acdd0b89e4715a3 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -913,8 +913,7 @@ void svm_set_x2apic_msr_interception(struct vcpu_svm *svm, bool intercept) if (intercept == svm->x2avic_msrs_intercepted) return; - if (!x2avic_enabled || - !apic_x2apic_mode(svm->vcpu.arch.apic)) + if (!x2avic_enabled) return; for (i = 0; i < MAX_DIRECT_ACCESS_MSRS; i++) { -- 2.26.3

9 months, 3 weeks

3
2
0 0

[PATCH] rcu: kmemleak: Ignore kmemleak false positives when RCU-freeing objects

by Joel Fernandes (Google)

From: Catalin Marinas <catalin.marinas(a)arm.com> Since the actual slab freeing is deferred when calling kvfree_rcu(), so is the kmemleak_free() callback informing kmemleak of the object deletion. From the perspective of the kvfree_rcu() caller, the object is freed and it may remove any references to it. Since kmemleak does not scan RCU internal data storing the pointer, it will report such objects as leaks during the grace period. Tell kmemleak to ignore such objects on the kvfree_call_rcu() path. Note that the tiny RCU implementation does not have such issue since the objects can be tracked from the rcu_ctrlblk structure. Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://lore.kernel.org/all/F903A825-F05F-4B77-A2B5-7356282FBA2C@apple.com/ Cc: <stable(a)vger.kernel.org> Tested-by: Christoph Paasch <cpaasch(a)apple.com> Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> --- kernel/rcu/tree.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index cb1caefa8bd0..24423877962c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -31,6 +31,7 @@ #include <linux/bitops.h> #include <linux/export.h> #include <linux/completion.h> +#include <linux/kmemleak.h> #include <linux/moduleparam.h> #include <linux/panic.h> #include <linux/panic_notifier.h> @@ -3388,6 +3389,14 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr) success = true; } + /* + * The kvfree_rcu() caller considers the pointer freed at this point + * and likely removes any references to it. Since the actual slab + * freeing (and kmemleak_free()) is deferred, tell kmemleak to ignore + * this object (no scanning or false positives reporting). + */ + kmemleak_ignore(ptr); + // Set timer to drain after KFREE_DRAIN_JIFFIES. if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING) schedule_delayed_monitor_work(krcp); -- 2.42.0.582.g8ccd20d70d-goog

9 months, 4 weeks

2
1
0 0

Re: [PATCH] usb: dwc3: Soft reset phy on probe for host

by Da Xue

Hi Thinh, I can confirm your patch fixed the issue on RK3399 when I was running on Linux 6.1.54. I'm not on the ML for this so I'm sorry if this email causes any issue as I'm not sure how to reply to a thread from a ML I am not on. Best, Da

9 months, 4 weeks

2
1
0 0

[PATCH v4] ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM

by Sven Frotscher

Like the Lenovo 82TL, 82V2, 82QF and 82UG, the 82YM (Yoga 7 14ARP8) requires an entry in the quirk list to enable the internal microphone. The latter two received similar fixes in commit 1263cc0f414d ("ASoC: amd: yc: Fix non-functional mic on Lenovo 82QF and 82UG"). Fixes: c008323fe361 ("ASoC: amd: yc: Fix a non-functional mic on Lenovo 82SJ") Cc: stable(a)vger.kernel.org Signed-off-by: Sven Frotscher <sven.frotscher(a)gmail.com> --- v3->v4 changes: * re-add blank line between commit message title and body --- v2->v3 changes: * add message title of referenced commit to commit message * make whitespace consistent with surrounding code * use a patch-friendly e-mail client --- v1->v2 changes: * add Fixes and Cc tags to commit message * remove redundant LKML link from commit message * fix mangled diff --- sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 94e9eb8e73f2..15a864dcd7bd 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -241,6 +241,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "82V2"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_NAME, "82YM"), + } + }, { .driver_data = &acp6x_card, .matches = { -- 2.42.0

9 months, 4 weeks

4
14
0 0

[merged] i915-limit-the-length-of-an-sg-list-to-the-requested-length.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: i915: limit the length of an sg list to the requested length has been removed from the -mm tree. Its filename was i915-limit-the-length-of-an-sg-list-to-the-requested-length.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: "Matthew Wilcox (Oracle)" <willy(a)infradead.org> Subject: i915: limit the length of an sg list to the requested length Date: Tue, 19 Sep 2023 20:48:55 +0100 The folio conversion changed the behaviour of shmem_sg_alloc_table() to put the entire length of the last folio into the sg list, even if the sg list should have been shorter. gen8_ggtt_insert_entries() relied on the list being the right length and would overrun the end of the page tables. Other functions may also have been affected. Clamp the length of the last entry in the sg list to be the expected length. Link: https://lkml.kernel.org/r/20230919194855.347582-1-willy@infradead.org Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9256 Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch") Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Reported-by: Oleksandr Natalenko <oleksandr(a)natalenko.name> Closes: https://lore.kernel.org/lkml/6287208.lOV4Wx5bFT@natalenko.name/ Tested-by: Oleksandr Natalenko <oleksandr(a)natalenko.name> Reviewed-by: Andrzej Hajda <andrzej.hajda(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> [6.5.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c~i915-limit-the-length-of-an-sg-list-to-the-requested-length +++ a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -100,6 +100,7 @@ int shmem_sg_alloc_table(struct drm_i915 st->nents = 0; for (i = 0; i < page_count; i++) { struct folio *folio; + unsigned long nr_pages; const unsigned int shrink[] = { I915_SHRINK_BOUND | I915_SHRINK_UNBOUND, 0, @@ -150,6 +151,8 @@ int shmem_sg_alloc_table(struct drm_i915 } } while (1); + nr_pages = min_t(unsigned long, + folio_nr_pages(folio), page_count - i); if (!i || sg->length >= max_segment || folio_pfn(folio) != next_pfn) { @@ -157,13 +160,13 @@ int shmem_sg_alloc_table(struct drm_i915 sg = sg_next(sg); st->nents++; - sg_set_folio(sg, folio, folio_size(folio), 0); + sg_set_folio(sg, folio, nr_pages * PAGE_SIZE, 0); } else { /* XXX: could overflow? */ - sg->length += folio_size(folio); + sg->length += nr_pages * PAGE_SIZE; } - next_pfn = folio_pfn(folio) + folio_nr_pages(folio); - i += folio_nr_pages(folio) - 1; + next_pfn = folio_pfn(folio) + nr_pages; + i += nr_pages - 1; /* Check that the i965g/gm workaround works. */ GEM_BUG_ON(gfp & __GFP_DMA32 && next_pfn >= 0x00100000UL); _ Patches currently in -mm which might be from willy(a)infradead.org are mm-convert-dax-lock-unlock-page-to-lock-unlock-folio.patch buffer-pass-gfp-flags-to-folio_alloc_buffers.patch buffer-hoist-gfp-flags-from-grow_dev_page-to-__getblk_gfp.patch buffer-hoist-gfp-flags-from-grow_dev_page-to-__getblk_gfp-fix.patch ext4-use-bdev_getblk-to-avoid-memory-reclaim-in-readahead-path.patch buffer-use-bdev_getblk-to-avoid-memory-reclaim-in-readahead-path.patch buffer-convert-getblk_unmovable-and-__getblk-to-use-bdev_getblk.patch buffer-convert-sb_getblk-to-call-__getblk.patch ext4-call-bdev_getblk-from-sb_getblk_gfp.patch buffer-remove-__getblk_gfp.patch hugetlb-use-a-folio-in-free_hpage_workfn.patch hugetlb-remove-a-few-calls-to-page_folio.patch hugetlb-convert-remove_pool_huge_page-to-remove_pool_hugetlb_folio.patch mm-make-lock_folio_maybe_drop_mmap-vma-lock-aware.patch mm-call-wp_page_copy-under-the-vma-lock.patch mm-handle-shared-faults-under-the-vma-lock.patch mm-handle-cow-faults-under-the-vma-lock.patch mm-handle-read-faults-under-the-vma-lock.patch mm-handle-write-faults-to-ro-pages-under-the-vma-lock.patch

9 months, 4 weeks

1
0
0 0

[PATCH v2] can: sja1000: Always restart the Tx queue after an overrun

by Miquel Raynal

Upstream commit 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs") fixes an issue with Renesas own SJA1000 CAN controller reception: the Rx buffer is only 5 messages long, so when the bus loaded (eg. a message every 50us), overrun may easily happen. Upon an overrun situation, due to a possible internal crosstalk situation, the controller enters a frozen state which only can be unlocked with a soft reset (experimentally). The solution was to offload a call to sja1000_start() in a threaded handler. This needs to happen in process context as this operation requires to sleep. sja1000_start() basically enters "reset mode", performs a proper software reset and returns back into "normal mode". Since this fix was introduced, we no longer observe any stalls in reception. However it was sporadically observed that the transmit path would now freeze. Further investigation blamed the fix mentioned above, and especially the reset operation. Reproducing the reset in a loop helped identifying what could possibly go wrong. The sja1000 is a single Tx queue device, which leverages the netdev helpers to process one Tx message at a time. The logic is: the queue is stopped, the message sent to the transceiver, once properly transmitted the controller sets a status bit which triggers an interrupt, in the interrupt handler the transmission status is checked and the queue woken up. Unfortunately, if an overrun happens, we might perform the soft reset precisely between the transmission of the buffer to the transceiver and the advent of the transmission status bit. We would then stop the transmission operation without re-enabling the queue, leading to all further transmissions to be ignored. The reset interrupt can only happen while the device is "open", and after a reset we anyway want to resume normal operations, no matter if a packet to transmit got dropped in the process, so we shall wake up the queue. Restarting the device and waking-up the queue is exactly what sja1000_set_mode(CAN_MODE_START) does. In order to be consistent about the queue state, we must acquire a lock both in the reset handler and in the transmit path to ensure serialization of both operations. As the reset handler might still be called after the transmission of a frame to the transceiver but before it actually gets transmitted, we must ensure we don't leak the skb, so we free it (the behavior is consistent, no matter if there was an skb on the stack or not). Fixes: 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- Changes in v2: * As Marc sugested, use netif_tx_{,un}lock() instead of our own spin_lock. drivers/net/can/sja1000/sja1000.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c index ae47fc72aa96..91e3fb3eed20 100644 --- a/drivers/net/can/sja1000/sja1000.c +++ b/drivers/net/can/sja1000/sja1000.c @@ -297,6 +297,7 @@ static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb, if (can_dropped_invalid_skb(dev, skb)) return NETDEV_TX_OK; + netif_tx_lock(dev); netif_stop_queue(dev); fi = dlc = cf->can_dlc; @@ -335,6 +336,8 @@ static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb, sja1000_write_cmdreg(priv, cmd_reg_val); + netif_tx_unlock(dev); + return NETDEV_TX_OK; } @@ -396,7 +399,13 @@ static irqreturn_t sja1000_reset_interrupt(int irq, void *dev_id) struct net_device *dev = (struct net_device *)dev_id; netdev_dbg(dev, "performing a soft reset upon overrun\n"); - sja1000_start(dev); + + netif_tx_lock(dev); + + can_free_echo_skb(dev, 0); + sja1000_set_mode(dev, CAN_MODE_START); + + netif_tx_unlock(dev); return IRQ_HANDLED; } -- 2.34.1

9 months, 4 weeks

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023