March 2025 - Linux-stable-mirror

[PATCH RESEND] fs/netfs/read_collect: add to next->prev_donated

by Max Kellermann

If multiple subrequests donate data to the same "next" request (depending on the subrequest completion order), each of them would overwrite the `prev_donated` field, causing data corruption and a BUG() crash ("Can't donate prior to front"). Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Closes: https://lore.kernel.org/netfs/CAKPOu+_4mUwYgQtRTbXCmi+-k3PGvLysnPadkmHOyB7G… Cc: stable(a)vger.kernel.org Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> Signed-off-by: David Howells <dhowells(a)redhat.com> --- fs/netfs/read_collect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/netfs/read_collect.c b/fs/netfs/read_collect.c index 8878b46589ff..cafadfe8e858 100644 --- a/fs/netfs/read_collect.c +++ b/fs/netfs/read_collect.c @@ -284,7 +284,7 @@ static bool netfs_consume_read_data(struct netfs_io_subrequest *subreq, bool was netfs_trace_donate_to_deferred_next); } else { next = list_next_entry(subreq, rreq_link); - WRITE_ONCE(next->prev_donated, excess); + WRITE_ONCE(next->prev_donated, next->prev_donated + excess); trace_netfs_donate(rreq, subreq, next, excess, netfs_trace_donate_to_next); } -- 2.47.2

3 months

4
3
0 0

6.6.84-rc1 build regression on ia64 (and possibly other architectures)

by Frank Scheiner

Dear Greg, I see that the review for 6.6.84-rc1 hasn't started yet, but as it was already available on [1], our CI has already tried to built it for ia64 in the morning. Unfortunately that failed - I assume due to the following **missing** upstream commit: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… [1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.… Build failure (see [2]): ``` [...] CC drivers/video/fbdev/core/fbcon.o drivers/video/fbdev/core/fbcon.c: In function 'fb_console_setup': drivers/video/fbdev/core/fbcon.c:478:33: error: 'fb_center_logo' undeclared (first use in this function); did you mean 'fb_prepare_logo'? 478 | fb_center_logo = true; | ^~~~~~~~~~~~~~ | fb_prepare_logo drivers/video/fbdev/core/fbcon.c:478:33: note: each undeclared identifier is reported only once for each function it appears in drivers/video/fbdev/core/fbcon.c:485:33: error: 'fb_logo_count' undeclared (first use in this function); did you mean 'file_count'? 485 | fb_logo_count = simple_strtol(options, &options, 0); | ^~~~~~~~~~~~~ | file_count make[8]: *** [scripts/Makefile.build:243: drivers/video/fbdev/core/fbcon.o] Error 1 [...] ``` [2]: https://github.com/linux-ia64/linux-stable-rc/actions/runs/13914712427/job/… [3] (fa671e4f1556e2c18e5443f777a75ae041290068 upstream) includes definitions for these variables, but they are guarded by CONFIG_LOGO. But in `drivers/video/fbdev/core/fbcon.c` those variables are used unguarded with 6.6.84-rc1. The above upstream commit (8887086) fixes that IIUC. Not build-tested yet, though. [3]: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.… Cheers, Frank

3 months

2
1
0 0

RE: Transform your business

by kristina williams

Hi again, I would appreciate your feedback on the proposal I sent earlier. Looking forward to your response. Best regards, Kristina ________________________________ From: Kristina Williams Sent: 17 March 2025 12:29 To: linux-stable-mirror(a)lists.linaro.org<mailto:linux-stable-mirror@lists.linaro.org> Subject: Transform your business Hi there, Would you like an updated contact list of Real Estate CRM Software users and customers? We can also provide contact lists for users and customers of the following companies: * AppFolio * RealPage * Buildium * CoreLogic * Yardi Voyager * Kissflow CRM * Pipedrive * HubSpot CRM Service and more... Please specify the target technology users and geographical areas of interest, so we can provide relevant information accordingly. Kind regards, Kristina Williams Lead Specialist To unsubscribe from future emails, simply reply with Stop.

3 months

1
0
0 0

Re: Patch "nvme-fc: do not ignore connectivity loss during connecting" has been added to the 6.13-stable tree

by Daniel Wagner

Hi Sasha, On Sat, Mar 15, 2025 at 09:34:40AM -0400, Sasha Levin wrote: > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. This fix is unfortunately buggy (schedule in atomic context). There is a fixup patch which would be necessary alongside this patch: f13409bb3f91 ("nvme-fc: rely on state transitions to handle connectivity loss") Thanks, Daniel > commit e0cdcd023334a757ae78a43d2fa8909dcc72ec56 > Author: Daniel Wagner <wagi(a)kernel.org> > Date: Thu Jan 9 14:30:49 2025 +0100 > > nvme-fc: do not ignore connectivity loss during connecting

3 months

2
1
0 0

Re: Patch "mm: shmem: skip swapcache for swapin of synchronous swap device" has been added to the 6.13-stable tree

by Hugh Dickins

On Tue, 18 Mar 2025, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > mm: shmem: skip swapcache for swapin of synchronous swap device > > to the 6.13-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > mm-shmem-skip-swapcache-for-swapin-of-synchronous-sw.patch > and it can be found in the queue-6.13 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 91c40c9fb0e939508d814e1ac302011d8e8213eb > Author: Baolin Wang <baolin.wang(a)linux.alibaba.com> > Date: Wed Jan 8 10:16:49 2025 +0800 > > mm: shmem: skip swapcache for swapin of synchronous swap device > > [ Upstream commit 1dd44c0af4fa1e80a4e82faa10cbf5d22da40362 ] > > With fast swap devices (such as zram), swapin latency is crucial to > applications. For shmem swapin, similar to anonymous memory swapin, we > can skip the swapcache operation to improve swapin latency. Testing 1G > shmem sequential swapin without THP enabled, I observed approximately a 6% > performance improvement: (Note: I repeated 5 times and took the mean data > for each test) > > w/o patch w/ patch changes > 534.8ms 501ms +6.3% > > In addition, currently, we always split the large swap entry stored in the > shmem mapping during shmem large folio swapin, which is not perfect, > especially with a fast swap device. We should swap in the whole large > folio instead of splitting the precious large folios to take advantage of > the large folios and improve the swapin latency if the swap device is > synchronous device, which is similar to anonymous memory mTHP swapin. > Testing 1G shmem sequential swapin with 64K mTHP and 2M mTHP, I observed > obvious performance improvement: > > mTHP=64K > w/o patch w/ patch changes > 550.4ms 169.6ms +69% > > mTHP=2M > w/o patch w/ patch changes > 542.8ms 126.8ms +77% > > Note that skipping swapcache requires attention to concurrent swapin > scenarios. Fortunately the swapcache_prepare() and > shmem_add_to_page_cache() can help identify concurrent swapin and large > swap entry split scenarios, and return -EEXIST for retry. > > [akpm(a)linux-foundation.org: use IS_ENABLED(), tweak comment grammar] > Link: https://lkml.kernel.org/r/3d9f3bd3bc6ec953054baff5134f66feeaae7c1e.17363017… > Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> > Cc: David Hildenbrand <david(a)redhat.com> > Cc: "Huang, Ying" <ying.huang(a)linux.alibaba.com> > Cc: Hugh Dickins <hughd(a)google.com> > Cc: Kairui Song <kasong(a)tencent.com> > Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> > Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> > Cc: Ryan Roberts <ryan.roberts(a)arm.com> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Stable-dep-of: 058313515d5a ("mm: shmem: fix potential data corruption during shmem swapin") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> No, NAK to this one going to stable. Hugh > > diff --git a/mm/shmem.c b/mm/shmem.c > index e10d6e0924620..6d30139d3967d 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -1903,6 +1903,65 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf, > return ERR_PTR(error); > } > > +static struct folio *shmem_swap_alloc_folio(struct inode *inode, > + struct vm_area_struct *vma, pgoff_t index, > + swp_entry_t entry, int order, gfp_t gfp) > +{ > + struct shmem_inode_info *info = SHMEM_I(inode); > + struct folio *new; > + void *shadow; > + int nr_pages; > + > + /* > + * We have arrived here because our zones are constrained, so don't > + * limit chance of success with further cpuset and node constraints. > + */ > + gfp &= ~GFP_CONSTRAINT_MASK; > + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && order > 0) { > + gfp_t huge_gfp = vma_thp_gfp_mask(vma); > + > + gfp = limit_gfp_mask(huge_gfp, gfp); > + } > + > + new = shmem_alloc_folio(gfp, order, info, index); > + if (!new) > + return ERR_PTR(-ENOMEM); > + > + nr_pages = folio_nr_pages(new); > + if (mem_cgroup_swapin_charge_folio(new, vma ? vma->vm_mm : NULL, > + gfp, entry)) { > + folio_put(new); > + return ERR_PTR(-ENOMEM); > + } > + > + /* > + * Prevent parallel swapin from proceeding with the swap cache flag. > + * > + * Of course there is another possible concurrent scenario as well, > + * that is to say, the swap cache flag of a large folio has already > + * been set by swapcache_prepare(), while another thread may have > + * already split the large swap entry stored in the shmem mapping. > + * In this case, shmem_add_to_page_cache() will help identify the > + * concurrent swapin and return -EEXIST. > + */ > + if (swapcache_prepare(entry, nr_pages)) { > + folio_put(new); > + return ERR_PTR(-EEXIST); > + } > + > + __folio_set_locked(new); > + __folio_set_swapbacked(new); > + new->swap = entry; > + > + mem_cgroup_swapin_uncharge_swap(entry, nr_pages); > + shadow = get_shadow_from_swap_cache(entry); > + if (shadow) > + workingset_refault(new, shadow); > + folio_add_lru(new); > + swap_read_folio(new, NULL); > + return new; > +} > + > /* > * When a page is moved from swapcache to shmem filecache (either by the > * usual swapin of shmem_get_folio_gfp(), or by the less common swapoff of > @@ -2006,7 +2065,8 @@ static int shmem_replace_folio(struct folio **foliop, gfp_t gfp, > } > > static void shmem_set_folio_swapin_error(struct inode *inode, pgoff_t index, > - struct folio *folio, swp_entry_t swap) > + struct folio *folio, swp_entry_t swap, > + bool skip_swapcache) > { > struct address_space *mapping = inode->i_mapping; > swp_entry_t swapin_error; > @@ -2022,7 +2082,8 @@ static void shmem_set_folio_swapin_error(struct inode *inode, pgoff_t index, > > nr_pages = folio_nr_pages(folio); > folio_wait_writeback(folio); > - delete_from_swap_cache(folio); > + if (!skip_swapcache) > + delete_from_swap_cache(folio); > /* > * Don't treat swapin error folio as alloced. Otherwise inode->i_blocks > * won't be 0 when inode is released and thus trigger WARN_ON(i_blocks) > @@ -2126,6 +2187,7 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, > struct shmem_inode_info *info = SHMEM_I(inode); > struct swap_info_struct *si; > struct folio *folio = NULL; > + bool skip_swapcache = false; > swp_entry_t swap; > int error, nr_pages; > > @@ -2147,6 +2209,8 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, > /* Look it up and read it in.. */ > folio = swap_cache_get_folio(swap, NULL, 0); > if (!folio) { > + int order = xa_get_order(&mapping->i_pages, index); > + bool fallback_order0 = false; > int split_order; > > /* Or update major stats only when swapin succeeds?? */ > @@ -2156,6 +2220,33 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, > count_memcg_event_mm(fault_mm, PGMAJFAULT); > } > > + /* > + * If uffd is active for the vma, we need per-page fault > + * fidelity to maintain the uffd semantics, then fallback > + * to swapin order-0 folio, as well as for zswap case. > + */ > + if (order > 0 && ((vma && unlikely(userfaultfd_armed(vma))) || > + !zswap_never_enabled())) > + fallback_order0 = true; > + > + /* Skip swapcache for synchronous device. */ > + if (!fallback_order0 && data_race(si->flags & SWP_SYNCHRONOUS_IO)) { > + folio = shmem_swap_alloc_folio(inode, vma, index, swap, order, gfp); > + if (!IS_ERR(folio)) { > + skip_swapcache = true; > + goto alloced; > + } > + > + /* > + * Fallback to swapin order-0 folio unless the swap entry > + * already exists. > + */ > + error = PTR_ERR(folio); > + folio = NULL; > + if (error == -EEXIST) > + goto failed; > + } > + > /* > * Now swap device can only swap in order 0 folio, then we > * should split the large swap entry stored in the pagecache > @@ -2186,9 +2277,10 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, > } > } > > +alloced: > /* We have to do this with folio locked to prevent races */ > folio_lock(folio); > - if (!folio_test_swapcache(folio) || > + if ((!skip_swapcache && !folio_test_swapcache(folio)) || > folio->swap.val != swap.val || > !shmem_confirm_swap(mapping, index, swap)) { > error = -EEXIST; > @@ -2224,7 +2316,12 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, > if (sgp == SGP_WRITE) > folio_mark_accessed(folio); > > - delete_from_swap_cache(folio); > + if (skip_swapcache) { > + folio->swap.val = 0; > + swapcache_clear(si, swap, nr_pages); > + } else { > + delete_from_swap_cache(folio); > + } > folio_mark_dirty(folio); > swap_free_nr(swap, nr_pages); > put_swap_device(si); > @@ -2235,8 +2332,11 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, > if (!shmem_confirm_swap(mapping, index, swap)) > error = -EEXIST; > if (error == -EIO) > - shmem_set_folio_swapin_error(inode, index, folio, swap); > + shmem_set_folio_swapin_error(inode, index, folio, swap, > + skip_swapcache); > unlock: > + if (skip_swapcache) > + swapcache_clear(si, swap, folio_nr_pages(folio)); > if (folio) { > folio_unlock(folio); > folio_put(folio); >

3 months

3
2
0 0

[PATCH 6.12 0/8] KVM: arm64: Backport of SVE fixes to v6.12

by Mark Brown

This series backports some recent fixes for SVE/KVM interactions from Mark Rutland to v6.12. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Fuad Tabba (1): KVM: arm64: Calculate cptr_el2 traps on activating traps Mark Rutland (7): KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state KVM: arm64: Remove host FPSIMD saving for non-protected KVM KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN KVM: arm64: Refactor exit handlers KVM: arm64: Mark some header functions as inline KVM: arm64: Eagerly switch ZCR_EL{1,2} arch/arm64/include/asm/kvm_host.h | 25 ++---- arch/arm64/kernel/fpsimd.c | 25 ------ arch/arm64/kvm/arm.c | 9 --- arch/arm64/kvm/fpsimd.c | 100 ++---------------------- arch/arm64/kvm/hyp/entry.S | 5 ++ arch/arm64/kvm/hyp/include/hyp/switch.h | 133 ++++++++++++++++++++++--------- arch/arm64/kvm/hyp/nvhe/hyp-main.c | 15 ++-- arch/arm64/kvm/hyp/nvhe/pkvm.c | 29 ------- arch/arm64/kvm/hyp/nvhe/switch.c | 134 ++++++++++++++++++-------------- arch/arm64/kvm/hyp/vhe/switch.c | 21 ++--- 10 files changed, 204 insertions(+), 292 deletions(-) --- base-commit: e9cc806c0152fa9993f817cebf42989a3e2530bb change-id: 20250227-stable-sve-6-12-777778ad28fb Best regards, -- Mark Brown <broonie(a)kernel.org>

3 months

9
25
0 0

[PATCH v2 2/2] sched/topology: Fix EAS freq-invariance print

by Christian Loehle

Add the missing newline on frequency invariance check to ensure the EAS abort reason doesn't go missing. Fixes: fa50e2b452c6 ("sched/topology: Condition EAS enablement on FIE support") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Loehle <christian.loehle(a)arm.com> Reviewed-by: Vincent Guittot <vincent.guittot(a)linaro.org> --- kernel/sched/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 27f14a775004..18e804b416f5 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -245,7 +245,7 @@ static bool sched_is_eas_possible(const struct cpumask *cpu_mask) if (!arch_scale_freq_invariant()) { if (sched_debug()) { - pr_info("rd %*pbl: Checking EAS: frequency-invariant load tracking not yet supported", + pr_info("rd %*pbl: Checking EAS: frequency-invariant load tracking not yet supported\n", cpumask_pr_args(cpu_mask)); } return false; -- 2.34.1

3 months

1
0
0 0

[PATCH v2 1/2] sched/topology: Fix EAS cpufreq check print

by Christian Loehle

Add the missing newline on cpufreq check to ensure the EAS abort reason doesn't go missing. Fixes: 8f833c82cdab ("sched/topology: Change behaviour of the 'sched_energy_aware' sysctl, based on the platform") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Loehle <christian.loehle(a)arm.com> Reviewed-by: Vincent Guittot <vincent.guittot(a)linaro.org> --- kernel/sched/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index c49aea8c1025..27f14a775004 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -256,7 +256,7 @@ static bool sched_is_eas_possible(const struct cpumask *cpu_mask) policy = cpufreq_cpu_get(i); if (!policy) { if (sched_debug()) { - pr_info("rd %*pbl: Checking EAS, cpufreq policy not set for CPU: %d", + pr_info("rd %*pbl: Checking EAS, cpufreq policy not set for CPU: %d\n", cpumask_pr_args(cpu_mask), i); } return false; -- 2.34.1

3 months

1
0
0 0

[PATCH] mmc: sdhci-omap: Disable MMC_CAP_AGGRESSIVE_PM for eMMC/SD

by Ulf Hansson

We have received reports about cards can become corrupt related to the aggressive PM support. Let's make a partial revert of the change that enabled the feature. Reported-by: David Owens <daowens01(a)gmail.com> Reported-by: Romain Naour <romain.naour(a)smile.fr> Reported-by: Robert Nelson <robertcnelson(a)gmail.com> Tested-by: Robert Nelson <robertcnelson(a)gmail.com> Fixes: 3edf588e7fe0 ("mmc: sdhci-omap: Allow SDIO card power off and enable aggressive PM") Cc: stable(a)vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> --- drivers/mmc/host/sdhci-omap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c index 54d795205fb4..26a9a8b5682a 100644 --- a/drivers/mmc/host/sdhci-omap.c +++ b/drivers/mmc/host/sdhci-omap.c @@ -1339,8 +1339,8 @@ static int sdhci_omap_probe(struct platform_device *pdev) /* R1B responses is required to properly manage HW busy detection. */ mmc->caps |= MMC_CAP_NEED_RSP_BUSY; - /* Allow card power off and runtime PM for eMMC/SD card devices */ - mmc->caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_AGGRESSIVE_PM; + /* Enable SDIO card power off. */ + mmc->caps |= MMC_CAP_POWER_OFF_CARD; ret = sdhci_setup_host(host); if (ret) -- 2.43.0

3 months

4
5
0 0

[PATCH 6.1] ubi: Add a check for ubi_num

by Denis Arefev

From: Denis Arefev <arefev(a)swemel.ru> commit 97bbf9e312c3fbaf0baa56120238825d2eb23b8a upstream. Added a check for ubi_num for negative numbers If the variable ubi_num takes negative values then we get: qemu-system-arm ... -append "ubi.mtd=0,0,0,-22222345" ... [ 0.745065] ubi_attach_mtd_dev from ubi_init+0x178/0x218 [ 0.745230] ubi_init from do_one_initcall+0x70/0x1ac [ 0.745344] do_one_initcall from kernel_init_freeable+0x198/0x224 [ 0.745474] kernel_init_freeable from kernel_init+0x18/0x134 [ 0.745600] kernel_init from ret_from_fork+0x14/0x28 [ 0.745727] Exception stack(0x90015fb0 to 0x90015ff8) Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Denis Arefev <arefev(a)swemel.ru> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- drivers/mtd/ubi/build.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 6fbd77dc1d18..6a7577e57617 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -1460,9 +1460,9 @@ static int ubi_mtd_param_parse(const char *val, const struct kernel_param *kp) if (token) { int err = kstrtoint(token, 10, &p->ubi_num); - if (err) { - pr_err("UBI error: bad value for ubi_num parameter: %s", - token); + if (err || p->ubi_num < UBI_DEV_NUM_AUTO) { + pr_err("UBI error: bad value for ubi_num parameter: %s\n", + token); return -EINVAL; } } else -- 2.43.0

3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025