May 2025 - Linux-stable-mirror

[to-be-updated] x86-kexec-fix-potential-cmem-ranges-out-of-bounds.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: x86/kexec: fix potential cmem->ranges out of bounds has been removed from the -mm tree. Its filename was x86-kexec-fix-potential-cmem-ranges-out-of-bounds.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: fuqiang wang <fuqiang.wang(a)easystack.cn> Subject: x86/kexec: fix potential cmem->ranges out of bounds Date: Mon, 8 Jan 2024 21:06:47 +0800 In memmap_exclude_ranges(), elfheader will be excluded from crashk_res. In the current x86 architecture code, the elfheader is always allocated at crashk_res.start. It seems that there won't be a new split range. But it depends on the allocation position of elfheader in crashk_res. To avoid potential out of bounds in future, add a extra slot. The similar issue also exists in fill_up_crash_elf_data(). The range to be excluded is [0, 1M], start (0) is special and will not appear in the middle of existing cmem->ranges[]. But in cast the low 1M could be changed in the future, add a extra slot too. Without this patch, kdump kernel will fail to be loaded by kexec_file_load, [ 139.736948] UBSAN: array-index-out-of-bounds in arch/x86/kernel/crash.c:350:25 [ 139.742360] index 0 is out of range for type 'range [*]' [ 139.745695] CPU: 0 UID: 0 PID: 5778 Comm: kexec Not tainted 6.15.0-0.rc3.20250425git02ddfb981de8.32.fc43.x86_64 #1 PREEMPT(lazy) [ 139.745698] Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 [ 139.745699] Call Trace: [ 139.745700] <TASK> [ 139.745701] dump_stack_lvl+0x5d/0x80 [ 139.745706] ubsan_epilogue+0x5/0x2b [ 139.745709] __ubsan_handle_out_of_bounds.cold+0x54/0x59 [ 139.745711] crash_setup_memmap_entries+0x2d9/0x330 [ 139.745716] setup_boot_parameters+0xf8/0x6a0 [ 139.745720] bzImage64_load+0x41b/0x4e0 [ 139.745722] ? find_next_iomem_res+0x109/0x140 [ 139.745727] ? locate_mem_hole_callback+0x109/0x170 [ 139.745737] kimage_file_alloc_init+0x1ef/0x3e0 [ 139.745740] __do_sys_kexec_file_load+0x180/0x2f0 [ 139.745742] do_syscall_64+0x7b/0x160 [ 139.745745] ? do_user_addr_fault+0x21a/0x690 [ 139.745747] ? exc_page_fault+0x7e/0x1a0 [ 139.745749] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 139.745751] RIP: 0033:0x7f7712c84e4d Previously discussed link: [1] https://lore.kernel.org/kexec/ZXk2oBf%2FT1Ul6o0c@MiWiFi-R3L-srv/ [2] https://lore.kernel.org/kexec/273284e8-7680-4f5f-8065-c5d780987e59@easystac… [3] https://lore.kernel.org/kexec/ZYQ6O%2F57sHAPxTHm@MiWiFi-R3L-srv/ Link: https://lkml.kernel.org/r/20240108130720.228478-1-fuqiang.wang@easystack.cn Signed-off-by: fuqiang wang <fuqiang.wang(a)easystack.cn> Acked-by: Baoquan He <bhe(a)redhat.com> Reported-by: Coiby Xu <coxu(a)redhat.com> Closes: https://lkml.kernel.org/r/4de3c2onosr7negqnfhekm4cpbklzmsimgdfv33c52dktqpza… Cc: Vivek Goyal <vgoyal(a)redhat.com> Cc: Dave Young <dyoung(a)redhat.com> Cc: <x86(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/x86/kernel/crash.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/crash.c~x86-kexec-fix-potential-cmem-ranges-out-of-bounds +++ a/arch/x86/kernel/crash.c @@ -165,8 +165,18 @@ static struct crash_mem *fill_up_crash_e /* * Exclusion of crash region and/or crashk_low_res may cause * another range split. So add extra two slots here. + * + * Exclusion of low 1M may not cause another range split, because the + * range of exclude is [0, 1M] and the condition for splitting a new + * region is that the start, end parameters are both in a certain + * existing region in cmem and cannot be equal to existing region's + * start or end. Obviously, the start of [0, 1M] cannot meet this + * condition. + * + * But in order to lest the low 1M could be changed in the future, + * (e.g. [stare, 1M]), add a extra slot. */ - nr_ranges += 2; + nr_ranges += 3; cmem = vzalloc(struct_size(cmem, ranges, nr_ranges)); if (!cmem) return NULL; @@ -298,9 +308,16 @@ int crash_setup_memmap_entries(struct ki struct crash_memmap_data cmd; struct crash_mem *cmem; - cmem = vzalloc(struct_size(cmem, ranges, 1)); + /* + * In the current x86 architecture code, the elfheader is always + * allocated at crashk_res.start. But it depends on the allocation + * position of elfheader in crashk_res. To avoid potential out of + * bounds in future, add a extra slot. + */ + cmem = vzalloc(struct_size(cmem, ranges, 2)); if (!cmem) return -ENOMEM; + cmem->max_nr_ranges = 2; memset(&cmd, 0, sizeof(struct crash_memmap_data)); cmd.params = params; _ Patches currently in -mm which might be from fuqiang.wang(a)easystack.cn are

2 months

1
0
0 0

[PATCH 1/2] iio: Fix scan mask subset check logic

by Fabio Estevam

From: Fabio Estevam <festevam(a)denx.de> Since commit 2718f15403fb ("iio: sanity check available_scan_masks array"), verbose and misleading warnings are printed for devices like the MAX11601: max1363 1-0064: available_scan_mask 8 subset of 0. Never used max1363 1-0064: available_scan_mask 9 subset of 0. Never used max1363 1-0064: available_scan_mask 10 subset of 0. Never used max1363 1-0064: available_scan_mask 11 subset of 0. Never used max1363 1-0064: available_scan_mask 12 subset of 0. Never used max1363 1-0064: available_scan_mask 13 subset of 0. Never used ... [warnings continue] Fix the available_scan_masks sanity check logic so that it only prints the warning when an element of available_scan_mask is in fact a subset of a previous one. These warnings incorrectly report that later scan masks are subsets of the first one, even when they are not. The issue lies in the logic that checks for subset relationships between scan masks. Fix the subset detection to correctly compare each mask only against previous masks, and only warn when a true subset is found. With this fix, the warning output becomes both correct and more informative: max1363 1-0064: Mask 7 (0xc) is a subset of mask 6 (0xf) and will be ignored Cc: stable(a)vger.kernel.org Fixes: 2718f15403fb ("iio: sanity check available_scan_masks array") Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- drivers/iio/industrialio-core.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index 6a6568d4a2cb..855d5fd3e6b2 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -1904,6 +1904,11 @@ static int iio_check_extended_name(const struct iio_dev *indio_dev) static const struct iio_buffer_setup_ops noop_ring_setup_ops; +static int is_subset(unsigned long a, unsigned long b) +{ + return (a & ~b) == 0; +} + static void iio_sanity_check_avail_scan_masks(struct iio_dev *indio_dev) { unsigned int num_masks, masklength, longs_per_mask; @@ -1947,21 +1952,13 @@ static void iio_sanity_check_avail_scan_masks(struct iio_dev *indio_dev) * available masks in the order of preference (presumably the least * costy to access masks first). */ - for (i = 0; i < num_masks - 1; i++) { - const unsigned long *mask1; - int j; - mask1 = av_masks + i * longs_per_mask; - for (j = i + 1; j < num_masks; j++) { - const unsigned long *mask2; - - mask2 = av_masks + j * longs_per_mask; - if (bitmap_subset(mask2, mask1, masklength)) + for (i = 1; i < num_masks; ++i) + for (int j = 0; j < i; ++j) + if (is_subset(av_masks[i], av_masks[j])) dev_warn(indio_dev->dev.parent, - "available_scan_mask %d subset of %d. Never used\n", - j, i); - } - } + "Mask %d (0x%lx) is a subset of mask %d (0x%lx) and will be ignored\n", + i, av_masks[i], j, av_masks[j]); } /** -- 2.34.1

2 months

3
17
0 0

[PATCH v2] drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()

by Vitor Soares

From: Vitor Soares <vitor.soares(a)toradex.com> The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with SET_RUNTIME_PM_OPS(), enabling suspend/resume handling through the _enable()/_disable() hooks managed by the DRM framework for both runtime and system-wide PM. Cc: <stable(a)vger.kernel.org> # 6.1.x Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Signed-off-by: Vitor Soares <vitor.soares(a)toradex.com> --- v1 -> v2 - Rely only on SET_RUNTIME_PM_OPS() for the PM. drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index b022dd6e6b6e..5a31783fe856 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -1258,7 +1258,7 @@ static const struct mipi_dsi_host_ops cdns_dsi_ops = { .transfer = cdns_dsi_transfer, }; -static int __maybe_unused cdns_dsi_resume(struct device *dev) +static int cdns_dsi_resume(struct device *dev) { struct cdns_dsi *dsi = dev_get_drvdata(dev); @@ -1269,7 +1269,7 @@ static int __maybe_unused cdns_dsi_resume(struct device *dev) return 0; } -static int __maybe_unused cdns_dsi_suspend(struct device *dev) +static int cdns_dsi_suspend(struct device *dev) { struct cdns_dsi *dsi = dev_get_drvdata(dev); @@ -1279,8 +1279,9 @@ static int __maybe_unused cdns_dsi_suspend(struct device *dev) return 0; } -static UNIVERSAL_DEV_PM_OPS(cdns_dsi_pm_ops, cdns_dsi_suspend, cdns_dsi_resume, - NULL); +static const struct dev_pm_ops cdns_dsi_pm_ops = { + SET_RUNTIME_PM_OPS(cdns_dsi_suspend, cdns_dsi_resume, NULL) +}; static int cdns_dsi_drm_probe(struct platform_device *pdev) { -- 2.34.1

2 months

2
1
0 0

Missing patch in 6.12.27 - breaks UM target builds

by Christian Lamparter

Hi, On 3/14/25 2:08 PM, Benjamin Berg wrote: > From: Benjamin Berg <benjamin.berg(a)intel.com> > um: work around sched_yield not yielding in time-travel mode > > sched_yield by a userspace may not actually cause scheduling in > time-travel mode as no time has passed. In the case seen it appears to > be a badly implemented userspace spinlock in ASAN. Unfortunately, with > time-travel it causes an extreme slowdown or even deadlock depending on > the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS). > > Work around it by accounting time to the process whenever it executes a > sched_yield syscall. > > Signed-off-by: Benjamin Berg <benjamin.berg(a)intel.com> From what I can tell the patch mentioned above was backported to 6.12.27 by: <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arc…> but without the upstream |Commit 0b8b2668f9981c1fefc2ef892bd915288ef01f33 |Author: Benjamin Berg <benjamin.berg(a)intel.com> |Date: Thu Oct 10 16:25:37 2024 +0200 | um: insert scheduler ticks when userspace does not yield | | In time-travel mode userspace can do a lot of work without any time | passing. Unfortunately, this can result in OOM situations as the RCU | core code will never be run. [...] the kernel build for 6.12.27 for the UM-Target will fail: | /usr/bin/ld: arch/um/kernel/skas/syscall.o: in function `handle_syscall': linux-6.12.27/arch/um/kernel/skas/syscall.c:43:(.text+0xa2): undefined reference to `tt_extra_sched_jiffies' | collect2: error: ld returned 1 exit status is it possible to backport 0b8b2668f9981c1fefc2ef892bd915288ef01f33 too? Or is it better to revert 887c5c12e80c8424bd471122d2e8b6b462e12874 again in the stable releases? Best Regards, Christian Lamparter > > --- > > I suspect it is this code in ASAN that uses sched_yield > https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_co… > though there are also some other places that use sched_yield. > > I doubt that code is reasonable. At the same time, not sure that > sched_yield is behaving as advertised either as it obviously is not > necessarily relinquishing the CPU. > --- > arch/um/include/linux/time-internal.h | 2 ++ > arch/um/kernel/skas/syscall.c | 11 +++++++++++ > 2 files changed, 13 insertions(+) > > diff --git a/arch/um/include/linux/time-internal.h b/arch/um/include/linux/time-internal.h > index b22226634ff6..138908b999d7 100644 > --- a/arch/um/include/linux/time-internal.h > +++ b/arch/um/include/linux/time-internal.h > @@ -83,6 +83,8 @@ extern void time_travel_not_configured(void); > #define time_travel_del_event(...) time_travel_not_configured() > #endif /* CONFIG_UML_TIME_TRAVEL_SUPPORT */ > > +extern unsigned long tt_extra_sched_jiffies; > + > /* > * Without CONFIG_UML_TIME_TRAVEL_SUPPORT this is a linker error if used, > * which is intentional since we really shouldn't link it in that case. > diff --git a/arch/um/kernel/skas/syscall.c b/arch/um/kernel/skas/syscall.c > index b09e85279d2b..a5beaea2967e 100644 > --- a/arch/um/kernel/skas/syscall.c > +++ b/arch/um/kernel/skas/syscall.c > @@ -31,6 +31,17 @@ void handle_syscall(struct uml_pt_regs *r) > goto out; > > syscall = UPT_SYSCALL_NR(r); > + > + /* > + * If no time passes, then sched_yield may not actually yield, causing > + * broken spinlock implementations in userspace (ASAN) to hang for long > + * periods of time. > + */ > + if ((time_travel_mode == TT_MODE_INFCPU || > + time_travel_mode == TT_MODE_EXTERNAL) && > + syscall == __NR_sched_yield) > + tt_extra_sched_jiffies += 1; > + > if (syscall >= 0 && syscall < __NR_syscalls) { > unsigned long ret = EXECUTE_SYSCALL(syscall, regs); >

2 months

2
1
0 0

[PATCH] riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL

by Nam Cao

When userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is not available, the kernel crashes: Oops - illegal instruction [#1] [snip] epc : set_tagged_addr_ctrl+0x112/0x15a ra : set_tagged_addr_ctrl+0x74/0x15a epc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10 [snip] status: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002 set_tagged_addr_ctrl+0x112/0x15a __riscv_sys_prctl+0x352/0x73c do_trap_ecall_u+0x17c/0x20c andle_exception+0x150/0x15c Fix it by checking if Supm is available. Fixes: 09d6775f503b ("riscv: Add support for userspace pointer masking") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: stable(a)vger.kernel.org --- arch/riscv/kernel/process.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c index 7c244de77180..3db2c0c07acd 100644 --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -275,6 +275,9 @@ long set_tagged_addr_ctrl(struct task_struct *task, unsigned long arg) unsigned long pmm; u8 pmlen; + if (!riscv_has_extension_unlikely(RISCV_ISA_EXT_SUPM)) + return -EINVAL; + if (is_compat_thread(ti)) return -EINVAL; -- 2.39.5

2 months

4
7
0 0

[PATCH] f2fs: fix to return correct error number in f2fs_sync_node_pages()

by Chao Yu

If __write_node_folio() failed, it will return AOP_WRITEPAGE_ACTIVATE, the incorrect return value may be passed to userspace in below path, fix it. - sync_filesystem - sync_fs - f2fs_issue_checkpoint - block_operations - f2fs_sync_node_pages - __write_node_folio : return AOP_WRITEPAGE_ACTIVATE Cc: stable(a)vger.kernel.org Reported-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Chao Yu <chao(a)kernel.org> --- fs/f2fs/node.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index ec74eb9982a5..69308523c34e 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -2092,10 +2092,14 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi, ret = __write_node_folio(folio, false, &submitted, wbc, do_balance, io_type, NULL); - if (ret) + if (ret) { folio_unlock(folio); - else if (submitted) + folio_batch_release(&fbatch); + ret = -EIO; + goto out; + } else if (submitted) { nwritten++; + } if (--wbc->nr_to_write == 0) break; -- 2.49.0

2 months

2
1
0 0

[PATCH 1/6] f2fs: fix to return correct error number in f2fs_sync_node_pages()

by Christoph Hellwig

From: Chao Yu <chao(a)kernel.org> If __write_node_folio() failed, it will return AOP_WRITEPAGE_ACTIVATE, the incorrect return value may be passed to userspace in below path, fix it. - sync_filesystem - sync_fs - f2fs_issue_checkpoint - block_operations - f2fs_sync_node_pages - __write_node_folio : return AOP_WRITEPAGE_ACTIVATE Cc: stable(a)vger.kernel.org Reported-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Chao Yu <chao(a)kernel.org> --- fs/f2fs/node.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index ec74eb9982a5..69308523c34e 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -2092,10 +2092,14 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi, ret = __write_node_folio(folio, false, &submitted, wbc, do_balance, io_type, NULL); - if (ret) + if (ret) { folio_unlock(folio); - else if (submitted) + folio_batch_release(&fbatch); + ret = -EIO; + goto out; + } else if (submitted) { nwritten++; + } if (--wbc->nr_to_write == 0) break; -- 2.47.2

2 months

2
1
0 0

FAILED: patch "[PATCH] mm: page_alloc: speed up fallbacks in rmqueue_bulk()" 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 90abee6d7895d5eef18c91d870d8168be4e76e9d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042150-hardiness-hunting-0780@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 90abee6d7895d5eef18c91d870d8168be4e76e9d Mon Sep 17 00:00:00 2001 From: Johannes Weiner <hannes(a)cmpxchg.org> Date: Mon, 7 Apr 2025 14:01:53 -0400 Subject: [PATCH] mm: page_alloc: speed up fallbacks in rmqueue_bulk() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The test robot identified c2f6ea38fc1b ("mm: page_alloc: don't steal single pages from biggest buddy") as the root cause of a 56.4% regression in vm-scalability::lru-file-mmap-read. Carlos reports an earlier patch, c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion"), as the root cause for a regression in worst-case zone->lock+irqoff hold times. Both of these patches modify the page allocator's fallback path to be less greedy in an effort to stave off fragmentation. The flip side of this is that fallbacks are also less productive each time around, which means the fallback search can run much more frequently. Carlos' traces point to rmqueue_bulk() specifically, which tries to refill the percpu cache by allocating a large batch of pages in a loop. It highlights how once the native freelists are exhausted, the fallback code first scans orders top-down for whole blocks to claim, then falls back to a bottom-up search for the smallest buddy to steal. For the next batch page, it goes through the same thing again. This can be made more efficient. Since rmqueue_bulk() holds the zone->lock over the entire batch, the freelists are not subject to outside changes; when the search for a block to claim has already failed, there is no point in trying again for the next page. Modify __rmqueue() to remember the last successful fallback mode, and restart directly from there on the next rmqueue_bulk() iteration. Oliver confirms that this improves beyond the regression that the test robot reported against c2f6ea38fc1b: commit: f3b92176f4 ("tools/selftests: add guard region test for /proc/$pid/pagemap") c2f6ea38fc ("mm: page_alloc: don't steal single pages from biggest buddy") acc4d5ff0b ("Merge tag 'net-6.15-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") 2c847f27c3 ("mm: page_alloc: speed up fallbacks in rmqueue_bulk()") <--- your patch f3b92176f4f7100f c2f6ea38fc1b640aa7a2e155cc1 acc4d5ff0b61eb1715c498b6536 2c847f27c37da65a93d23c237c5 ---------------- --------------------------- --------------------------- --------------------------- %stddev %change %stddev %change %stddev %change %stddev \ | \ | \ | \ 25525364 ± 3% -56.4% 11135467 -57.8% 10779336 +31.6% 33581409 vm-scalability.throughput Carlos confirms that worst-case times are almost fully recovered compared to before the earlier culprit patch: 2dd482ba627d (before freelist hygiene): 1ms c0cd6f557b90 (after freelist hygiene): 90ms next-20250319 (steal smallest buddy): 280ms this patch : 8ms [jackmanb(a)google.com: comment updates] Link: https://lkml.kernel.org/r/D92AC0P9594X.3BML64MUKTF8Z@google.com [hannes(a)cmpxchg.org: reset rmqueue_mode in rmqueue_buddy() error loop, per Yunsheng Lin] Link: https://lkml.kernel.org/r/20250409140023.GA2313@cmpxchg.org Link: https://lkml.kernel.org/r/20250407180154.63348-1-hannes@cmpxchg.org Fixes: c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block conversion") Fixes: c2f6ea38fc1b ("mm: page_alloc: don't steal single pages from biggest buddy") Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Signed-off-by: Brendan Jackman <jackmanb(a)google.com> Reported-by: kernel test robot <oliver.sang(a)intel.com> Reported-by: Carlos Song <carlos.song(a)nxp.com> Tested-by: Carlos Song <carlos.song(a)nxp.com> Tested-by: kernel test robot <oliver.sang(a)intel.com> Closes: https://lore.kernel.org/oe-lkp/202503271547.fc08b188-lkp@intel.com Reviewed-by: Brendan Jackman <jackmanb(a)google.com> Tested-by: Shivank Garg <shivankg(a)amd.com> Acked-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> [6.10+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 9a219fe8e130..1715e34b91af 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2183,23 +2183,15 @@ try_to_claim_block(struct zone *zone, struct page *page, } /* - * Try finding a free buddy page on the fallback list. - * - * This will attempt to claim a whole pageblock for the requested type - * to ensure grouping of such requests in the future. - * - * If a whole block cannot be claimed, steal an individual page, regressing to - * __rmqueue_smallest() logic to at least break up as little contiguity as - * possible. + * Try to allocate from some fallback migratetype by claiming the entire block, + * i.e. converting it to the allocation's start migratetype. * * The use of signed ints for order and current_order is a deliberate * deviation from the rest of this file, to make the for loop * condition simpler. - * - * Return the stolen page, or NULL if none can be found. */ static __always_inline struct page * -__rmqueue_fallback(struct zone *zone, int order, int start_migratetype, +__rmqueue_claim(struct zone *zone, int order, int start_migratetype, unsigned int alloc_flags) { struct free_area *area; @@ -2237,14 +2229,29 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype, page = try_to_claim_block(zone, page, current_order, order, start_migratetype, fallback_mt, alloc_flags); - if (page) - goto got_one; + if (page) { + trace_mm_page_alloc_extfrag(page, order, current_order, + start_migratetype, fallback_mt); + return page; + } } - if (alloc_flags & ALLOC_NOFRAGMENT) - return NULL; + return NULL; +} + +/* + * Try to steal a single page from some fallback migratetype. Leave the rest of + * the block as its current migratetype, potentially causing fragmentation. + */ +static __always_inline struct page * +__rmqueue_steal(struct zone *zone, int order, int start_migratetype) +{ + struct free_area *area; + int current_order; + struct page *page; + int fallback_mt; + bool claim_block; - /* No luck claiming pageblock. Find the smallest fallback page */ for (current_order = order; current_order < NR_PAGE_ORDERS; current_order++) { area = &(zone->free_area[current_order]); fallback_mt = find_suitable_fallback(area, current_order, @@ -2254,25 +2261,28 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype, page = get_page_from_free_area(area, fallback_mt); page_del_and_expand(zone, page, order, current_order, fallback_mt); - goto got_one; + trace_mm_page_alloc_extfrag(page, order, current_order, + start_migratetype, fallback_mt); + return page; } return NULL; - -got_one: - trace_mm_page_alloc_extfrag(page, order, current_order, - start_migratetype, fallback_mt); - - return page; } +enum rmqueue_mode { + RMQUEUE_NORMAL, + RMQUEUE_CMA, + RMQUEUE_CLAIM, + RMQUEUE_STEAL, +}; + /* * Do the hard work of removing an element from the buddy allocator. * Call me with the zone->lock already held. */ static __always_inline struct page * __rmqueue(struct zone *zone, unsigned int order, int migratetype, - unsigned int alloc_flags) + unsigned int alloc_flags, enum rmqueue_mode *mode) { struct page *page; @@ -2291,16 +2301,48 @@ __rmqueue(struct zone *zone, unsigned int order, int migratetype, } } - page = __rmqueue_smallest(zone, order, migratetype); - if (unlikely(!page)) { - if (alloc_flags & ALLOC_CMA) + /* + * First try the freelists of the requested migratetype, then try + * fallbacks modes with increasing levels of fragmentation risk. + * + * The fallback logic is expensive and rmqueue_bulk() calls in + * a loop with the zone->lock held, meaning the freelists are + * not subject to any outside changes. Remember in *mode where + * we found pay dirt, to save us the search on the next call. + */ + switch (*mode) { + case RMQUEUE_NORMAL: + page = __rmqueue_smallest(zone, order, migratetype); + if (page) + return page; + fallthrough; + case RMQUEUE_CMA: + if (alloc_flags & ALLOC_CMA) { page = __rmqueue_cma_fallback(zone, order); - - if (!page) - page = __rmqueue_fallback(zone, order, migratetype, - alloc_flags); + if (page) { + *mode = RMQUEUE_CMA; + return page; + } + } + fallthrough; + case RMQUEUE_CLAIM: + page = __rmqueue_claim(zone, order, migratetype, alloc_flags); + if (page) { + /* Replenished preferred freelist, back to normal mode. */ + *mode = RMQUEUE_NORMAL; + return page; + } + fallthrough; + case RMQUEUE_STEAL: + if (!(alloc_flags & ALLOC_NOFRAGMENT)) { + page = __rmqueue_steal(zone, order, migratetype); + if (page) { + *mode = RMQUEUE_STEAL; + return page; + } + } } - return page; + return NULL; } /* @@ -2312,6 +2354,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order, unsigned long count, struct list_head *list, int migratetype, unsigned int alloc_flags) { + enum rmqueue_mode rmqm = RMQUEUE_NORMAL; unsigned long flags; int i; @@ -2323,7 +2366,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order, } for (i = 0; i < count; ++i) { struct page *page = __rmqueue(zone, order, migratetype, - alloc_flags); + alloc_flags, &rmqm); if (unlikely(page == NULL)) break; @@ -2948,7 +2991,9 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone, if (alloc_flags & ALLOC_HIGHATOMIC) page = __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC); if (!page) { - page = __rmqueue(zone, order, migratetype, alloc_flags); + enum rmqueue_mode rmqm = RMQUEUE_NORMAL; + + page = __rmqueue(zone, order, migratetype, alloc_flags, &rmqm); /* * If the allocation fails, allow OOM handling and

2 months

2
2
0 0

[PATCH v2 0/7] accel/ivpu: Add context violation handling for 6.12

by Jacek Lawrynowicz

These patchset adds support for VPU_JSM_STATUS_MVNCI_CONTEXT_VIOLATION_HW message added in recent VPU firmware. Without it the driver will not be able to process any jobs after this message is received and would need to be reloaded. Most patches are as-is from upstream besides these two: - Fix locking order in ivpu_job_submit - Abort all jobs after command queue unregister Both these patches need to be rebased because of missing new CMDQ UAPI changes that should not be backported to stable. Changes since v1: - Documented deviations from the original upstream patches in commit messages Andrew Kreimer (1): accel/ivpu: Fix a typo Andrzej Kacprowski (1): accel/ivpu: Update VPU FW API headers Karol Wachowski (4): accel/ivpu: Use xa_alloc_cyclic() instead of custom function accel/ivpu: Abort all jobs after command queue unregister accel/ivpu: Fix locking order in ivpu_job_submit accel/ivpu: Add handling of VPU_JSM_STATUS_MVNCI_CONTEXT_VIOLATION_HW Tomasz Rusinowicz (1): accel/ivpu: Make DB_ID and JOB_ID allocations incremental drivers/accel/ivpu/ivpu_drv.c | 38 ++-- drivers/accel/ivpu/ivpu_drv.h | 9 + drivers/accel/ivpu/ivpu_job.c | 125 +++++++++--- drivers/accel/ivpu/ivpu_job.h | 1 + drivers/accel/ivpu/ivpu_jsm_msg.c | 3 +- drivers/accel/ivpu/ivpu_mmu.c | 3 +- drivers/accel/ivpu/ivpu_sysfs.c | 5 +- drivers/accel/ivpu/vpu_boot_api.h | 45 +++-- drivers/accel/ivpu/vpu_jsm_api.h | 303 +++++++++++++++++++++++++----- 9 files changed, 412 insertions(+), 120 deletions(-) -- 2.45.1

2 months

2
14
0 0

[PATCH 6.14.y v2 0/7] ublk: fix race between io_uring_cmd_complete_in_task and ublk_cancel_cmd

by Jared Holzman

This patchset backports a series of ublk fixes from upstream to 6.14-stable. Patch 7 fixes the race that can cause kernel panic when ublk server daemon is exiting. It depends on patches 1-6 which simplifies & improves IO canceling when ublk server daemon is exiting as described here: https://lore.kernel.org/linux-block/20250416035444.99569-1-ming.lei@redhat.… Ming Lei (5): ublk: add helper of ublk_need_map_io() ublk: move device reset into ublk_ch_release() ublk: remove __ublk_quiesce_dev() ublk: simplify aborting ublk request ublk: fix race between io_uring_cmd_complete_in_task and ublk_cancel_cmd Uday Shankar (2): ublk: properly serialize all FETCH_REQs ublk: improve detection and handling of ublk server exit drivers/block/ublk_drv.c | 550 +++++++++++++++++++++------------------ 1 file changed, 291 insertions(+), 259 deletions(-) -- 2.43.0

2 months

3
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025