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

+ mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.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-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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: Jinjiang Tu <tujinjiang(a)huawei.com> Subject: mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn Date: Fri, 15 Aug 2025 15:32:09 +0800 When memory_failure() is called for a already hwpoisoned pfn, kill_accessing_process() will be called to kill current task. However, if the vma of the accessing vaddr is VM_PFNMAP, walk_page_range() will skip the vma in walk_page_test() and return 0. Before commit aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages"), kill_accessing_process() will return EFAULT. For x86, the current task will be killed in kill_me_maybe(). However, after this commit, kill_accessing_process() simplies return 0, that means UCE is handled properly, but it doesn't actually. In such case, the user task will trigger UCE infinitely. To fix it, add .test_walk callback for hwpoison_walk_ops to scan all vmas. Link: https://lkml.kernel.org/r/20250815073209.1984582-1-tujinjiang@huawei.com Fixes: aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Miaohe Lin <linmiaohe(a)huawei.com> Reviewed-by: Jane Chu <jane.chu(a)oracle.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Shuai Xue <xueshuai(a)linux.alibaba.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/mm/memory-failure.c~mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn +++ a/mm/memory-failure.c @@ -853,9 +853,17 @@ static int hwpoison_hugetlb_range(pte_t #define hwpoison_hugetlb_range NULL #endif +static int hwpoison_test_walk(unsigned long start, unsigned long end, + struct mm_walk *walk) +{ + /* We also want to consider pages mapped into VM_PFNMAP. */ + return 0; +} + static const struct mm_walk_ops hwpoison_walk_ops = { .pmd_entry = hwpoison_pte_range, .hugetlb_entry = hwpoison_hugetlb_range, + .test_walk = hwpoison_test_walk, .walk_lock = PGWALK_RDLOCK, }; _ Patches currently in -mm which might be from tujinjiang(a)huawei.com are mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch mm-memory_hotplug-fix-hwpoisoned-large-folio-handling-in-do_migrate_range.patch

3 months, 3 weeks

1
0
0 0

+ init-handle-bootloader-identifier-in-kernel-parameters-v4.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: init-handle-bootloader-identifier-in-kernel-parameters-v4 has been added to the -mm mm-nonmm-unstable branch. Its filename is init-handle-bootloader-identifier-in-kernel-parameters-v4.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-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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: Huacai Chen <chenhuacai(a)loongson.cn> Subject: init-handle-bootloader-identifier-in-kernel-parameters-v4 Date: Fri, 15 Aug 2025 17:01:20 +0800 use strstarts() Link: https://lkml.kernel.org/r/20250815090120.1569947-1-chenhuacai@loongson.cn Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jan Kara <jack(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- init/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/init/main.c~init-handle-bootloader-identifier-in-kernel-parameters-v4 +++ a/init/main.c @@ -559,7 +559,7 @@ static int __init unknown_bootoption(cha /* Handle bootloader identifier */ for (int i = 0; bootloader[i]; i++) { - if (!strncmp(param, bootloader[i], strlen(bootloader[i]))) + if (strstarts(param, bootloader[i])) return 0; } _ Patches currently in -mm which might be from chenhuacai(a)loongson.cn are init-handle-bootloader-identifier-in-kernel-parameters.patch init-handle-bootloader-identifier-in-kernel-parameters-v4.patch

3 months, 3 weeks

1
0
0 0

[PATCH v5 RESEND] x86/cpu/intel: Fix the constant_tsc model check for Pentium 4

by Suchit Karunakaran

Pentium 4's which are INTEL_P4_PRESCOTT (model 0x03) and later have a constant TSC. This was correctly captured until commit fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks"). In that commit, an error was introduced while selecting the last P4 model (0x06) as the upper bound. Model 0x06 was transposed to INTEL_P4_WILLAMETTE, which is just plain wrong. That was presumably a simple typo, probably just copying and pasting the wrong P4 model. Fix the constant TSC logic to cover all later P4 models. End at INTEL_P4_CEDARMILL which accurately corresponds to the last P4 model. Fixes: fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks") Cc: <stable(a)vger.kernel.org> # v6.15 Reviewed-by: Sohil Mehta <sohil.mehta(a)intel.com> Signed-off-by: Suchit Karunakaran <suchitkarunakaran(a)gmail.com> --- Changes since v4: - Updated the patch based on review suggestions Changes since v3: - Refined changelog Changes since v2: - Improved commit message Changes since v1: - Fixed incorrect logic arch/x86/kernel/cpu/intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index 076eaa41b8c8..98ae4c37c93e 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -262,7 +262,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) if (c->x86_power & (1 << 8)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC); - } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_WILLAMETTE) || + } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_CEDARMILL) || (c->x86_vfm >= INTEL_CORE_YONAH && c->x86_vfm <= INTEL_IVYBRIDGE)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); } -- 2.50.1

3 months, 3 weeks

1
0
0 0

[BACKPORT REQUEST] mfd: cros_ec: Separate charge-control probing from USB-PD

by Thomas Weißschuh

Dear stable team, I'd like to have the following commit backported to v6.16 and v6.15: e40fc1160d49 ("mfd: cros_ec: Separate charge-control probing from USB-PD") It fixes probing issues for the cros-charge-control driver, for details see the commit message. As far as I can see, the commit also was marked for -stable backporting from the beginning. Somehow this doesn't seem to have worked. Thanks for your consideration, Thomas

3 months, 3 weeks

2
1
0 0

FAILED: patch "[PATCH] PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable" 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 6cff20ce3b92ffbf2fc5eb9e5a030b3672aa414a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081509-uncrown-janitor-adad@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6cff20ce3b92ffbf2fc5eb9e5a030b3672aa414a Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Sun, 13 Jul 2025 16:31:01 +0200 Subject: [PATCH] PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable ports pci_bridge_d3_possible() is called from both pcie_portdrv_probe() and pcie_portdrv_remove() to determine whether runtime power management shall be enabled (on probe) or disabled (on remove) on a PCIe port. The underlying assumption is that pci_bridge_d3_possible() always returns the same value, else a runtime PM reference imbalance would occur. That assumption is not given if the PCIe port is inaccessible on remove due to hot-unplug: pci_bridge_d3_possible() calls pciehp_is_native(), which accesses Config Space to determine whether the port is Hot-Plug Capable. An inaccessible port returns "all ones", which is converted to "all zeroes" by pcie_capability_read_dword(). Hence the port no longer seems Hot-Plug Capable on remove even though it was on probe. The resulting runtime PM ref imbalance causes warning messages such as: pcieport 0000:02:04.0: Runtime PM usage count underflow! Avoid the Config Space access (and thus the runtime PM ref imbalance) by caching the Hot-Plug Capable bit in struct pci_dev. The struct already contains an "is_hotplug_bridge" flag, which however is not only set on Hot-Plug Capable PCIe ports, but also Conventional PCI Hot-Plug bridges and ACPI slots. The flag identifies bridges which are allocated additional MMIO and bus number resources to allow for hierarchy expansion. The kernel is somewhat sloppily using "is_hotplug_bridge" in a number of places to identify Hot-Plug Capable PCIe ports, even though the flag encompasses other devices. Subsequent commits replace these occurrences with the new flag to clearly delineate Hot-Plug Capable PCIe ports from other kinds of hotplug bridges. Document the existing "is_hotplug_bridge" and the new "is_pciehp" flag and document the (non-obvious) requirement that pci_bridge_d3_possible() always returns the same value across the entire lifetime of a bridge, including its hot-removal. Fixes: 5352a44a561d ("PCI: pciehp: Make pciehp_is_native() stricter") Reported-by: Laurent Bigonville <bigon(a)bigon.be> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220216 Reported-by: Mario Limonciello <mario.limonciello(a)amd.com> Closes: https://lore.kernel.org/r/20250609020223.269407-3-superm1@kernel.org/ Link: https://lore.kernel.org/all/20250620025535.3425049-3-superm1@kernel.org/T/#u Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Acked-by: Rafael J. Wysocki <rafael(a)kernel.org> Cc: stable(a)vger.kernel.org # v4.18+ Link: https://patch.msgid.link/fe5dcc3b2e62ee1df7905d746bde161eb1b3291c.175239010… diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index b78e0e417324..efe478e5073e 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -816,13 +816,11 @@ int pci_acpi_program_hp_params(struct pci_dev *dev) bool pciehp_is_native(struct pci_dev *bridge) { const struct pci_host_bridge *host; - u32 slot_cap; if (!IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE)) return false; - pcie_capability_read_dword(bridge, PCI_EXP_SLTCAP, &slot_cap); - if (!(slot_cap & PCI_EXP_SLTCAP_HPC)) + if (!bridge->is_pciehp) return false; if (pcie_ports_native) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index e9448d55113b..23d8fe98ddf9 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3030,8 +3030,12 @@ static const struct dmi_system_id bridge_d3_blacklist[] = { * pci_bridge_d3_possible - Is it possible to put the bridge into D3 * @bridge: Bridge to check * - * This function checks if it is possible to move the bridge to D3. * Currently we only allow D3 for some PCIe ports and for Thunderbolt. + * + * Return: Whether it is possible to move the bridge to D3. + * + * The return value is guaranteed to be constant across the entire lifetime + * of the bridge, including its hot-removal. */ bool pci_bridge_d3_possible(struct pci_dev *bridge) { diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 4b8693ec9e4c..cf50be63bf5f 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1678,7 +1678,7 @@ void set_pcie_hotplug_bridge(struct pci_dev *pdev) pcie_capability_read_dword(pdev, PCI_EXP_SLTCAP, &reg32); if (reg32 & PCI_EXP_SLTCAP_HPC) - pdev->is_hotplug_bridge = 1; + pdev->is_hotplug_bridge = pdev->is_pciehp = 1; } static void set_pcie_thunderbolt(struct pci_dev *dev) diff --git a/include/linux/pci.h b/include/linux/pci.h index 05e68f35f392..d56d0dd80afb 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -328,6 +328,11 @@ struct rcec_ea; * determined (e.g., for Root Complex Integrated * Endpoints without the relevant Capability * Registers). + * @is_hotplug_bridge: Hotplug bridge of any kind (e.g. PCIe Hot-Plug Capable, + * Conventional PCI Hot-Plug, ACPI slot). + * Such bridges are allocated additional MMIO and bus + * number resources to allow for hierarchy expansion. + * @is_pciehp: PCIe Hot-Plug Capable bridge. */ struct pci_dev { struct list_head bus_list; /* Node in per-bus list */ @@ -451,6 +456,7 @@ struct pci_dev { unsigned int is_physfn:1; unsigned int is_virtfn:1; unsigned int is_hotplug_bridge:1; + unsigned int is_pciehp:1; unsigned int shpc_managed:1; /* SHPC owned by shpchp */ unsigned int is_thunderbolt:1; /* Thunderbolt controller */ /*

3 months, 3 weeks

2
1
0 0

FAILED: patch "[PATCH] block: Make REQ_OP_ZONE_FINISH a write operation" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x 3f66ccbaaef3a0c5bd844eab04e3207b4061c546 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081543-myself-easiest-be00@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3f66ccbaaef3a0c5bd844eab04e3207b4061c546 Mon Sep 17 00:00:00 2001 From: Damien Le Moal <dlemoal(a)kernel.org> Date: Wed, 25 Jun 2025 18:33:23 +0900 Subject: [PATCH] block: Make REQ_OP_ZONE_FINISH a write operation REQ_OP_ZONE_FINISH is defined as "12", which makes op_is_write(REQ_OP_ZONE_FINISH) return false, despite the fact that a zone finish operation is an operation that modifies a zone (transition it to full) and so should be considered as a write operation (albeit one that does not transfer any data to the device). Fix this by redefining REQ_OP_ZONE_FINISH to be an odd number (13), and redefine REQ_OP_ZONE_RESET and REQ_OP_ZONE_RESET_ALL using sequential odd numbers from that new value. Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations") Cc: stable(a)vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal(a)kernel.org> Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Link: https://lore.kernel.org/r/20250625093327.548866-2-dlemoal@kernel.org Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h index 3d1577f07c1c..930daff207df 100644 --- a/include/linux/blk_types.h +++ b/include/linux/blk_types.h @@ -350,11 +350,11 @@ enum req_op { /* Close a zone */ REQ_OP_ZONE_CLOSE = (__force blk_opf_t)11, /* Transition a zone to full */ - REQ_OP_ZONE_FINISH = (__force blk_opf_t)12, + REQ_OP_ZONE_FINISH = (__force blk_opf_t)13, /* reset a zone write pointer */ - REQ_OP_ZONE_RESET = (__force blk_opf_t)13, + REQ_OP_ZONE_RESET = (__force blk_opf_t)15, /* reset all the zone present on the device */ - REQ_OP_ZONE_RESET_ALL = (__force blk_opf_t)15, + REQ_OP_ZONE_RESET_ALL = (__force blk_opf_t)17, /* Driver private requests */ REQ_OP_DRV_IN = (__force blk_opf_t)34,

3 months, 3 weeks

2
2
0 0

[STATUS] stable/linux-6.6.y - bb9c90ab9c5a1a933a0dfd302a3fde73642b2b06

by KernelCI bot

Hello, Status summary for stable/linux-6.6.y Dashboard: https://d.kernelci.org/c/stable/linux-6.6.y/bb9c90ab9c5a1a933a0dfd302a3fde7… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-6.6.y commit hash: bb9c90ab9c5a1a933a0dfd302a3fde73642b2b06 origin: maestro test start time: 2025-08-15 10:52:19.705000+00:00 Builds: 45 ✅ 0 ❌ 0 ⚠️ Boots: 60 ✅ 0 ❌ 42 ⚠️ Tests: 3948 ✅ 607 ❌ 1617 ⚠️ ### POSSIBLE REGRESSIONS No possible regressions observed. ### FIXED REGRESSIONS No fixed regressions observed. ### UNSTABLE TESTS Hardware: bcm2711-rpi-4-b - boot (defconfig+lab-setup+kselftest) last run: https://d.kernelci.org/test/maestro:689f184b233e484a3f986be3 history: > ✅ > ✅ > ⚠️ Hardware: dell-latitude-3445-7520c-skyrim - boot (cros://chromeos-6.6/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y) last run: https://d.kernelci.org/test/maestro:689f24dd233e484a3f98e2c2 history: > ⚠️ > ⚠️ Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 months, 3 weeks

1
0
0 0

[STATUS] stable/linux-6.12.y - 880e4ff5d6c8dc6b660f163a0e9b68b898cc6310

by KernelCI bot

Hello, Status summary for stable/linux-6.12.y Dashboard: https://d.kernelci.org/c/stable/linux-6.12.y/880e4ff5d6c8dc6b660f163a0e9b68… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-6.12.y commit hash: 880e4ff5d6c8dc6b660f163a0e9b68b898cc6310 origin: maestro test start time: 2025-08-15 10:52:20.130000+00:00 Builds: 44 ✅ 0 ❌ 1 ⚠️ Boots: 160 ✅ 1 ❌ 41 ⚠️ Tests: 10405 ✅ 5245 ❌ 3110 ⚠️ ### POSSIBLE REGRESSIONS No possible regressions observed. ### FIXED REGRESSIONS No fixed regressions observed. ### UNSTABLE TESTS Hardware: acer-cb317-1h-c3z6-dedede - kernelci_wifi_basic (x86_64_defconfig+lab-setup+x86-board+kselftest) last run: https://d.kernelci.org/test/maestro:689f1bf6233e484a3f98a8b1 history: > ⚠️ > ❌ Hardware: acer-chromebox-cxi4-puff - tast (cros://chromeos-6.6/x86_64/chromeos-intel-pineview.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y) last run: https://d.kernelci.org/test/maestro:689f2110233e484a3f98ccb7 history: > ⚠️ > ❌ > ⚠️ > ⚠️ > ⚠️ Hardware: bcm2711-rpi-4-b - boot (defconfig+lab-setup+kselftest) last run: https://d.kernelci.org/test/maestro:689f1a23233e484a3f9880c8 history: > ✅ > ✅ > ⚠️ Hardware: dell-latitude-3445-7520c-skyrim - boot (cros://chromeos-6.6/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y) last run: https://d.kernelci.org/test/maestro:689f17c2233e484a3f986a63 history: > ⚠️ > ⚠️ Hardware: hp-14-db0003na-grunt - tast (cros://chromeos-6.6/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y) last run: https://d.kernelci.org/test/maestro:689f17d9233e484a3f986b39 history: > ⚠️ > ❌ > ⚠️ > ⚠️ > ⚠️ Hardware: hp-x360-14a-cb0001xx-zork - tast (cros://chromeos-6.6/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y) last run: https://d.kernelci.org/test/maestro:689f17db233e484a3f986b42 history: > ⚠️ > ⚠️ > ⚠️ > ❌ > ⚠️ Hardware: lenovo-TPad-C13-Yoga-zork - tast (cros://chromeos-6.6/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y) last run: https://d.kernelci.org/test/maestro:689f17db233e484a3f986b45 history: > ⚠️ > ⚠️ > ⚠️ > ⚠️ > ⚠️ Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 months, 3 weeks

1
0
0 0

[STATUS] stable/linux-6.1.y - 0bc96de781b4da716c8dbd248af4b26d8d8341f5

by KernelCI bot

Hello, Status summary for stable/linux-6.1.y Dashboard: https://d.kernelci.org/c/stable/linux-6.1.y/0bc96de781b4da716c8dbd248af4b26… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-6.1.y commit hash: 0bc96de781b4da716c8dbd248af4b26d8d8341f5 origin: maestro test start time: 2025-08-15 10:52:19.284000+00:00 Builds: 44 ✅ 1 ❌ 0 ⚠️ Boots: 35 ✅ 0 ❌ 24 ⚠️ Tests: 1994 ✅ 166 ❌ 1054 ⚠️ ### POSSIBLE REGRESSIONS No possible regressions observed. ### FIXED REGRESSIONS No fixed regressions observed. ### UNSTABLE TESTS Hardware: bcm2711-rpi-4-b - boot (defconfig+lab-setup+kselftest) last run: https://d.kernelci.org/test/maestro:689f28a2233e484a3f98e9a8 history: > ✅ > ✅ > ⚠️ Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 months, 3 weeks

1
0
0 0

[PATCH 2/2] riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id

by Radim Krčmář

emit_ld is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: 2ddec2c80b44 ("riscv, bpf: inline bpf_get_smp_processor_id()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Radim Krčmář <rkrcmar(a)ventanamicro.com> --- arch/riscv/net/bpf_jit_comp64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c index 6e1554d89681..9883a55d61b5 100644 --- a/arch/riscv/net/bpf_jit_comp64.c +++ b/arch/riscv/net/bpf_jit_comp64.c @@ -1763,7 +1763,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx, */ if (insn->src_reg == 0 && insn->imm == BPF_FUNC_get_smp_processor_id) { /* Load current CPU number in R0 */ - emit_ld(bpf_to_rv_reg(BPF_REG_0, ctx), offsetof(struct thread_info, cpu), + emit_lw(bpf_to_rv_reg(BPF_REG_0, ctx), offsetof(struct thread_info, cpu), RV_REG_TP, ctx); break; } -- 2.50.0

3 months, 3 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror