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

FAILED: patch "[PATCH] Revert "io_uring/rw: drop -EOPNOTSUPP check in" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 927069c4ac2cd1a37efa468596fb5b8f86db9df0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102039-bonelike-vocation-0372@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 927069c4ac2cd1a37efa468596fb5b8f86db9df0 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Mon, 13 Oct 2025 12:05:31 -0600 Subject: [PATCH] Revert "io_uring/rw: drop -EOPNOTSUPP check in __io_complete_rw_common()" This reverts commit 90bfb28d5fa8127a113a140c9791ea0b40ab156a. Kevin reports that this commit causes an issue for him with LVM snapshots, most likely because of turning off NOWAIT support while a snapshot is being created. This makes -EOPNOTSUPP bubble back through the completion handler, where io_uring read/write handling should just retry it. Reinstate the previous check removed by the referenced commit. Cc: stable(a)vger.kernel.org Fixes: 90bfb28d5fa8 ("io_uring/rw: drop -EOPNOTSUPP check in __io_complete_rw_common()") Reported-by: Salvatore Bonaccorso <carnil(a)debian.org> Reported-by: Kevin Lumik <kevin(a)xf.ee> Link: https://lore.kernel.org/io-uring/cceb723c-051b-4de2-9a4c-4aa82e1619ee@kerne… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/rw.c b/io_uring/rw.c index 08882648d569..a0f9d2021e3f 100644 --- a/io_uring/rw.c +++ b/io_uring/rw.c @@ -542,7 +542,7 @@ static void __io_complete_rw_common(struct io_kiocb *req, long res) { if (res == req->cqe.res) return; - if (res == -EAGAIN && io_rw_should_reissue(req)) { + if ((res == -EOPNOTSUPP || res == -EAGAIN) && io_rw_should_reissue(req)) { req->flags |= REQ_F_REISSUE | REQ_F_BL_NO_RECYCLE; } else { req_set_fail(req);

3 weeks, 5 days

3
2
0 0

[PATCH v3 1/5] mm: fix off-by-one error in VMA count limit checks

by Kalesh Singh

The VMA count limit check in do_mmap() and do_brk_flags() uses a strict inequality (>), which allows a process's VMA count to exceed the configured sysctl_max_map_count limit by one. A process with mm->map_count == sysctl_max_map_count will incorrectly pass this check and then exceed the limit upon allocation of a new VMA when its map_count is incremented. Other VMA allocation paths, such as split_vma(), already use the correct, inclusive (>=) comparison. Fix this bug by changing the comparison to be inclusive in do_mmap() and do_brk_flags(), bringing them in line with the correct behavior of other allocation paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: <stable(a)vger.kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: "Liam R. Howlett" <Liam.Howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Pedro Falcato <pfalcato(a)suse.de> Reviewed-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reviewed-by: Pedro Falcato <pfalcato(a)suse.de> Acked-by: SeongJae Park <sj(a)kernel.org> Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> --- Changes in v3: - Collect Reviewed-by and Acked-by tags. Changes in v2: - Fix mmap check, per Pedro mm/mmap.c | 2 +- mm/vma.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index 644f02071a41..da2cbdc0f87b 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -374,7 +374,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, return -EOVERFLOW; /* Too many mappings? */ - if (mm->map_count > sysctl_max_map_count) + if (mm->map_count >= sysctl_max_map_count) return -ENOMEM; /* diff --git a/mm/vma.c b/mm/vma.c index a2e1ae954662..fba68f13e628 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2797,7 +2797,7 @@ int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, if (!may_expand_vm(mm, vm_flags, len >> PAGE_SHIFT)) return -ENOMEM; - if (mm->map_count > sysctl_max_map_count) + if (mm->map_count >= sysctl_max_map_count) return -ENOMEM; if (security_vm_enough_memory_mm(mm, len >> PAGE_SHIFT)) -- 2.51.0.760.g7b8bcc2412-goog

3 weeks, 5 days

5
11
0 0

[PATCH 6.1.y 00/12] timers: Provide timer_shutdown[_sync]()

by Jeongjun Park

The "timers: Provide timer_shutdown[_sync]()" patch series implemented a useful feature that addresses various bugs caused by attempts to rearm shutdown timers. https://lore.kernel.org/all/20221123201306.823305113@linutronix.de/ However, this patch series was not fully backported to versions prior to 6.2, requiring separate patches for older kernels if these bugs were encountered. The biggest problem with this is that even if these bugs were discovered and patched in the upstream kernel, if the maintainer or author didn't create a separate backport patch for versions prior to 6.2, the bugs would remain untouched in older kernels. Therefore, to reduce the hassle of having to write a separate patch, we should backport the remaining unbackported commits from the "timers: Provide timer_shutdown[_sync]()" patch series to versions prior to 6.2. --- Documentation/RCU/Design/Requirements/Requirements.rst | 2 +- Documentation/core-api/local_ops.rst | 2 +- Documentation/kernel-hacking/locking.rst | 17 ++++--- Documentation/timers/hrtimers.rst | 2 +- Documentation/translations/it_IT/kernel-hacking/locking.rst | 14 +++-- Documentation/translations/zh_CN/core-api/local_ops.rst | 2 +- arch/arm/mach-spear/time.c | 8 +-- drivers/bluetooth/hci_qca.c | 10 +++- drivers/clocksource/arm_arch_timer.c | 12 ++--- drivers/clocksource/timer-sp804.c | 6 +-- include/linux/timer.h | 2 + kernel/time/timer.c | 311 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------- 12 files changed, 299 insertions(+), 89 deletions(-)

3 weeks, 5 days

2
13
0 0

[PATCH v3 05/14] iommu/mediatek: fix device leak on of_xlate()

by Johan Hovold

Make sure to drop the reference taken to the iommu platform device when looking up its driver data during of_xlate(). Fixes: 0df4fabe208d ("iommu/mediatek: Add mt8173 IOMMU driver") Cc: stable(a)vger.kernel.org # 4.6 Acked-by: Robin Murphy <robin.murphy(a)arm.com> Reviewed-by: Yong Wu <yong.wu(a)mediatek.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/iommu/mtk_iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index 0e0285348d2b..8d8e85186188 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -974,6 +974,8 @@ static int mtk_iommu_of_xlate(struct device *dev, return -EINVAL; dev_iommu_priv_set(dev, platform_get_drvdata(m4updev)); + + put_device(&m4updev->dev); } return iommu_fwspec_add_ids(dev, args->args, 1); -- 2.49.1

3 weeks, 5 days

2
1
0 0

[PATCH v3 08/14] iommu/mediatek-v1: fix device leak on probe_device()

by Johan Hovold

Make sure to drop the reference taken to the iommu platform device when looking up its driver data during probe_device(). Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW") Cc: stable(a)vger.kernel.org # 4.8 Cc: Honghui Zhang <honghui.zhang(a)mediatek.com> Acked-by: Robin Murphy <robin.murphy(a)arm.com> Reviewed-by: Yong Wu <yong.wu(a)mediatek.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/iommu/mtk_iommu_v1.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c index 10cc0b1197e8..de9153c0a82f 100644 --- a/drivers/iommu/mtk_iommu_v1.c +++ b/drivers/iommu/mtk_iommu_v1.c @@ -435,6 +435,8 @@ static int mtk_iommu_v1_create_mapping(struct device *dev, return -EINVAL; dev_iommu_priv_set(dev, platform_get_drvdata(m4updev)); + + put_device(&m4updev->dev); } ret = iommu_fwspec_add_ids(dev, args->args, 1); -- 2.49.1

3 weeks, 5 days

2
1
0 0

[PATCH v3 09/14] iommu/mediatek-v1: fix device leaks on probe()

by Johan Hovold

Make sure to drop the references taken to the larb devices during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW") Cc: stable(a)vger.kernel.org # 4.8 Cc: Honghui Zhang <honghui.zhang(a)mediatek.com> Acked-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/iommu/mtk_iommu_v1.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c index de9153c0a82f..44b965a2db92 100644 --- a/drivers/iommu/mtk_iommu_v1.c +++ b/drivers/iommu/mtk_iommu_v1.c @@ -648,8 +648,10 @@ static int mtk_iommu_v1_probe(struct platform_device *pdev) struct platform_device *plarbdev; larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i); - if (!larbnode) - return -EINVAL; + if (!larbnode) { + ret = -EINVAL; + goto out_put_larbs; + } if (!of_device_is_available(larbnode)) { of_node_put(larbnode); @@ -659,11 +661,14 @@ static int mtk_iommu_v1_probe(struct platform_device *pdev) plarbdev = of_find_device_by_node(larbnode); if (!plarbdev) { of_node_put(larbnode); - return -ENODEV; + ret = -ENODEV; + goto out_put_larbs; } if (!plarbdev->dev.driver) { of_node_put(larbnode); - return -EPROBE_DEFER; + put_device(&plarbdev->dev); + ret = -EPROBE_DEFER; + goto out_put_larbs; } data->larb_imu[i].dev = &plarbdev->dev; @@ -675,7 +680,7 @@ static int mtk_iommu_v1_probe(struct platform_device *pdev) ret = mtk_iommu_v1_hw_init(data); if (ret) - return ret; + goto out_put_larbs; ret = iommu_device_sysfs_add(&data->iommu, &pdev->dev, NULL, dev_name(&pdev->dev)); @@ -697,12 +702,17 @@ static int mtk_iommu_v1_probe(struct platform_device *pdev) iommu_device_sysfs_remove(&data->iommu); out_clk_unprepare: clk_disable_unprepare(data->bclk); +out_put_larbs: + for (i = 0; i < MTK_LARB_NR_MAX; i++) + put_device(data->larb_imu[i].dev); + return ret; } static void mtk_iommu_v1_remove(struct platform_device *pdev) { struct mtk_iommu_v1_data *data = platform_get_drvdata(pdev); + int i; iommu_device_sysfs_remove(&data->iommu); iommu_device_unregister(&data->iommu); @@ -710,6 +720,9 @@ static void mtk_iommu_v1_remove(struct platform_device *pdev) clk_disable_unprepare(data->bclk); devm_free_irq(&pdev->dev, data->irq, data); component_master_del(&pdev->dev, &mtk_iommu_v1_com_ops); + + for (i = 0; i < MTK_LARB_NR_MAX; i++) + put_device(data->larb_imu[i].dev); } static int __maybe_unused mtk_iommu_v1_suspend(struct device *dev) -- 2.49.1

3 weeks, 5 days

2
1
0 0

[PATCH 0/4] drm/amd: Check whether secure display TA loaded successfully

by Adrian Yip

Hi everyone, This is a patch series of backports from a upstream commit: c760bcda8357 ("drm/amd: Check whether secure display TA loaded successfully") to the following stable kernel trees: * 6.17.y * 6.12.y * 6.6.y * 6.1.y Each patch applied without conflicts. Compiling tests will be done for patches as I send them in. I have not tested backports personally, but Shuah khan has Kindly offered to test them. This is my first patch, please do let me know if there are any corrections or criticisms, I will take them to heart. Thank you so much Shuah for providing this opportunity! I'm very grateful for it! Respectfully, Adrian Yip Mario Limonciello (1): drm/amd: Check whether secure display TA loaded successfully drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.51.0

3 weeks, 5 days

2
7
0 0

FAILED: patch "[PATCH] arm64: debug: always unmask interrupts in el0_softstp()" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x ea0d55ae4b3207c33691a73da3443b1fd379f1d2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102040-gopher-dipping-a96a@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ea0d55ae4b3207c33691a73da3443b1fd379f1d2 Mon Sep 17 00:00:00 2001 From: Ada Couprie Diaz <ada.coupriediaz(a)arm.com> Date: Tue, 14 Oct 2025 10:25:36 +0100 Subject: [PATCH] arm64: debug: always unmask interrupts in el0_softstp() We intend that EL0 exception handlers unmask all DAIF exceptions before calling exit_to_user_mode(). When completing single-step of a suspended breakpoint, we do not call local_daif_restore(DAIF_PROCCTX) before calling exit_to_user_mode(), leaving all DAIF exceptions masked. When pseudo-NMIs are not in use this is benign. When pseudo-NMIs are in use, this is unsound. At this point interrupts are masked by both DAIF.IF and PMR_EL1, and subsequent irq flag manipulation may not work correctly. For example, a subsequent local_irq_enable() within exit_to_user_mode_loop() will only unmask interrupts via PMR_EL1 (leaving those masked via DAIF.IF), and anything depending on interrupts being unmasked (e.g. delivery of signals) will not work correctly. This was detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Move the call to `try_step_suspended_breakpoints()` outside of the check so that interrupts can be unmasked even if we don't call the step handler. Fixes: 0ac7584c08ce ("arm64: debug: split single stepping exception entry") Cc: <stable(a)vger.kernel.org> # 6.17 Signed-off-by: Ada Couprie Diaz <ada.coupriediaz(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> [catalin.marinas(a)arm.com: added Mark's rewritten commit log and some whitespace] Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index f546a914f041..a9c81715ce59 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -697,6 +697,8 @@ static void noinstr el0_breakpt(struct pt_regs *regs, unsigned long esr) static void noinstr el0_softstp(struct pt_regs *regs, unsigned long esr) { + bool step_done; + if (!is_ttbr0_addr(regs->pc)) arm64_apply_bp_hardening(); @@ -707,10 +709,10 @@ static void noinstr el0_softstp(struct pt_regs *regs, unsigned long esr) * If we are stepping a suspended breakpoint there's nothing more to do: * the single-step is complete. */ - if (!try_step_suspended_breakpoints(regs)) { - local_daif_restore(DAIF_PROCCTX); + step_done = try_step_suspended_breakpoints(regs); + local_daif_restore(DAIF_PROCCTX); + if (!step_done) do_el0_softstep(esr, regs); - } arm64_exit_to_user_mode(regs); }

3 weeks, 5 days

2
1
0 0

FAILED: patch "[PATCH] HID: multitouch: fix sticky fingers" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x 46f781e0d151844589dc2125c8cce3300546f92a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102007-puma-shawl-4634@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 46f781e0d151844589dc2125c8cce3300546f92a Mon Sep 17 00:00:00 2001 From: Benjamin Tissoires <bentiss(a)kernel.org> Date: Wed, 8 Oct 2025 16:06:58 +0200 Subject: [PATCH] HID: multitouch: fix sticky fingers The sticky fingers quirk (MT_QUIRK_STICKY_FINGERS) was only considering the case when slots were not released during the last report. This can be problematic if the firmware forgets to release a finger while others are still present. This was observed on the Synaptics DLL0945 touchpad found on the Dell XPS 9310 and the Dell Inspiron 5406. Fixes: 4f4001bc76fd ("HID: multitouch: fix rare Win 8 cases when the touch up event gets missing") Cc: stable(a)vger.kernel.org Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index 513b8673ad8d..179dc316b4b5 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -94,9 +94,8 @@ enum report_mode { TOUCHPAD_REPORT_ALL = TOUCHPAD_REPORT_BUTTONS | TOUCHPAD_REPORT_CONTACTS, }; -#define MT_IO_FLAGS_RUNNING 0 -#define MT_IO_FLAGS_ACTIVE_SLOTS 1 -#define MT_IO_FLAGS_PENDING_SLOTS 2 +#define MT_IO_SLOTS_MASK GENMASK(7, 0) /* reserve first 8 bits for slot tracking */ +#define MT_IO_FLAGS_RUNNING 32 static const bool mtrue = true; /* default for true */ static const bool mfalse; /* default for false */ @@ -172,7 +171,11 @@ struct mt_device { struct timer_list release_timer; /* to release sticky fingers */ struct hid_haptic_device *haptic; /* haptic related configuration */ struct hid_device *hdev; /* hid_device we're attached to */ - unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_*) */ + unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_RUNNING) + * first 8 bits are reserved for keeping the slot + * states, this is fine because we only support up + * to 250 slots (MT_MAX_MAXCONTACT) + */ __u8 inputmode_value; /* InputMode HID feature value */ __u8 maxcontacts; bool is_buttonpad; /* is this device a button pad? */ @@ -986,6 +989,7 @@ static void mt_release_pending_palms(struct mt_device *td, for_each_set_bit(slotnum, app->pending_palm_slots, td->maxcontacts) { clear_bit(slotnum, app->pending_palm_slots); + clear_bit(slotnum, &td->mt_io_flags); input_mt_slot(input, slotnum); input_mt_report_slot_inactive(input); @@ -1019,12 +1023,6 @@ static void mt_sync_frame(struct mt_device *td, struct mt_application *app, app->left_button_state = 0; if (td->is_haptic_touchpad) hid_haptic_pressure_reset(td->haptic); - - if (test_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags)) - set_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags); - else - clear_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags); - clear_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags); } static int mt_compute_timestamp(struct mt_application *app, __s32 value) @@ -1202,7 +1200,9 @@ static int mt_process_slot(struct mt_device *td, struct input_dev *input, input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, major); input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, minor); - set_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags); + set_bit(slotnum, &td->mt_io_flags); + } else { + clear_bit(slotnum, &td->mt_io_flags); } return 0; @@ -1337,7 +1337,7 @@ static void mt_touch_report(struct hid_device *hid, * defect. */ if (app->quirks & MT_QUIRK_STICKY_FINGERS) { - if (test_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags)) + if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100)); else @@ -1814,6 +1814,7 @@ static void mt_release_contacts(struct hid_device *hid) for (i = 0; i < mt->num_slots; i++) { input_mt_slot(input_dev, i); input_mt_report_slot_inactive(input_dev); + clear_bit(i, &td->mt_io_flags); } input_mt_sync_frame(input_dev); input_sync(input_dev); @@ -1836,7 +1837,7 @@ static void mt_expired_timeout(struct timer_list *t) */ if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags)) return; - if (test_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags)) + if (td->mt_io_flags & MT_IO_SLOTS_MASK) mt_release_contacts(hdev); clear_bit_unlock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags); }

3 weeks, 5 days

2
1
0 0

[RESEND PATCH 6.16-6.17 0/2] arm64: errata: Apply workarounds for Neoverse-V3AE

by Ryan Roberts

Hi All, This series is a backport that applies to stable kernels 6.16 and 6.17, of the recent errata workarounds for Neoverse-V3AE, which were originally posted at: https://lore.kernel.org/all/20250919145832.4035534-1-ryan.roberts@arm.com/ ... and were originally merged upstream in v6.18-rc1. Thanks, Ryan Mark Rutland (2): arm64: cputype: Add Neoverse-V3AE definitions arm64: errata: Apply workarounds for Neoverse-V3AE Documentation/arch/arm64/silicon-errata.rst | 2 ++ arch/arm64/Kconfig | 1 + arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu_errata.c | 1 + 4 files changed, 6 insertions(+) -- 2.43.0

3 weeks, 5 days

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror