- Linux-stable-mirror - lists.linaro.org

[PATCH 6.1.y] spi-rockchip: Fix register out of bounds access

by Vasiliy Kovalev

From: Luis de Arquer <luis.dearquer(a)inertim.com> commit 7a874e8b54ea21094f7fd2d428b164394c6cb316 upstream. Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense. Fixes: 736b81e07517 ("spi: rockchip: Support SPI_CS_HIGH") Signed-off-by: Luis de Arquer <luis.dearquer(a)inertim.com> Link: https://patch.msgid.link/365ccddfba110549202b3520f4401a6a936e82a8.camel@gma… Signed-off-by: Mark Brown <broonie(a)kernel.org> [ kovalev: bp to fix CVE-2025-38081; added Fixes tag ] Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- drivers/spi/spi-rockchip.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c index dbefc7e77313..cba858a7b4f9 100644 --- a/drivers/spi/spi-rockchip.c +++ b/drivers/spi/spi-rockchip.c @@ -540,8 +540,8 @@ static int rockchip_spi_config(struct rockchip_spi *rs, cr0 |= (spi->mode & 0x3U) << CR0_SCPH_OFFSET; if (spi->mode & SPI_LSB_FIRST) cr0 |= CR0_FBM_LSB << CR0_FBM_OFFSET; - if (spi->mode & SPI_CS_HIGH) - cr0 |= BIT(spi->chip_select) << CR0_SOI_OFFSET; + if ((spi->mode & SPI_CS_HIGH) && !(spi_get_csgpiod(spi, 0))) + cr0 |= BIT(spi_get_chipselect(spi, 0)) << CR0_SOI_OFFSET; if (xfer->rx_buf && xfer->tx_buf) cr0 |= CR0_XFM_TR << CR0_XFM_OFFSET; -- 2.50.1

2 months

1
0
0 0

Security alert for linux-stable-mirror@lists.linaro.org

by Cpanel Adminlists.linaro.org

2 months

1
0
0 0

+ mm-swap-do-not-perform-synchronous-discard-during-allocation.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm, swap: do not perform synchronous discard during allocation has been added to the -mm mm-new branch. Its filename is mm-swap-do-not-perform-synchronous-discard-during-allocation.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kairui Song <kasong(a)tencent.com> Subject: mm, swap: do not perform synchronous discard during allocation Date: Fri, 24 Oct 2025 02:34:11 +0800 Patch series "mm, swap: misc cleanup and bugfix", v2. A few cleanups and a bugfix that are either suitable after the swap table phase I or found during code review. Patch 1 is a bugfix and needs to be included in the stable branch, the rest have no behavioral change. This patch (of 5): Since commit 1b7e90020eb77 ("mm, swap: use percpu cluster as allocation fast path"), swap allocation is protected by a local lock, which means we can't do any sleeping calls during allocation. However, the discard routine is not taken well care of. When the swap allocator failed to find any usable cluster, it would look at the pending discard cluster and try to issue some blocking discards. It may not necessarily sleep, but the cond_resched at the bio layer indicates this is wrong when combined with a local lock. And the bio GFP flag used for discard bio is also wrong (not atomic). It's arguable whether this synchronous discard is helpful at all. In most cases, the async discard is good enough. And the swap allocator is doing very differently at organizing the clusters since the recent change, so it is very rare to see discard clusters piling up. So far, no issues have been observed or reported with typical SSD setups under months of high pressure. This issue was found during my code review. But by hacking the kernel a bit: adding a mdelay(500) in the async discard path, this issue will be observable with WARNING triggered by the wrong GFP and cond_resched in the bio layer for debug builds. So now let's apply a hotfix for this issue: remove the synchronous discard in the swap allocation path. And when order 0 is failing with all cluster list drained on all swap devices, try to do a discard following the swap device priority list. If any discards released some cluster, try the allocation again. This way, we can still avoid OOM due to swap failure if the hardware is very slow and memory pressure is extremely high. This may cause more fragmentation issues if the discarding hardware is really slow. Ideally, we want to discard pending clusters before continuing to iterate the fragment cluster lists. This can be implemented in a cleaner way if we clean up the device list iteration part first. Link: https://lkml.kernel.org/r/20251024-swap-clean-after-swap-table-p1-v2-0-a709… Link: https://lkml.kernel.org/r/20251024-swap-clean-after-swap-table-p1-v2-1-c5b0… Fixes: 1b7e90020eb77 ("mm, swap: use percpu cluster as allocation fast path") Signed-off-by: Kairui Song <kasong(a)tencent.com> Acked-by: Nhat Pham <nphamcs(a)gmail.com> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Chris Li <chrisl(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: "Huang, Ying" <ying.huang(a)linux.alibaba.com> Cc: Kemeng Shi <shikemeng(a)huaweicloud.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swapfile.c | 40 +++++++++++++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 7 deletions(-) --- a/mm/swapfile.c~mm-swap-do-not-perform-synchronous-discard-during-allocation +++ a/mm/swapfile.c @@ -1101,13 +1101,6 @@ new_cluster: goto done; } - /* - * We don't have free cluster but have some clusters in discarding, - * do discard now and reclaim them. - */ - if ((si->flags & SWP_PAGE_DISCARD) && swap_do_scheduled_discard(si)) - goto new_cluster; - if (order) goto done; @@ -1394,6 +1387,33 @@ start_over: return false; } +/* + * Discard pending clusters in a synchronized way when under high pressure. + * Return: true if any cluster is discarded. + */ +static bool swap_sync_discard(void) +{ + bool ret = false; + int nid = numa_node_id(); + struct swap_info_struct *si, *next; + + spin_lock(&swap_avail_lock); + plist_for_each_entry_safe(si, next, &swap_avail_heads[nid], avail_lists[nid]) { + spin_unlock(&swap_avail_lock); + if (get_swap_device_info(si)) { + if (si->flags & SWP_PAGE_DISCARD) + ret = swap_do_scheduled_discard(si); + put_swap_device(si); + } + if (ret) + return true; + spin_lock(&swap_avail_lock); + } + spin_unlock(&swap_avail_lock); + + return false; +} + /** * folio_alloc_swap - allocate swap space for a folio * @folio: folio we want to move to swap @@ -1432,11 +1452,17 @@ int folio_alloc_swap(struct folio *folio } } +again: local_lock(&percpu_swap_cluster.lock); if (!swap_alloc_fast(&entry, order)) swap_alloc_slow(&entry, order); local_unlock(&percpu_swap_cluster.lock); + if (unlikely(!order && !entry.val)) { + if (swap_sync_discard()) + goto again; + } + /* Need to call this even if allocation failed, for MEMCG_SWAP_FAIL. */ if (mem_cgroup_try_charge_swap(folio, entry)) goto out_free; _ Patches currently in -mm which might be from kasong(a)tencent.com are mm-shmem-fix-thp-allocation-and-fallback-loop.patch mm-swap-do-not-perform-synchronous-discard-during-allocation.patch mm-swap-rename-helper-for-setup-bad-slots.patch mm-swap-cleanup-swap-entry-allocation-parameter.patch mm-migrate-swap-drop-usage-of-folio_index.patch mm-swap-remove-redundant-argument-for-isolating-a-cluster.patch

2 months

1
0
0 0

[PATCH v3] ACPI: video: Fix use-after-free in acpi_video_switch_brightness()

by Yuhao Jiang

The switch_brightness_work delayed work accesses device->brightness and device->backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. Fixes: 8ab58e8e7e097 ("ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress") Cc: stable(a)vger.kernel.org Signed-off-by: Yuhao Jiang <danisjiang(a)gmail.com> --- Changes in v3: - Move cancel_delayed_work_sync() to acpi_video_bus_remove_notify_handler() instead of acpi_video_bus_unregister_backlight() for better logic placement - Link to v2: https://lore.kernel.org/all/20251022042514.2167599-1-danisjiang@gmail.com/ --- drivers/acpi/acpi_video.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index 103f29661576..be8e7e18abca 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -1959,8 +1959,10 @@ static void acpi_video_bus_remove_notify_handler(struct acpi_video_bus *video) struct acpi_video_device *dev; mutex_lock(&video->device_list_lock); - list_for_each_entry(dev, &video->video_device_list, entry) + list_for_each_entry(dev, &video->video_device_list, entry) { acpi_video_dev_remove_notify_handler(dev); + cancel_delayed_work_sync(&dev->switch_brightness_work); + } mutex_unlock(&video->device_list_lock); acpi_video_bus_stop_devices(video); -- 2.34.1

2 months

3
2
0 0

[PATCH v1] riscv: dts: microchip: remove BeagleV Fire fabric.dtsi

by Conor Dooley

From: Conor Dooley <conor.dooley(a)microchip.com> At the time of adding the fabric.dtsi for the BeagleV Fire, we thought that the fabric nodes in the Beagle supplied images were stable. They are not, which has lead to nodes present in the devicetree that are not in the programmed FPGA images. This is obviously problematic, and these nodes must be removed. CC: stable(a)vger.kernel.org Fixes: 3f41368fbfe1 ("riscv: dts: microchip: add an initial devicetree for the BeagleV Fire") Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> -- CC: Valentina.FernandezAlanis(a)microchip.com CC: Cyril.Jean(a)microchip.com CC: Conor Dooley <conor(a)kernel.org> CC: Daire McNamara <daire.mcnamara(a)microchip.com> CC: Rob Herring <robh(a)kernel.org> CC: Krzysztof Kozlowski <krzk+dt(a)kernel.org> CC: Paul Walmsley <paul.walmsley(a)sifive.com> CC: Jamie Gibbons <jamie.gibbons(a)microchip.com> CC: linux-riscv(a)lists.infradead.org CC: devicetree(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org --- .../microchip/mpfs-beaglev-fire-fabric.dtsi | 82 ------------------- .../boot/dts/microchip/mpfs-beaglev-fire.dts | 5 -- 2 files changed, 87 deletions(-) delete mode 100644 arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi diff --git a/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi b/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi deleted file mode 100644 index e153eaf9b90e..000000000000 --- a/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi +++ /dev/null @@ -1,82 +0,0 @@ -// SPDX-License-Identifier: (GPL-2.0 OR MIT) - -/ { - fabric_clk3: fabric-clk3 { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <50000000>; - }; - - fabric_clk1: fabric-clk1 { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <125000000>; - }; - - fabric-bus@40000000 { - compatible = "simple-bus"; - #address-cells = <2>; - #size-cells = <2>; - ranges = <0x0 0x40000000 0x0 0x40000000 0x0 0x20000000>, /* FIC3-FAB */ - <0x0 0x60000000 0x0 0x60000000 0x0 0x20000000>, /* FIC0, LO */ - <0x0 0xe0000000 0x0 0xe0000000 0x0 0x20000000>, /* FIC1, LO */ - <0x20 0x0 0x20 0x0 0x10 0x0>, /* FIC0,HI */ - <0x30 0x0 0x30 0x0 0x10 0x0>; /* FIC1,HI */ - - cape_gpios_p8: gpio@41100000 { - compatible = "microchip,coregpio-rtl-v3"; - reg = <0x0 0x41100000 0x0 0x1000>; - clocks = <&fabric_clk3>; - gpio-controller; - #gpio-cells = <2>; - ngpios = <16>; - gpio-line-names = "P8_PIN31", "P8_PIN32", "P8_PIN33", "P8_PIN34", - "P8_PIN35", "P8_PIN36", "P8_PIN37", "P8_PIN38", - "P8_PIN39", "P8_PIN40", "P8_PIN41", "P8_PIN42", - "P8_PIN43", "P8_PIN44", "P8_PIN45", "P8_PIN46"; - }; - - cape_gpios_p9: gpio@41200000 { - compatible = "microchip,coregpio-rtl-v3"; - reg = <0x0 0x41200000 0x0 0x1000>; - clocks = <&fabric_clk3>; - gpio-controller; - #gpio-cells = <2>; - ngpios = <20>; - gpio-line-names = "P9_PIN11", "P9_PIN12", "P9_PIN13", "P9_PIN14", - "P9_PIN15", "P9_PIN16", "P9_PIN17", "P9_PIN18", - "P9_PIN21", "P9_PIN22", "P9_PIN23", "P9_PIN24", - "P9_PIN25", "P9_PIN26", "P9_PIN27", "P9_PIN28", - "P9_PIN29", "P9_PIN31", "P9_PIN41", "P9_PIN42"; - }; - - hsi_gpios: gpio@44000000 { - compatible = "microchip,coregpio-rtl-v3"; - reg = <0x0 0x44000000 0x0 0x1000>; - clocks = <&fabric_clk3>; - gpio-controller; - #gpio-cells = <2>; - ngpios = <20>; - gpio-line-names = "B0_HSIO70N", "B0_HSIO71N", "B0_HSIO83N", - "B0_HSIO73N_C2P_CLKN", "B0_HSIO70P", "B0_HSIO71P", - "B0_HSIO83P", "B0_HSIO73N_C2P_CLKP", "XCVR1_RX_VALID", - "XCVR1_LOCK", "XCVR1_ERROR", "XCVR2_RX_VALID", - "XCVR2_LOCK", "XCVR2_ERROR", "XCVR3_RX_VALID", - "XCVR3_LOCK", "XCVR3_ERROR", "XCVR_0B_REF_CLK_PLL_LOCK", - "XCVR_0C_REF_CLK_PLL_LOCK", "B0_HSIO81N"; - }; - }; - - refclk_ccc: cccrefclk { - compatible = "fixed-clock"; - #clock-cells = <0>; - }; -}; - -&ccc_nw { - clocks = <&refclk_ccc>, <&refclk_ccc>, <&refclk_ccc>, <&refclk_ccc>, - <&refclk_ccc>, <&refclk_ccc>; - clock-names = "pll0_ref0", "pll0_ref1", "pll1_ref0", "pll1_ref1", - "dll0_ref", "dll1_ref"; - status = "okay"; -}; diff --git a/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts b/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts index 47cf693beb68..aae239d79162 100644 --- a/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts +++ b/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts @@ -5,7 +5,6 @@ #include <dt-bindings/gpio/gpio.h> #include "mpfs.dtsi" -#include "mpfs-beaglev-fire-fabric.dtsi" /* Clock frequency (in Hz) of MTIMER */ #define MTIMER_FREQ 1000000 @@ -183,10 +182,6 @@ &refclk { clock-frequency = <125000000>; }; -&refclk_ccc { - clock-frequency = <50000000>; -}; - &rtc { status = "okay"; }; -- 2.51.0

2 months

1
1
0 0

[PATCH 1/2] mmc: core sd: Simplify current limit logic for 200mA default

by Avri Altman

The SD current limit logic is updated to avoid explicitly setting the current limit when the maximum power is 200mA (0.72W) or less, as this is already the default value. The code now only issues a current limit switch if a higher limit is required, and the unused SD_SET_CURRENT_NO_CHANGE constant is removed. This reduces unnecessary commands and simplifies the logic. Fixes: 0aa6770000ba ("mmc: sdhci: only set 200mA support for 1.8v if 200mA is available") Signed-off-by: Avri Altman <avri.altman(a)sandisk.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/core/sd.c | 7 ++----- include/linux/mmc/card.h | 1 - 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index ec02067f03c5..cf92c5b2059a 100644 --- a/drivers/mmc/core/sd.c +++ b/drivers/mmc/core/sd.c @@ -554,7 +554,7 @@ static u32 sd_get_host_max_current(struct mmc_host *host) static int sd_set_current_limit(struct mmc_card *card, u8 *status) { - int current_limit = SD_SET_CURRENT_NO_CHANGE; + int current_limit = SD_SET_CURRENT_LIMIT_200; int err; u32 max_current; @@ -598,11 +598,8 @@ static int sd_set_current_limit(struct mmc_card *card, u8 *status) else if (max_current >= 400 && card->sw_caps.sd3_curr_limit & SD_MAX_CURRENT_400) current_limit = SD_SET_CURRENT_LIMIT_400; - else if (max_current >= 200 && - card->sw_caps.sd3_curr_limit & SD_MAX_CURRENT_200) - current_limit = SD_SET_CURRENT_LIMIT_200; - if (current_limit != SD_SET_CURRENT_NO_CHANGE) { + if (current_limit != SD_SET_CURRENT_LIMIT_200) { err = mmc_sd_switch(card, SD_SWITCH_SET, 3, current_limit, status); if (err) diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h index ddcdf23d731c..e9e964c20e53 100644 --- a/include/linux/mmc/card.h +++ b/include/linux/mmc/card.h @@ -182,7 +182,6 @@ struct sd_switch_caps { #define SD_SET_CURRENT_LIMIT_400 1 #define SD_SET_CURRENT_LIMIT_600 2 #define SD_SET_CURRENT_LIMIT_800 3 -#define SD_SET_CURRENT_NO_CHANGE (-1) #define SD_MAX_CURRENT_200 (1 << SD_SET_CURRENT_LIMIT_200) #define SD_MAX_CURRENT_400 (1 << SD_SET_CURRENT_LIMIT_400) -- 2.25.1

2 months

3
4
0 0

Custom Packaging Boxes and Labels

by Micah Robert

Hi, We provide custom packaging boxes and labels. We make boxes in different materials and styles such as Vape Boxe, Cigarette Boxes, Cartridge Boxes, Cardboard boxes, Rigid Boxes and Mailer boxes, etc. Our benefits include quick turnaround time, free shipping and design support. Just send over your box or label specifications and quantity so I can give you an estimate on that. Let me know if you have any questions. Thanks Best Regards Micah Robert My Packaging Pro

2 months

1
0
0 0

[PATCH] PCI/PM: Ensure power-up succeeded before restoring MMIO state

by Brian Norris

From: Brian Norris <briannorris(a)google.com> As the comments in pci_pm_thaw_noirq() suggest, pci_restore_state() may need to restore MSI-X state in MMIO space. This is only possible if we reach D0; if we failed to power up, this might produce a fatal error when touching memory space. Check for errors (as the "verify" in "pci_pm_power_up_and_verify_state" implies), and skip restoring if it fails. This mitigates errors seen during resume_noirq, for example, when the platform did not resume the link properly. Cc: stable(a)vger.kernel.org Signed-off-by: Brian Norris <briannorris(a)google.com> Signed-off-by: Brian Norris <briannorris(a)chromium.org> --- drivers/pci/pci-driver.c | 12 +++++++++--- drivers/pci/pci.c | 13 +++++++++++-- drivers/pci/pci.h | 2 +- 3 files changed, 21 insertions(+), 6 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 302d61783f6c..d66d95bd0ca2 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -557,7 +557,13 @@ static void pci_pm_default_resume(struct pci_dev *pci_dev) static void pci_pm_default_resume_early(struct pci_dev *pci_dev) { - pci_pm_power_up_and_verify_state(pci_dev); + /* + * If we failed to reach D0, we'd better not touch MSI-X state in MMIO + * space. + */ + if (pci_pm_power_up_and_verify_state(pci_dev)) + return; + pci_restore_state(pci_dev); pci_pme_restore(pci_dev); } @@ -1101,8 +1107,8 @@ static int pci_pm_thaw_noirq(struct device *dev) * in case the driver's "freeze" callbacks put it into a low-power * state. */ - pci_pm_power_up_and_verify_state(pci_dev); - pci_restore_state(pci_dev); + if (!pci_pm_power_up_and_verify_state(pci_dev)) + pci_restore_state(pci_dev); if (pci_has_legacy_pm_support(pci_dev)) return 0; diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index e698278229f2..c75fec3b094f 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3144,10 +3144,19 @@ void pci_d3cold_disable(struct pci_dev *dev) } EXPORT_SYMBOL_GPL(pci_d3cold_disable); -void pci_pm_power_up_and_verify_state(struct pci_dev *pci_dev) +int pci_pm_power_up_and_verify_state(struct pci_dev *pci_dev) { - pci_power_up(pci_dev); + int ret; + + ret = pci_power_up(pci_dev); pci_update_current_state(pci_dev, PCI_D0); + + if (ret < 0 && pci_dev->current_state == PCI_D3cold) { + dev_err(&pci_dev->dev, "Failed to power up device: %d\n", ret); + return ret; + } + + return 0; } /** diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 1c48bc447f58..87ad201417d5 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -233,7 +233,7 @@ void pci_dev_adjust_pme(struct pci_dev *dev); void pci_dev_complete_resume(struct pci_dev *pci_dev); void pci_config_pm_runtime_get(struct pci_dev *dev); void pci_config_pm_runtime_put(struct pci_dev *dev); -void pci_pm_power_up_and_verify_state(struct pci_dev *pci_dev); +int pci_pm_power_up_and_verify_state(struct pci_dev *pci_dev); void pci_pm_init(struct pci_dev *dev); void pci_ea_init(struct pci_dev *dev); void pci_msi_init(struct pci_dev *dev); -- 2.51.0.rc1.193.gad69d77794-goog

2 months

2
1
0 0

FAILED: patch "[PATCH] x86/resctrl: Fix miscount of bandwidth event when" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102051-foe-trunks-268f@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 Mon Sep 17 00:00:00 2001 From: Babu Moger <babu.moger(a)amd.com> Date: Fri, 10 Oct 2025 12:08:35 -0500 Subject: [PATCH] x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state. When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked. resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked. This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter). Reset the stored value (arch_mbm_state::prev_msr) of MSR_IA32_QM_CTR to zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again. Example scenario that results in mistaken overflow ================================================== 1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group. $mount -t resctrl resctrl /sys/fs/resctrl $mkdir /sys/fs/resctrl/mon_groups/test1/ $echo 1234 > /sys/fs/resctrl/mon_groups/test1/tasks $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 21323 <- Total bytes on domain 0 "Unavailable" <- Total bytes on domain 1 Task is running on domain 0. Counter on domain 1 is "Unavailable". 2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 7345357 <- Total bytes on domain 0 4545 <- Total bytes on domain 1 3. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes "Unavailable" <- Total bytes on domain 0 434341 <- Total bytes on domain 1 4. Since the task continues to migrate between domains, it may eventually return to domain 0. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 17592178699059 <- Overflow on domain 0 3232332 <- Total bytes on domain 1 In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0. Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta. In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state. Here is the text from APM [1] available from [2]. "In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first QM_CTR read when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, a QM_CTR read with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read." [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM). [ bp: Split commit message into smaller paragraph chunks for better consumption. ] Fixes: 4d05bf71f157d ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Babu Moger <babu.moger(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre(a)intel.com> Tested-by: Reinette Chatre <reinette.chatre(a)intel.com> Cc: stable(a)vger.kernel.org # needs adjustments for <= v6.17 Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2] diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index c8945610d455..2cd25a0d4637 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -242,7 +242,9 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_mon_domain *d, u32 unused, u32 rmid, enum resctrl_event_id eventid, u64 *val, void *ignored) { + struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d); int cpu = cpumask_any(&d->hdr.cpu_mask); + struct arch_mbm_state *am; u64 msr_val; u32 prmid; int ret; @@ -251,12 +253,16 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_mon_domain *d, prmid = logical_rmid_to_physical_rmid(cpu, rmid); ret = __rmid_read_phys(prmid, eventid, &msr_val); - if (ret) - return ret; - *val = get_corrected_val(r, d, rmid, eventid, msr_val); + if (!ret) { + *val = get_corrected_val(r, d, rmid, eventid, msr_val); + } else if (ret == -EINVAL) { + am = get_arch_mbm_state(hw_dom, rmid, eventid); + if (am) + am->prev_msr = 0; + } - return 0; + return ret; } static int __cntr_id_read(u32 cntr_id, u64 *val)

2 months

3
2
0 0

, conoce mejor a tu candidato antes de contratar

by Valeria Pérez

Evaluaciones Psicométricas para RR.HH. body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Mejora tus procesos de selección con evaluaciones psicométricas fáciles y confiables. Hola, , Sabemos que encontrar al candidato ideal va más allá del currículum. Por eso quiero contarte brevemente sobre PsicoSmart, una plataforma que ayuda a equipos de RR.HH. a evaluar talento con pruebas psicométricas rápidas, confiables y fáciles de aplicar. Con PsicoSmart puedes: Aplicar evaluaciones psicométricas 100% en línea. Elegir entre más de 31 pruebas psicométricas Generar reportes automáticos, visuales y fáciles de interpretar. Comparar resultados entre candidatos en segundos. Ahorrar horas valiosas del proceso de selección. Si estás buscando mejorar tus contrataciones, te lo recomiendo muchísimo. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo. Saludos, ----------------------------- Atte.: Valeria Pérez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewispptseup">click aquí</a>

2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror