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

[REGRESSION][BISECTED] intel iGPU with HDMI PLL stopped working at 1080p@120Hz 1efd5384

by Vas Novikov

Hi dear LKML and community, this is my first post here, so I'd appreciate any guidance or redirection if it's due. Starting from commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…, HDMI handling for certain refresh rates on my intel iGPU is broken. The error is still present in 6.16rc1. Specifically, this is the command that disambiguates the newer broken kernels: xrandr --output HDMI-1 --auto --scale 1x1 --mode 1920x1080 --rate 120 --pos 0x0 --output eDP-1 --off The important parts are 1920x1080 and 120Hz. When run on commits prior to the bisected above, it behaves as expected, delivering 1920x1080 @ 120Hz. When run on kernel builds with the above commit included (that commit or later), the monitor goes completely blank. After about 30 seconds, it shuts down entirely (which I assume means that from the monitor's perspective, HDMI got "disconnected"). On this link you can see my original report in the ArchLinux community, where Christian Heusel (@gromit) kindly guided me through the bisection process and built the bisection images for me to try: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/14… This link also contains the bisection history. Additional info: * The monitor and the notebook are connected via an HDMI cable, the monitor itself is a 4k@120Hz monitor. * According to `lsmod | grep -E "(i915|Xe)"`, I'm using the i915 kernel driver for the GPU. * The GPU is an iGPU from intel, specifically `Intel Core Ultra 7 155H`. * One symptom that disambiguates the working and non-working kernels, besides whether they actually have the bug, is that the broken kernels cause xrandr to additionally report the 144.05 refresh rate as possible for the monitor, whereas the non-broken kernels consistently cause xrandr to only list refresh rate 120 and below as possible. I'm only ever testing the refresh rate of 120, but the presence of the 144.05 rate is correlated. If any other information or anything is needed, please write. Thank you, Vas ---- #regzbot introduced: 1efd5384277eb71fce20922579061cd3acdb07cf #regzbot title: intel iGPU with HDMI PLL stopped working at 1080p@120Hz 1efd5384 #regzbot link: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/145

2 weeks, 3 days

3
4
0 0

[PATCH] pinctrl: nuvoton: Fix boot on ma35dx platforms

by Miquel Raynal

As part of a wider cleanup trying to get rid of OF specific APIs, an incorrect (and partially unrelated) cleanup was introduced. The goal was to replace a device_for_each_chil_node() loop including an additional condition inside by a macro doing both the loop and the check on a single line. The snippet: device_for_each_child_node(dev, child) if (fwnode_property_present(child, "gpio-controller")) continue; was replaced by: for_each_gpiochip_node(dev, child) which expands into: device_for_each_child_node(dev, child) for_each_if(fwnode_property_present(child, "gpio-controller")) This change is actually doing the opposite of what was initially expected, breaking the probe of this driver, breaking at the same time the whole boot of Nuvoton platforms (no more console, the kernel WARN()). Revert these two changes to roll back to the correct behavior. Fixes: 693c9ecd8326 ("pinctrl: nuvoton: Reduce use of OF-specific APIs") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/pinctrl/nuvoton/pinctrl-ma35.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/nuvoton/pinctrl-ma35.c b/drivers/pinctrl/nuvoton/pinctrl-ma35.c index 06ae1fe8b8c5..b51704bafd81 100644 --- a/drivers/pinctrl/nuvoton/pinctrl-ma35.c +++ b/drivers/pinctrl/nuvoton/pinctrl-ma35.c @@ -1074,7 +1074,10 @@ static int ma35_pinctrl_probe_dt(struct platform_device *pdev, struct ma35_pinct u32 idx = 0; int ret; - for_each_gpiochip_node(dev, child) { + device_for_each_child_node(dev, child) { + if (fwnode_property_present(child, "gpio-controller")) + continue; + npctl->nfunctions++; npctl->ngroups += of_get_child_count(to_of_node(child)); } @@ -1092,7 +1095,10 @@ static int ma35_pinctrl_probe_dt(struct platform_device *pdev, struct ma35_pinct if (!npctl->groups) return -ENOMEM; - for_each_gpiochip_node(dev, child) { + device_for_each_child_node(dev, child) { + if (fwnode_property_present(child, "gpio-controller")) + continue; + ret = ma35_pinctrl_parse_functions(child, npctl, idx++); if (ret) { fwnode_handle_put(child); -- 2.48.1

2 weeks, 3 days

3
3
0 0

[PATCH v2] pinctrl: qcom: msm: mark certain pins as invalid for interrupts

by Bartosz Golaszewski

From: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this. Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver") Cc: stable(a)vger.kernel.org Reviewed-by: Bjorn Andersson <andersson(a)kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> --- Changes in v2: - expand the commit message, describing the underlying code issue in detail - added a newline for better readability drivers/pinctrl/qcom/pinctrl-msm.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index f012ea88aa22c..1ff84e8c176d4 100644 --- a/drivers/pinctrl/qcom/pinctrl-msm.c +++ b/drivers/pinctrl/qcom/pinctrl-msm.c @@ -1038,6 +1038,25 @@ static bool msm_gpio_needs_dual_edge_parent_workaround(struct irq_data *d, test_bit(d->hwirq, pctrl->skip_wake_irqs); } +static void msm_gpio_irq_init_valid_mask(struct gpio_chip *gc, + unsigned long *valid_mask, + unsigned int ngpios) +{ + struct msm_pinctrl *pctrl = gpiochip_get_data(gc); + const struct msm_pingroup *g; + int i; + + bitmap_fill(valid_mask, ngpios); + + for (i = 0; i < ngpios; i++) { + g = &pctrl->soc->groups[i]; + + if (g->intr_detection_width != 1 && + g->intr_detection_width != 2) + clear_bit(i, valid_mask); + } +} + static int msm_gpio_irq_set_type(struct irq_data *d, unsigned int type) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); @@ -1441,6 +1460,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl) girq->default_type = IRQ_TYPE_NONE; girq->handler = handle_bad_irq; girq->parents[0] = pctrl->irq; + girq->init_valid_mask = msm_gpio_irq_init_valid_mask; ret = gpiochip_add_data(&pctrl->chip, pctrl); if (ret) { -- 2.48.1

2 weeks, 3 days

2
1
0 0

[PATCH v2] xhci: Disable stream for xHC controller with XHCI_BROKEN_STREAMS

by xiehongyu1＠kylinos.cn

From: Hongyu Xie <xiehongyu1(a)kylinos.cn> Disable stream for platform xHC controller with broken stream. Fixes: 14aec589327a6 ("storage: accept some UAS devices if streams are unavailable") Cc: stable(a)vger.kernel.org # 5.4 Signed-off-by: Hongyu Xie <xiehongyu1(a)kylinos.cn> --- drivers/usb/host/xhci-plat.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 6dab142e72789..c79d5ed48a08b 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -328,7 +328,8 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s } usb3_hcd = xhci_get_usb3_hcd(xhci); - if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4) + if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4 && + !(xhci->quirks & XHCI_BROKEN_STREAMS)) usb3_hcd->can_do_streams = 1; if (xhci->shared_hcd) { -- 2.25.1

2 weeks, 4 days

2
1
0 0

RE: [PATCH v5] virtio_blk: Fix disk deletion hang on device surprise removal

by Parav Pandit

Hi Michael, Stefan, > From: Parav Pandit <parav(a)nvidia.com> > Sent: 02 June 2025 08:15 AM > To: mst(a)redhat.com; stefanha(a)redhat.com; axboe(a)kernel.dk; > virtualization(a)lists.linux.dev; linux-block(a)vger.kernel.org > Cc: stable(a)vger.kernel.org; NBU-Contact-Li Rongqing (EXTERNAL) > <lirongqing(a)baidu.com>; Chaitanya Kulkarni <kch(a)nvidia.com>; > xuanzhuo(a)linux.alibaba.com; pbonzini(a)redhat.com; > jasowang(a)redhat.com; alok.a.tiwari(a)oracle.com; Parav Pandit > <parav(a)nvidia.com>; Max Gurtovoy <mgurtovoy(a)nvidia.com>; Israel > Rukshin <israelr(a)nvidia.com> > Subject: [PATCH v5] virtio_blk: Fix disk deletion hang on device surprise > removal > > When the PCI device is surprise removed, requests may not complete the > device as the VQ is marked as broken. Due to this, the disk deletion hangs. > > Fix it by aborting the requests when the VQ is broken. > > With this fix now fio completes swiftly. > An alternative of IO timeout has been considered, however when the driver > knows about unresponsive block device, swiftly clearing them enables users > and upper layers to react quickly. > > Verified with multiple device unplug iterations with pending requests in virtio > used ring and some pending with the device. > > Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci > device") > Cc: stable(a)vger.kernel.org > Reported-by: Li RongQing <lirongqing(a)baidu.com> > Closes: > https://lore.kernel.org/virtualization/c45dd68698cd47238c55fb73ca9b4741 > @baidu.com/ > Reviewed-by: Max Gurtovoy <mgurtovoy(a)nvidia.com> > Reviewed-by: Israel Rukshin <israelr(a)nvidia.com> > Signed-off-by: Parav Pandit <parav(a)nvidia.com> > > --- > v4->v5: > - fixed comment style where comment to start with one empty line at start > - Addressed comments from Alok > - fixed typo in broken vq check Did you get a chance to review this version where I fixed all the comments you proposed? [..]

2 weeks, 4 days

1
0
0 0

[PATCH v2 1/3] mtd: spinand: winbond: Fix W35N number of planes/LUN

by Miquel Raynal

There's been a mistake when extracting the geometry of the W35N02 and W35N04 chips from the datasheet. There is a single plane, however there are respectively 2 and 4 LUNs. They are actually referred in the datasheet as dies (equivalent of target), but as there is no die select operation and the chips only feature a single configuration register for the entire chip (instead of one per die), we can reasonably assume we are talking about LUNs and not dies. Reported-by: Andreas Dannenberg <dannenberg(a)ti.com> Suggested-by: Vignesh Raghavendra <vigneshr(a)ti.com> Fixes: 25e08bf66660 ("mtd: spinand: winbond: Add support for W35N02JW and W35N04JW chips") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/spi/winbond.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c index 19f8dd4a6370..2808bbd7a16e 100644 --- a/drivers/mtd/nand/spi/winbond.c +++ b/drivers/mtd/nand/spi/winbond.c @@ -289,7 +289,7 @@ static const struct spinand_info winbond_spinand_table[] = { SPINAND_ECCINFO(&w35n01jw_ooblayout, NULL)), SPINAND_INFO("W35N02JW", /* 1.8V */ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xdf, 0x22), - NAND_MEMORG(1, 4096, 128, 64, 512, 10, 2, 1, 1), + NAND_MEMORG(1, 4096, 128, 64, 512, 10, 1, 2, 1), NAND_ECCREQ(1, 512), SPINAND_INFO_OP_VARIANTS(&read_cache_octal_variants, &write_cache_octal_variants, @@ -298,7 +298,7 @@ static const struct spinand_info winbond_spinand_table[] = { SPINAND_ECCINFO(&w35n01jw_ooblayout, NULL)), SPINAND_INFO("W35N04JW", /* 1.8V */ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xdf, 0x23), - NAND_MEMORG(1, 4096, 128, 64, 512, 10, 4, 1, 1), + NAND_MEMORG(1, 4096, 128, 64, 512, 10, 1, 4, 1), NAND_ECCREQ(1, 512), SPINAND_INFO_OP_VARIANTS(&read_cache_octal_variants, &write_cache_octal_variants, -- 2.48.1

2 weeks, 4 days

1
0
0 0

RE:Custom Bags factory 2025/6/18 16:02:14

by Steven Xiu

Hi linux-stable-mirror , This is Steven from China, I would like to introduce my company - Xiamen Oready Industry & Trade Co.,Ltd. to you. My company is specialized in manufacturing & exporting all kinds of bags, backpacks, cases, etc with more than 13 years. OEM & ODM orders are welcome. If you're looking for a reliable supplier of bags, you can contact me directly. I'm at your disposal all the time. Looking forward to hearing from you. Kind regards, Steven Xiu Xiamen Oready Industry & Trade Co.,Ltd. If you no longer wish to receive these emails, please unsubscribe here. because kids have to be able to get to school. And that's what we have to do ,00:40,(Laughter) ,00:42,And my idea is this -- all these men and women should be free to decide whether they do or do not want to conceive a child

2 weeks, 4 days

1
0
0 0

[RFC PATCH 5.10 00/16] ITS mitigation for 5.10

by Pawan Gupta

This is the backport for Indirect Target Selection(ITS) mitigation for 5.10. This is only boot tested, so sending it as an RFC for now. I hope some bot picks this up for some at-scale testing. Meanwhile I am doing basic tests around ITS mitigation. In addition to commits in 5.15 ITS backport, below commits are required to make the ITS mitigation work on 5.10. These are the prime target of scrutiny: x86/alternatives: Teach text_poke_bp() to patch Jcc.d32 instructions x86/alternatives: Introduce int3_emulate_jcc() x86/bhi: Define SPEC_CTRL_BHI_DIS_S --- Borislav Petkov (AMD) (1): x86/alternative: Optimize returns patching Daniel Sneddon (1): x86/bhi: Define SPEC_CTRL_BHI_DIS_S Eric Biggers (1): x86/its: Fix build errors when CONFIG_MODULES=n Josh Poimboeuf (1): x86/alternatives: Remove faulty optimization Pawan Gupta (7): Documentation: x86/bugs/its: Add ITS documentation x86/its: Enumerate Indirect Target Selection (ITS) bug x86/its: Add support for ITS-safe indirect thunk x86/its: Add support for ITS-safe return thunk x86/its: Fix undefined reference to cpu_wants_rethunk_at() x86/its: Enable Indirect Target Selection mitigation x86/its: Add "vmexit" option to skip mitigation on some CPUs Peter Zijlstra (4): x86/alternatives: Introduce int3_emulate_jcc() x86/alternatives: Teach text_poke_bp() to patch Jcc.d32 instructions x86/its: Use dynamic thunks for indirect branches x86/its: FineIBT-paranoid vs ITS Thomas Gleixner (1): x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc() Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/indirect-target-selection.rst | 156 +++++++++++ Documentation/admin-guide/kernel-parameters.txt | 15 + arch/x86/Kconfig | 11 + arch/x86/include/asm/alternative.h | 26 ++ arch/x86/include/asm/cpufeatures.h | 6 +- arch/x86/include/asm/msr-index.h | 13 +- arch/x86/include/asm/nospec-branch.h | 11 + arch/x86/include/asm/text-patching.h | 31 +++ arch/x86/kernel/alternative.c | 308 ++++++++++++++++++++- arch/x86/kernel/cpu/bugs.c | 139 +++++++++- arch/x86/kernel/cpu/common.c | 63 ++++- arch/x86/kernel/cpu/scattered.c | 1 + arch/x86/kernel/ftrace.c | 4 +- arch/x86/kernel/kprobes/core.c | 39 +-- arch/x86/kernel/module.c | 14 +- arch/x86/kernel/static_call.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 8 + arch/x86/kvm/x86.c | 4 +- arch/x86/lib/retpoline.S | 39 +++ arch/x86/net/bpf_jit_comp.c | 8 +- drivers/base/cpu.c | 8 + include/linux/cpu.h | 2 + include/linux/module.h | 5 + 25 files changed, 842 insertions(+), 73 deletions(-) --- base-commit: 01e7e36b8606e5d4fddf795938010f7bfa3aa277 change-id: 20250609-its-5-10-a656ce2e08ce Best regards, -- Pawan

2 weeks, 4 days

3
19
0 0

[PATCH 1/4] mm/shmem, swap: improve cached mTHP handling and fix potential hung

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> The current swap-in code assumes that, when a swap entry in shmem mapping is order 0, its cached folios (if present) must be order 0 too, which turns out not always correct. The problem is shmem_split_large_entry is called before verifying the folio will eventually be swapped in, one possible race is: CPU1 CPU2 shmem_swapin_folio /* swap in of order > 0 swap entry S1 */ folio = swap_cache_get_folio /* folio = NULL */ order = xa_get_order /* order > 0 */ folio = shmem_swap_alloc_folio /* mTHP alloc failure, folio = NULL */ <... Interrupted ...> shmem_swapin_folio /* S1 is swapped in */ shmem_writeout /* S1 is swapped out, folio cached */ shmem_split_large_entry(..., S1) /* S1 is split, but the folio covering it has order > 0 now */ Now any following swapin of S1 will hang: `xa_get_order` returns 0, and folio lookup will return a folio with order > 0. The `xa_get_order(&mapping->i_pages, index) != folio_order(folio)` will always return false causing swap-in to return -EEXIST. And this looks fragile. So fix this up by allowing seeing a larger folio in swap cache, and check the whole shmem mapping range covered by the swapin have the right swap value upon inserting the folio. And drop the redundant tree walks before the insertion. This will actually improve the performance, as it avoided two redundant Xarray tree walks in the hot path, and the only side effect is that in the failure path, shmem may redundantly reallocate a few folios causing temporary slight memory pressure. And worth noting, it may seems the order and value check before inserting might help reducing the lock contention, which is not true. The swap cache layer ensures raced swapin will either see a swap cache folio or failed to do a swapin (we have SWAP_HAS_CACHE bit even if swap cache is bypassed), so holding the folio lock and checking the folio flag is already good enough for avoiding the lock contention. The chance that a folio passes the swap entry value check but the shmem mapping slot has changed should be very low. Cc: stable(a)vger.kernel.org Fixes: 058313515d5a ("mm: shmem: fix potential data corruption during shmem swapin") Fixes: 809bc86517cc ("mm: shmem: support large folio swap out") Signed-off-by: Kairui Song <kasong(a)tencent.com> --- mm/shmem.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index eda35be2a8d9..4e7ef343a29b 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -884,7 +884,9 @@ static int shmem_add_to_page_cache(struct folio *folio, pgoff_t index, void *expected, gfp_t gfp) { XA_STATE_ORDER(xas, &mapping->i_pages, index, folio_order(folio)); - long nr = folio_nr_pages(folio); + unsigned long nr = folio_nr_pages(folio); + swp_entry_t iter, swap; + void *entry; VM_BUG_ON_FOLIO(index != round_down(index, nr), folio); VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); @@ -896,14 +898,24 @@ static int shmem_add_to_page_cache(struct folio *folio, gfp &= GFP_RECLAIM_MASK; folio_throttle_swaprate(folio, gfp); + swap = iter = radix_to_swp_entry(expected); do { xas_lock_irq(&xas); - if (expected != xas_find_conflict(&xas)) { - xas_set_err(&xas, -EEXIST); - goto unlock; + xas_for_each_conflict(&xas, entry) { + /* + * The range must either be empty, or filled with + * expected swap entries. Shmem swap entries are never + * partially freed without split of both entry and + * folio, so there shouldn't be any holes. + */ + if (!expected || entry != swp_to_radix_entry(iter)) { + xas_set_err(&xas, -EEXIST); + goto unlock; + } + iter.val += 1 << xas_get_order(&xas); } - if (expected && xas_find_conflict(&xas)) { + if (expected && iter.val - nr != swap.val) { xas_set_err(&xas, -EEXIST); goto unlock; } @@ -2323,7 +2335,7 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, error = -ENOMEM; goto failed; } - } else if (order != folio_order(folio)) { + } else if (order > folio_order(folio)) { /* * Swap readahead may swap in order 0 folios into swapcache * asynchronously, while the shmem mapping can still stores @@ -2348,15 +2360,15 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, swap = swp_entry(swp_type(swap), swp_offset(swap) + offset); } + } else if (order < folio_order(folio)) { + swap.val = round_down(swp_type(swap), folio_order(folio)); } alloced: /* We have to do this with folio locked to prevent races */ folio_lock(folio); if ((!skip_swapcache && !folio_test_swapcache(folio)) || - folio->swap.val != swap.val || - !shmem_confirm_swap(mapping, index, swap) || - xa_get_order(&mapping->i_pages, index) != folio_order(folio)) { + folio->swap.val != swap.val) { error = -EEXIST; goto unlock; } -- 2.50.0

2 weeks, 4 days

3
3
0 0

+ ocfs2-reset-folio-to-null-when-get-folio-fails.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: ocfs2: reset folio to NULL when get folio fails has been added to the -mm mm-nonmm-unstable branch. Its filename is ocfs2-reset-folio-to-null-when-get-folio-fails.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: Lizhi Xu <lizhi.xu(a)windriver.com> Subject: ocfs2: reset folio to NULL when get folio fails Date: Mon, 16 Jun 2025 09:31:40 +0800 The reproducer uses FAULT_INJECTION to make memory allocation fail, which causes __filemap_get_folio() to fail, when initializing w_folios[i] in ocfs2_grab_folios_for_write(), it only returns an error code and the value of w_folios[i] is the error code, which causes ocfs2_unlock_and_free_folios() to recycle the invalid w_folios[i] when releasing folios. Link: https://lkml.kernel.org/r/20250616013140.3602219-1-lizhi.xu@windriver.com Reported-by: syzbot+c2ea94ae47cd7e3881ec(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c2ea94ae47cd7e3881ec Signed-off-by: Lizhi Xu <lizhi.xu(a)windriver.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/aops.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ocfs2/aops.c~ocfs2-reset-folio-to-null-when-get-folio-fails +++ a/fs/ocfs2/aops.c @@ -1071,6 +1071,7 @@ static int ocfs2_grab_folios_for_write(s if (IS_ERR(wc->w_folios[i])) { ret = PTR_ERR(wc->w_folios[i]); mlog_errno(ret); + wc->w_folios[i] = NULL; goto out; } } _ Patches currently in -mm which might be from lizhi.xu(a)windriver.com are ocfs2-reset-folio-to-null-when-get-folio-fails.patch

2 weeks, 4 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror