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

6.12.4: System partially freezes with _swap_info_get: Unused swap offset entry

by Kai Krakow

Sorry for posting without subject. Added. Thanks. Am Mi., 18. Dez. 2024 um 01:57 Uhr schrieb Kai Krakow <kai(a)kaishome.de>: > > Hello! > > Running 6.12.4 on Gentoo, using zswap with zsmalloc. > > Since 6.12, I often experience the following error while > installing/compiling packages: > > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:11:58 jupiter kernel: Huh VM_FAULT_OOM leaked out to the #PF > handler. Retrying PF > Dez 16 03:12:03 jupiter kernel: pagefault_out_of_memory: 8645812 > callbacks suppressed > > Programs then slowly start to stop responding and the system won't > shut down cleanly. > > I'm starting to get backtraces after a while: > > Dez 16 03:58:17 jupiter kernel: ------------[ cut here ]------------ > Dez 16 03:58:17 jupiter kernel: WARNING: CPU: 5 PID: 5149 at > mm/swapfile.c:1566 free_swap_and_cache_nr+0xab/0x540 > Dez 16 03:58:17 jupiter kernel: Modules linked in: nfnetlink_queue > nf_conntrack_netlink ip6t_REJECT nf_reject_ipv6 ip6table_nat > ip6table_filter xt_nat ipt_REJECT nf_reject_ipv4 xt_NFQUEUE xt_mark > xt_connmark iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 > nf_defrag_ipv4 iptable_filter ip6table_mangle ip6_tables > iptable_mangle xt_DSCP xt_tcpudp ip_tables x_tables rfcomm > snd_hrtimer> > Dez 16 03:58:17 jupiter kernel: gpu_sched drm_gpuvm drm_exec i915 > drm_buddy drm_display_helper ttm nvidia_uvm(PO) nvidia_modeset(PO) > nvidia(PO) lm92 efivarfs > Dez 16 03:58:17 jupiter kernel: CPU: 5 UID: 1000 PID: 5149 Comm: > QXcbEventQueue Tainted: P O 6.12.4-gentoo-r1 #1 > Dez 16 03:58:17 jupiter kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE > Dez 16 03:58:17 jupiter kernel: Hardware name: ASRock Z690 Pro RS/Z690 > Pro RS, BIOS 18.02 01/04/2024 > Dez 16 03:58:17 jupiter kernel: RIP: 0010:free_swap_and_cache_nr+0xab/0x540 > Dez 16 03:58:17 jupiter kernel: Code: 31 ed 4c 89 7c 24 10 49 89 dc 48 > ba 00 00 00 00 00 00 00 fc 48 89 5c 24 18 45 89 ef 48 21 d1 44 88 4c > 24 26 48 89 0c 24 eb 1c <0f> 0b 41 83 c7 01 49 83 c4 01 45 39 fe 0f 8e > dd 00 00 00 48 8b 45 > Dez 16 03:58:17 jupiter kernel: RSP: 0018:ffffb2bcc984bac8 EFLAGS: 00010246 > Dez 16 03:58:17 jupiter kernel: RAX: 0000000000000000 RBX: > 00000000002c1603 RCX: 0000000000000000 > Dez 16 03:58:17 jupiter kernel: RDX: fc00000000000000 RSI: > 0000000000000001 RDI: ffff8e093c170f00 > Dez 16 03:58:17 jupiter kernel: RBP: ffff8e084a8bec00 R08: > 0000000000000008 R09: 0000000000000000 > Dez 16 03:58:17 jupiter kernel: R10: ffffd68059365ec0 R11: > 0000000000000000 R12: 00000000002c1603 > Dez 16 03:58:17 jupiter kernel: R13: 0000000000000000 R14: > 0000000000000001 R15: 0000000000000000 > Dez 16 03:58:17 jupiter kernel: FS: 0000000000000000(0000) > GS:ffff8e0f6f340000(0000) knlGS:0000000000000000 > Dez 16 03:58:17 jupiter kernel: CS: 0010 DS: 0000 ES: 0000 CR0: > 0000000080050033 > Dez 16 03:58:17 jupiter kernel: CR2: 0000188c00a50000 CR3: > 00000007db42b000 CR4: 0000000000f52ef0 > Dez 16 03:58:17 jupiter kernel: PKRU: 55555554 > Dez 16 03:58:17 jupiter kernel: Call Trace: > Dez 16 03:58:17 jupiter kernel: <TASK> > Dez 16 03:58:17 jupiter kernel: ? __warn.cold+0x90/0x9e > Dez 16 03:58:17 jupiter kernel: ? free_swap_and_cache_nr+0xab/0x540 > Dez 16 03:58:17 jupiter kernel: ? report_bug+0xf6/0x140 > Dez 16 03:58:17 jupiter kernel: ? handle_bug+0x4f/0x90 > Dez 16 03:58:17 jupiter kernel: ? exc_invalid_op+0x17/0x60 > Dez 16 03:58:17 jupiter kernel: ? asm_exc_invalid_op+0x1a/0x20 > Dez 16 03:58:17 jupiter kernel: ? free_swap_and_cache_nr+0xab/0x540 > Dez 16 03:58:17 jupiter kernel: ? free_swap_and_cache_nr+0x2c/0x540 > Dez 16 03:58:17 jupiter kernel: ? swap_pte_batch+0xdc/0x1f0 > Dez 16 03:58:17 jupiter kernel: unmap_page_range+0xa18/0x16b0 > Dez 16 03:58:17 jupiter kernel: unmap_vmas+0xb7/0x170 > Dez 16 03:58:17 jupiter kernel: exit_mmap+0xfb/0x280 > Dez 16 03:58:17 jupiter kernel: __mmput+0x35/0x120 > Dez 16 03:58:17 jupiter kernel: do_exit+0x255/0x930 > Dez 16 03:58:17 jupiter kernel: do_group_exit+0x2b/0x80 > Dez 16 03:58:17 jupiter kernel: get_signal+0x774/0x7b0 > Dez 16 03:58:17 jupiter kernel: arch_do_signal_or_restart+0x29/0x230 > Dez 16 03:58:17 jupiter kernel: syscall_exit_to_user_mode+0x7b/0xf0 > Dez 16 03:58:17 jupiter kernel: do_syscall_64+0x57/0x100 > Dez 16 03:58:17 jupiter kernel: entry_SYSCALL_64_after_hwframe+0x4b/0x53 > Dez 16 03:58:17 jupiter kernel: RIP: 0033:0x564111720e3f > Dez 16 03:58:17 jupiter kernel: Code: Unable to access opcode bytes at > 0x564111720e15. > Dez 16 03:58:17 jupiter kernel: RSP: 002b:000056410b1fda00 EFLAGS: > 00000293 ORIG_RAX: 0000000000000007 > Dez 16 03:58:17 jupiter kernel: RAX: fffffffffffffdfc RBX: > 0000564131839600 RCX: 0000564111720e3f > Dez 16 03:58:17 jupiter kernel: RDX: 00000000ffffffff RSI: > 0000000000000001 RDI: 000056410b1fda48 > Dez 16 03:58:17 jupiter kernel: RBP: 000056410b1fdb20 R08: > 0000000000000000 R09: 0000000000000081 > Dez 16 03:58:17 jupiter kernel: R10: 0000000000000000 R11: > 0000000000000293 R12: 000056410b1fda48 > Dez 16 03:58:17 jupiter kernel: R13: 0000000000000000 R14: > 0000000000000000 R15: 0000564131839618 > Dez 16 03:58:17 jupiter kernel: </TASK> > Dez 16 03:58:17 jupiter kernel: ---[ end trace 0000000000000000 ]--- > Dez 16 03:58:17 jupiter kernel: BUG: Bad rss-counter state > mm:00000000bf899335 type:MM_ANONPAGES val:1 > Dez 16 03:58:17 jupiter kernel: BUG: Bad rss-counter state > mm:00000000bf899335 type:MM_SHMEMPAGES val:-1 > Dez 16 03:58:17 jupiter kernel: BUG: Bad page cache in process > QXcbEventQueue pfn:81fdec > Dez 16 03:58:17 jupiter kernel: page: refcount:3 mapcount:1 > mapping:00000000e6a99870 index:0x10 pfn:0x81fdec > Dez 16 03:58:17 jupiter kernel: memcg:ffff8e09819f9000 > Dez 16 03:58:17 jupiter kernel: aops:0xffffffffbb027a60 ino:20c5 > Dez 16 03:58:17 jupiter kernel: flags: > 0xa00000000002002d(locked|referenced|uptodate|lru|swapbacked|zone=2) > Dez 16 03:58:17 jupiter kernel: raw: a00000000002002d ffffd680607facc8 > ffffd6806075c308 ffff8e0805f5e0b8 > Dez 16 03:58:17 jupiter kernel: raw: 0000000000000010 0000000000000000 > 0000000300000000 ffff8e09819f9000 > Dez 16 03:58:17 jupiter kernel: page dumped because: still mapped when deleted > > When trying to kill processes with sysrq or via kill command, those > processes usually get stuck in state D and I get the following errors > in dmesg: > > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 002c16ee > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 002c16c0 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 002c16c1 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 002c1760 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 40000000004ce36 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 40000000004ce1d > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 40000000004ce52 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 40000000004ced8 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 40000000004ced9 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 40000000004cec4 > Dez 16 20:40:12 jupiter kernel: _swap_info_get: Unused swap offset > entry 40000000004cec3 > > The system can then only be rebooted with alt+sysrq+b. > > Regards, > Kai

1 month, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/i915: Fix memory leak by correcting cache object name in" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x 2828e5808bcd5aae7fdcd169cac1efa2701fa2dd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121517-deserve-wharf-c2d0@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2828e5808bcd5aae7fdcd169cac1efa2701fa2dd Mon Sep 17 00:00:00 2001 From: Jiasheng Jiang <jiashengjiangcool(a)outlook.com> Date: Wed, 27 Nov 2024 20:10:42 +0000 Subject: [PATCH] drm/i915: Fix memory leak by correcting cache object name in error handler Replace "slab_priorities" with "slab_dependencies" in the error handler to avoid memory leak. Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global") Cc: <stable(a)vger.kernel.org> # v5.2+ Signed-off-by: Jiasheng Jiang <jiashengjiangcool(a)outlook.com> Reviewed-by: Nirmoy Das <nirmoy.das(a)intel.com> Reviewed-by: Andi Shyti <andi.shyti(a)linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127201042.29620-1-jiashe… (cherry picked from commit 9bc5e7dc694d3112bbf0fa4c46ef0fa0f114937a) Signed-off-by: Tvrtko Ursulin <tursulin(a)ursulin.net> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c index 762127dd56c5..70a854557e6e 100644 --- a/drivers/gpu/drm/i915/i915_scheduler.c +++ b/drivers/gpu/drm/i915/i915_scheduler.c @@ -506,6 +506,6 @@ int __init i915_scheduler_module_init(void) return 0; err_priorities: - kmem_cache_destroy(slab_priorities); + kmem_cache_destroy(slab_dependencies); return -ENOMEM; }

1 month, 2 weeks

5
6
0 0

+ fs-proc-task_mmu-fix-pagemap-flags-with-pmd-thp-entries-on-32bit.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: fs/proc/task_mmu: fix pagemap flags with PMD THP entries on 32bit has been added to the -mm mm-hotfixes-unstable branch. Its filename is fs-proc-task_mmu-fix-pagemap-flags-with-pmd-thp-entries-on-32bit.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: David Hildenbrand <david(a)redhat.com> Subject: fs/proc/task_mmu: fix pagemap flags with PMD THP entries on 32bit Date: Tue, 17 Dec 2024 20:50:00 +0100 Entries (including flags) are u64, even on 32bit. So right now we are cutting of the flags on 32bit. This way, for example the cow selftest complains about: # ./cow ... Bail Out! read and ioctl return unmatched results for populated: 0 1 Link: https://lkml.kernel.org/r/20241217195000.1734039-1-david@redhat.com Fixes: 2c1f057e5be6 ("fs/proc/task_mmu: properly detect PM_MMAP_EXCLUSIVE per page of PMD-mapped THPs") Signed-off-by: David Hildenbrand <david(a)redhat.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/proc/task_mmu.c~fs-proc-task_mmu-fix-pagemap-flags-with-pmd-thp-entries-on-32bit +++ a/fs/proc/task_mmu.c @@ -1810,7 +1810,7 @@ static int pagemap_pmd_range(pmd_t *pmdp } for (; addr != end; addr += PAGE_SIZE, idx++) { - unsigned long cur_flags = flags; + u64 cur_flags = flags; pagemap_entry_t pme; if (folio && (flags & PM_PRESENT) && _ Patches currently in -mm which might be from david(a)redhat.com are mm-page_alloc-dont-call-pfn_to_page-on-possibly-non-existent-pfn-in-split_large_buddy.patch fs-proc-task_mmu-fix-pagemap-flags-with-pmd-thp-entries-on-32bit.patch docs-tmpfs-update-the-large-folios-policy-for-tmpfs-and-shmem.patch mm-memory_hotplug-move-debug_pagealloc_map_pages-into-online_pages_range.patch mm-page_isolation-dont-pass-gfp-flags-to-isolate_single_pageblock.patch mm-page_isolation-dont-pass-gfp-flags-to-start_isolate_page_range.patch mm-page_alloc-make-__alloc_contig_migrate_range-static.patch mm-page_alloc-sort-out-the-alloc_contig_range-gfp-flags-mess.patch mm-page_alloc-forward-the-gfp-flags-from-alloc_contig_range-to-post_alloc_hook.patch powernv-memtrace-use-__gfp_zero-with-alloc_contig_pages.patch mm-hugetlb-dont-map-folios-writable-without-vm_write-when-copying-during-fork.patch fs-proc-vmcore-convert-vmcore_cb_lock-into-vmcore_mutex.patch fs-proc-vmcore-replace-vmcoredd_mutex-by-vmcore_mutex.patch fs-proc-vmcore-disallow-vmcore-modifications-while-the-vmcore-is-open.patch fs-proc-vmcore-prefix-all-pr_-with-vmcore.patch fs-proc-vmcore-move-vmcore-definitions-out-of-kcoreh.patch fs-proc-vmcore-factor-out-allocating-a-vmcore-range-and-adding-it-to-a-list.patch fs-proc-vmcore-factor-out-freeing-a-list-of-vmcore-ranges.patch fs-proc-vmcore-introduce-proc_vmcore_device_ram-to-detect-device-ram-ranges-in-2nd-kernel.patch virtio-mem-mark-device-ready-before-registering-callbacks-in-kdump-mode.patch virtio-mem-remember-usable-region-size.patch virtio-mem-support-config_proc_vmcore_device_ram.patch s390-kdump-virtio-mem-kdump-support-config_proc_vmcore_device_ram.patch mm-page_alloc-dont-use-__gfp_hardwall-when-migrating-pages-via-alloc_contig.patch mm-memory_hotplug-dont-use-__gfp_hardwall-when-migrating-pages-via-memory-offlining.patch

1 month, 2 weeks

1
0
0 0

[PATCH 1/5] clk: mediatek: mt2701-vdec: fix conversion to mtk_clk_simple_probe

by Daniel Golle

Commit 973d1607d936 ("clk: mediatek: mt2701: use mtk_clk_simple_probe to simplify driver") broke DT bindings as the highest index was reduced by 1 because the id count starts from 1 and not from 0. Fix this, like for other drivers which had the same issue, by adding a dummy clk at index 0. Fixes: 973d1607d936 ("clk: mediatek: mt2701: use mtk_clk_simple_probe to simplify driver") Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Golle <daniel(a)makrotopia.org> --- drivers/clk/mediatek/clk-mt2701-vdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/mediatek/clk-mt2701-vdec.c b/drivers/clk/mediatek/clk-mt2701-vdec.c index 94db86f8d0a4..5299d92f3aba 100644 --- a/drivers/clk/mediatek/clk-mt2701-vdec.c +++ b/drivers/clk/mediatek/clk-mt2701-vdec.c @@ -31,6 +31,7 @@ static const struct mtk_gate_regs vdec1_cg_regs = { GATE_MTK(_id, _name, _parent, &vdec1_cg_regs, _shift, &mtk_clk_gate_ops_setclr_inv) static const struct mtk_gate vdec_clks[] = { + GATE_DUMMY(CLK_DUMMY, "vdec_dummy"), GATE_VDEC0(CLK_VDEC_CKGEN, "vdec_cken", "vdec_sel", 0), GATE_VDEC1(CLK_VDEC_LARB, "vdec_larb_cken", "mm_sel", 0), }; -- 2.47.1

1 month, 2 weeks

3
14
0 0

[PATCH v1] fs/proc/task_mmu: fix pagemap flags with PMD THP entries on 32bit

by David Hildenbrand

Entries (including flags) are u64, even on 32bit. So right now we are cutting of the flags on 32bit. This way, for example the cow selftest complains about: # ./cow ... Bail Out! read and ioctl return unmatched results for populated: 0 1 Fixes: 2c1f057e5be6 ("fs/proc/task_mmu: properly detect PM_MMAP_EXCLUSIVE per page of PMD-mapped THPs") Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- fs/proc/task_mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 38a5a3e9cba20..f02cd362309a0 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -1810,7 +1810,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long addr, unsigned long end, } for (; addr != end; addr += PAGE_SIZE, idx++) { - unsigned long cur_flags = flags; + u64 cur_flags = flags; pagemap_entry_t pme; if (folio && (flags & PM_PRESENT) && -- 2.47.1

1 month, 2 weeks

1
0
0 0

[PATCH AUTOSEL 5.15 01/13] PCI: Add ACS quirk for Broadcom BCM5760X NIC

by Sasha Levin

From: Ajit Khaparde <ajit.khaparde(a)broadcom.com> [ Upstream commit 524e057b2d66b61f9b63b6db30467ab7b0bb4796 ] The Broadcom BCM5760X NIC may be a multi-function device. While it does not advertise an ACS capability, peer-to-peer transactions are not possible between the individual functions. So it is ok to treat them as fully isolated. Add an ACS quirk for this device so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240510204228.73435-1-ajit.khaparde@broa… Signed-off-by: Ajit Khaparde <ajit.khaparde(a)broadcom.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Reviewed-by: Andy Gospodarek <gospo(a)broadcom.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/pci/quirks.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 4d4267105cd2b..842e8fecf0a9a 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4971,6 +4971,10 @@ static const struct pci_dev_acs_enabled { { PCI_VENDOR_ID_BROADCOM, 0x1750, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_BROADCOM, 0x1751, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_BROADCOM, 0x1752, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1760, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1761, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1762, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1763, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_BROADCOM, 0xD714, pci_quirk_brcm_acs }, /* Amazon Annapurna Labs */ { PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031, pci_quirk_al_acs }, -- 2.43.0

1 month, 2 weeks

2
14
0 0

+ maple_tree-reload-mas-before-the-second-call-for-mas_empty_area-fix.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: maple_tree: fix mas_alloc_cyclic() second search has been added to the -mm mm-hotfixes-unstable branch. Its filename is maple_tree-reload-mas-before-the-second-call-for-mas_empty_area-fix.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: "Liam R. Howlett" <Liam.Howlett(a)Oracle.com> Subject: maple_tree: fix mas_alloc_cyclic() second search Date: Mon, 16 Dec 2024 14:01:12 -0500 The first search may leave the maple state in an error state. Reset the maple state before the second search so that the search has a chance of executing correctly after an exhausted first search. Link: https://lore.kernel.org/all/20241216060600.287B4C4CED0@smtp.kernel.org/ Link: https://lkml.kernel.org/r/20241216190113.1226145-2-Liam.Howlett@oracle.com Fixes: 9b6713cc7522 ("maple_tree: Add mtree_alloc_cyclic()") Signed-off-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Chuck Lever <chuck.lever(a)oracle.com> says: Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/lib/maple_tree.c~maple_tree-reload-mas-before-the-second-call-for-mas_empty_area-fix +++ a/lib/maple_tree.c @@ -4346,7 +4346,6 @@ int mas_alloc_cyclic(struct ma_state *ma { unsigned long min = range_lo; int ret = 0; - struct ma_state m = *mas; range_lo = max(min, *next); ret = mas_empty_area(mas, range_lo, range_hi, 1); @@ -4355,7 +4354,7 @@ int mas_alloc_cyclic(struct ma_state *ma ret = 1; } if (ret < 0 && range_lo > min) { - *mas = m; + mas_reset(mas); ret = mas_empty_area(mas, min, range_hi, 1); if (ret == 0) ret = 1; _ Patches currently in -mm which might be from Liam.Howlett(a)Oracle.com are maple_tree-reload-mas-before-the-second-call-for-mas_empty_area-fix.patch test_maple_tree-test-exhausted-upper-limit-of-mtree_alloc_cyclic.patch

1 month, 2 weeks

1
0
0 0

+ maple_tree-fix-mas_alloc_cyclic-second-search.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: maple_tree: fix mas_alloc_cyclic() second search has been added to the -mm mm-hotfixes-unstable branch. Its filename is maple_tree-fix-mas_alloc_cyclic-second-search.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: "Liam R. Howlett" <Liam.Howlett(a)Oracle.com> Subject: maple_tree: fix mas_alloc_cyclic() second search Date: Mon, 16 Dec 2024 14:01:12 -0500 The first search may leave the maple state in an error state. Reset the maple state before the second search so that the search has a chance of executing correctly after an exhausted first search. Link: https://lore.kernel.org/all/20241216060600.287B4C4CED0@smtp.kernel.org/ Link: https://lkml.kernel.org/r/20241216190113.1226145-2-Liam.Howlett@oracle.com Fixes: 9b6713cc7522 ("maple_tree: Add mtree_alloc_cyclic()") Signed-off-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Chuck Lever <chuck.lever(a)oracle.com> says: Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/lib/maple_tree.c~maple_tree-fix-mas_alloc_cyclic-second-search +++ a/lib/maple_tree.c @@ -4346,7 +4346,6 @@ int mas_alloc_cyclic(struct ma_state *ma { unsigned long min = range_lo; int ret = 0; - struct ma_state m = *mas; range_lo = max(min, *next); ret = mas_empty_area(mas, range_lo, range_hi, 1); @@ -4355,7 +4354,7 @@ int mas_alloc_cyclic(struct ma_state *ma ret = 1; } if (ret < 0 && range_lo > min) { - *mas = m; + mas_reset(mas); ret = mas_empty_area(mas, min, range_hi, 1); if (ret == 0) ret = 1; _ Patches currently in -mm which might be from Liam.Howlett(a)Oracle.com are maple_tree-fix-mas_alloc_cyclic-second-search.patch test_maple_tree-test-exhausted-upper-limit-of-mtree_alloc_cyclic.patch

1 month, 2 weeks

1
0
0 0

[to-be-updated] mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm, compaction: don't use ALLOC_CMA in long term GUP flow has been removed from the -mm tree. Its filename was mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: yangge <yangge1116(a)126.com> Subject: mm, compaction: don't use ALLOC_CMA in long term GUP flow Date: Mon, 16 Dec 2024 19:54:04 +0800 Since commit 984fdba6a32e ("mm, compaction: use proper alloc_flags in __compaction_suitable()") allow compaction to proceed when free pages required for compaction reside in the CMA pageblocks, it's possible that __compaction_suitable() always returns true, and in some cases, it's not acceptable. There are 4 NUMA nodes on my machine, and each NUMA node has 32GB of memory. I have configured 16GB of CMA memory on each NUMA node, and starting a 32GB virtual machine with device passthrough is extremely slow, taking almost an hour. During the start-up of the virtual machine, it will call pin_user_pages_remote(..., FOLL_LONGTERM, ...) to allocate memory. Long term GUP cannot allocate memory from CMA area, so a maximum of 16 GB of no-CMA memory on a NUMA node can be used as virtual machine memory. Since there is 16G of free CMA memory on the NUMA node, watermark for order-0 always be met for compaction, so __compaction_suitable() always returns true, even if the node is unable to allocate non-CMA memory for the virtual machine. For costly allocations, because __compaction_suitable() always returns true, __alloc_pages_slowpath() can't exit at the appropriate place, resulting in excessively long virtual machine startup times. Call trace: __alloc_pages_slowpath if (compact_result == COMPACT_SKIPPED || compact_result == COMPACT_DEFERRED) goto nopage; // should exit __alloc_pages_slowpath() from here In order to quickly fall back to remote node, we should remove ALLOC_CMA both in __compaction_suitable() and __isolate_free_page() in long term GUP flow. After this fix, starting a 32GB virtual machine with device passthrough takes only a few seconds. Link: https://lkml.kernel.org/r/1734350044-12928-1-git-send-email-yangge1116@126.… Fixes: 984fdba6a32e ("mm, compaction: use proper alloc_flags in __compaction_suitable()") Signed-off-by: yangge <yangge1116(a)126.com> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/compaction.h | 6 ++++-- mm/compaction.c | 20 +++++++++++--------- mm/internal.h | 3 ++- mm/page_alloc.c | 6 ++++-- mm/page_isolation.c | 3 ++- mm/page_reporting.c | 2 +- mm/vmscan.c | 4 ++-- 7 files changed, 26 insertions(+), 18 deletions(-) --- a/include/linux/compaction.h~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/include/linux/compaction.h @@ -90,7 +90,8 @@ extern enum compact_result try_to_compac struct page **page); extern void reset_isolation_suitable(pg_data_t *pgdat); extern bool compaction_suitable(struct zone *zone, int order, - int highest_zoneidx); + int highest_zoneidx, + unsigned int alloc_flags); extern void compaction_defer_reset(struct zone *zone, int order, bool alloc_success); @@ -108,7 +109,8 @@ static inline void reset_isolation_suita } static inline bool compaction_suitable(struct zone *zone, int order, - int highest_zoneidx) + int highest_zoneidx, + unsigned int alloc_flags) { return false; } --- a/mm/compaction.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/compaction.c @@ -654,7 +654,7 @@ static unsigned long isolate_freepages_b /* Found a free page, will break it into order-0 pages */ order = buddy_order(page); - isolated = __isolate_free_page(page, order); + isolated = __isolate_free_page(page, order, cc->alloc_flags); if (!isolated) break; set_page_private(page, order); @@ -1633,7 +1633,7 @@ static void fast_isolate_freepages(struc /* Isolate the page if available */ if (page) { - if (__isolate_free_page(page, order)) { + if (__isolate_free_page(page, order, cc->alloc_flags)) { set_page_private(page, order); nr_isolated = 1 << order; nr_scanned += nr_isolated - 1; @@ -2379,6 +2379,7 @@ static enum compact_result compact_finis static bool __compaction_suitable(struct zone *zone, int order, int highest_zoneidx, + unsigned int alloc_flags, unsigned long wmark_target) { unsigned long watermark; @@ -2393,25 +2394,26 @@ static bool __compaction_suitable(struct * even if compaction succeeds. * For costly orders, we require low watermark instead of min for * compaction to proceed to increase its chances. - * ALLOC_CMA is used, as pages in CMA pageblocks are considered - * suitable migration targets + * In addition to long term GUP flow, ALLOC_CMA is used, as pages in + * CMA pageblocks are considered suitable migration targets */ watermark = (order > PAGE_ALLOC_COSTLY_ORDER) ? low_wmark_pages(zone) : min_wmark_pages(zone); watermark += compact_gap(order); return __zone_watermark_ok(zone, 0, watermark, highest_zoneidx, - ALLOC_CMA, wmark_target); + alloc_flags & ALLOC_CMA, wmark_target); } /* * compaction_suitable: Is this suitable to run compaction on this zone now? */ -bool compaction_suitable(struct zone *zone, int order, int highest_zoneidx) +bool compaction_suitable(struct zone *zone, int order, int highest_zoneidx, + unsigned int alloc_flags) { enum compact_result compact_result; bool suitable; - suitable = __compaction_suitable(zone, order, highest_zoneidx, + suitable = __compaction_suitable(zone, order, highest_zoneidx, alloc_flags, zone_page_state(zone, NR_FREE_PAGES)); /* * fragmentation index determines if allocation failures are due to @@ -2472,7 +2474,7 @@ bool compaction_zonelist_suitable(struct available = zone_reclaimable_pages(zone) / order; available += zone_page_state_snapshot(zone, NR_FREE_PAGES); if (__compaction_suitable(zone, order, ac->highest_zoneidx, - available)) + alloc_flags, available)) return true; } @@ -2497,7 +2499,7 @@ compaction_suit_allocation_order(struct alloc_flags)) return COMPACT_SUCCESS; - if (!compaction_suitable(zone, order, highest_zoneidx)) + if (!compaction_suitable(zone, order, highest_zoneidx, alloc_flags)) return COMPACT_SKIPPED; return COMPACT_CONTINUE; --- a/mm/internal.h~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/internal.h @@ -662,7 +662,8 @@ static inline void clear_zone_contiguous zone->contiguous = false; } -extern int __isolate_free_page(struct page *page, unsigned int order); +extern int __isolate_free_page(struct page *page, unsigned int order, + unsigned int alloc_flags); extern void __putback_isolated_page(struct page *page, unsigned int order, int mt); extern void memblock_free_pages(struct page *page, unsigned long pfn, --- a/mm/page_alloc.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/page_alloc.c @@ -2808,7 +2808,8 @@ void split_page(struct page *page, unsig } EXPORT_SYMBOL_GPL(split_page); -int __isolate_free_page(struct page *page, unsigned int order) +int __isolate_free_page(struct page *page, unsigned int order, + unsigned int alloc_flags) { struct zone *zone = page_zone(page); int mt = get_pageblock_migratetype(page); @@ -2822,7 +2823,8 @@ int __isolate_free_page(struct page *pag * exists. */ watermark = zone->_watermark[WMARK_MIN] + (1UL << order); - if (!zone_watermark_ok(zone, 0, watermark, 0, ALLOC_CMA)) + if (!zone_watermark_ok(zone, 0, watermark, 0, + alloc_flags & ALLOC_CMA)) return 0; } --- a/mm/page_isolation.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/page_isolation.c @@ -229,7 +229,8 @@ static void unset_migratetype_isolate(st buddy = find_buddy_page_pfn(page, page_to_pfn(page), order, NULL); if (buddy && !is_migrate_isolate_page(buddy)) { - isolated_page = !!__isolate_free_page(page, order); + isolated_page = !!__isolate_free_page(page, order, + ALLOC_CMA); /* * Isolating a free page in an isolated pageblock * is expected to always work as watermarks don't --- a/mm/page_reporting.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/page_reporting.c @@ -198,7 +198,7 @@ page_reporting_cycle(struct page_reporti /* Attempt to pull page from list and place in scatterlist */ if (*offset) { - if (!__isolate_free_page(page, order)) { + if (!__isolate_free_page(page, order, ALLOC_CMA)) { next = page; break; } --- a/mm/vmscan.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/vmscan.c @@ -5861,7 +5861,7 @@ static inline bool should_continue_recla sc->reclaim_idx, 0)) return false; - if (compaction_suitable(zone, sc->order, sc->reclaim_idx)) + if (compaction_suitable(zone, sc->order, sc->reclaim_idx, ALLOC_CMA)) return false; } @@ -6089,7 +6089,7 @@ static inline bool compaction_ready(stru return true; /* Compaction cannot yet proceed. Do reclaim. */ - if (!compaction_suitable(zone, sc->order, sc->reclaim_idx)) + if (!compaction_suitable(zone, sc->order, sc->reclaim_idx, ALLOC_CMA)) return false; /* _ Patches currently in -mm which might be from yangge1116(a)126.com are

1 month, 2 weeks

1
0
0 0

Re: [PATCH 6.12 000/172] 6.12.6-rc1 review

by Ronald Warsow

Hi Greg *no* regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

1 month, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror