January 2022 - Linux-stable-mirror

[PATCH] drm/vmwgfx: Stop requesting the pci regions

by Zack Rusin

From: Zack Rusin <zackr(a)vmware.com> When sysfb_simple is enabled loading vmwgfx fails because the regions are held by the platform. In that case remove_conflicting*_framebuffers only removes the simplefb but not the regions held by sysfb. Like the other drm drivers we need to stop requesting all the pci regions to let the driver load with platform code enabled. This allows vmwgfx to load correctly on systems with sysfb_simple enabled. Signed-off-by: Zack Rusin <zackr(a)vmware.com> Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64") Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> Reviewed-by: Martin Krastev <krastevm(a)vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index fe36efdb7ff5..27feb19f3324 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -724,10 +724,6 @@ static int vmw_setup_pci_resources(struct vmw_private *dev, pci_set_master(pdev); - ret = pci_request_regions(pdev, "vmwgfx probe"); - if (ret) - return ret; - dev->pci_id = pci_id; if (pci_id == VMWGFX_PCI_ID_SVGA3) { rmmio_start = pci_resource_start(pdev, 0); -- 2.32.0

2 years, 11 months

4
17
0 0

[PATCH v7 04/14] mm, hugetlbfs: Allow for "high" userspace addresses

by Christophe Leroy

This is a complement of f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses") for hugetlb. This patch adds support for "high" userspace addresses that are optionally supported on the system and have to be requested via a hint mechanism ("high" addr parameter to mmap). Architectures such as powerpc and x86 achieve this by making changes to their architectural versions of hugetlb_get_unmapped_area() function. However, arm64 uses the generic version of that function. So take into account arch_get_mmap_base() and arch_get_mmap_end() in hugetlb_get_unmapped_area(). To allow that, move those two macros out of mm/mmap.c into include/linux/sched/mm.h If these macros are not defined in architectural code then they default to (TASK_SIZE) and (base) so should not introduce any behavioural changes to architectures that do not define them. For the time being, only ARM64 is affected by this change. Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Steve Capper <steve.capper(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Fixes: f6795053dac8 ("mm: mmap: Allow for "high" userspace addresses") Cc: <stable(a)vger.kernel.org> # 5.0.x Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com> --- fs/hugetlbfs/inode.c | 9 +++++---- include/linux/sched/mm.h | 8 ++++++++ mm/mmap.c | 8 -------- 3 files changed, 13 insertions(+), 12 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index c7cde4e5924d..a8d3b0899b60 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -205,7 +205,7 @@ hugetlb_get_unmapped_area_bottomup(struct file *file, unsigned long addr, info.flags = 0; info.length = len; info.low_limit = current->mm->mmap_base; - info.high_limit = TASK_SIZE; + info.high_limit = arch_get_mmap_end(addr, len, flags); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; return vm_unmapped_area(&info); @@ -221,7 +221,7 @@ hugetlb_get_unmapped_area_topdown(struct file *file, unsigned long addr, info.flags = VM_UNMAPPED_AREA_TOPDOWN; info.length = len; info.low_limit = max(PAGE_SIZE, mmap_min_addr); - info.high_limit = current->mm->mmap_base; + info.high_limit = arch_get_mmap_base(addr, current->mm->mmap_base); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; addr = vm_unmapped_area(&info); @@ -236,7 +236,7 @@ hugetlb_get_unmapped_area_topdown(struct file *file, unsigned long addr, VM_BUG_ON(addr != -ENOMEM); info.flags = 0; info.low_limit = current->mm->mmap_base; - info.high_limit = TASK_SIZE; + info.high_limit = arch_get_mmap_end(addr, len, flags); addr = vm_unmapped_area(&info); } @@ -251,6 +251,7 @@ generic_hugetlb_get_unmapped_area(struct file *file, unsigned long addr, struct mm_struct *mm = current->mm; struct vm_area_struct *vma; struct hstate *h = hstate_file(file); + const unsigned long mmap_end = arch_get_mmap_end(addr, len, flags); if (len & ~huge_page_mask(h)) return -EINVAL; @@ -266,7 +267,7 @@ generic_hugetlb_get_unmapped_area(struct file *file, unsigned long addr, if (addr) { addr = ALIGN(addr, huge_page_size(h)); vma = find_vma(mm, addr); - if (TASK_SIZE - len >= addr && + if (mmap_end - len >= addr && (!vma || addr + len <= vm_start_gap(vma))) return addr; } diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h index 2584f7c13f69..cc9d80bd36d5 100644 --- a/include/linux/sched/mm.h +++ b/include/linux/sched/mm.h @@ -135,6 +135,14 @@ static inline void mm_update_next_owner(struct mm_struct *mm) #endif /* CONFIG_MEMCG */ #ifdef CONFIG_MMU +#ifndef arch_get_mmap_end +#define arch_get_mmap_end(addr, len, flags) (TASK_SIZE) +#endif + +#ifndef arch_get_mmap_base +#define arch_get_mmap_base(addr, base) (base) +#endif + extern void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack); extern unsigned long diff --git a/mm/mmap.c b/mm/mmap.c index ad48f7af7511..c773b5ad9a11 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2112,14 +2112,6 @@ unsigned long vm_unmapped_area(struct vm_unmapped_area_info *info) return addr; } -#ifndef arch_get_mmap_end -#define arch_get_mmap_end(addr, len, flags) (TASK_SIZE) -#endif - -#ifndef arch_get_mmap_base -#define arch_get_mmap_base(addr, base) (base) -#endif - /* Get an address range which is currently unmapped. * For shmat() with addr=0. * -- 2.33.1

2 years, 11 months

1
0
0 0

Happy new year

by Mrs.aisha Gaddafi

-- Happy new year I am sending my greetings to you from the Sultanate of Oman, in the capital city of Muscat. Note, I come across your e-mail contact prior a private search while in need of your assistances. May i use this medium to open a mutual communication with you, and seeking your acceptance towards investing in your country under your management as my partner, My name is Aisha Gaddafi and presently living in Oman, i am a Widow and single Mother with three Children, the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi) and presently i am under political asylum protection by the Omani Government. I have funds worth “Twenty Seven Million Five Hundred Thousand United State Dollars” -$27.500.000.00 US Dollars which i want to entrust on you for investment project in your country. If you are willing to handle this project on my behalf, kindly reply urgent to enable me provide you more details to start the transfer process . Please after read this mail try to contact me through this my private email address :{ madamgadafiaisha(a)gmail.com} Thanks Yours Truly Aisha

2 years, 11 months

1
0
0 0

stable-rc/queue/5.15 baseline: 151 runs, 1 regressions (v5.15.15-28-g1f75a74f84d6)

by kernelci.org bot

stable-rc/queue/5.15 baseline: 151 runs, 1 regressions (v5.15.15-28-g1f75a74f84d6) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ meson-gxbb-p200 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.15/kernel/v5.15.15… Test: baseline Tree: stable-rc Branch: queue/5.15 Describe: v5.15.15-28-g1f75a74f84d6 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 1f75a74f84d6221d204ad411e33ebe52161ed9ca Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ meson-gxbb-p200 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/61e9af614b37df8eb8abbd4d Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-5.15/v5.15.15-28-g1f75a74f84d… HTML log: https://storage.kernelci.org//stable-rc/queue-5.15/v5.15.15-28-g1f75a74f84d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/61e9af614b37df8eb8abbd4e new failure (last pass: v5.15.14-69-gc1152c1284d7)

2 years, 11 months

1
0
0 0

[merged] mm-page_allocc-do-not-warn-allocation-failure-on-zone-dma-if-no-managed-pages.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/page_alloc.c: do not warn allocation failure on zone DMA if no managed pages has been removed from the -mm tree. Its filename was mm-page_allocc-do-not-warn-allocation-failure-on-zone-dma-if-no-managed-pages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Baoquan He <bhe(a)redhat.com> Subject: mm/page_alloc.c: do not warn allocation failure on zone DMA if no managed pages In kdump kernel of x86_64, page allocation failure is observed: kworker/u2:2: page allocation failure: order:0, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 55 Comm: kworker/u2:2 Not tainted 5.16.0-rc4+ #5 Hardware name: AMD Dinar/Dinar, BIOS RDN1505B 06/05/2013 Workqueue: events_unbound async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x48/0x5e warn_alloc.cold+0x72/0xd6 __alloc_pages_slowpath.constprop.0+0xc69/0xcd0 __alloc_pages+0x1df/0x210 new_slab+0x389/0x4d0 ___slab_alloc+0x58f/0x770 __slab_alloc.constprop.0+0x4a/0x80 kmem_cache_alloc_trace+0x24b/0x2c0 sr_probe+0x1db/0x620 ...... device_add+0x405/0x920 ...... __scsi_add_device+0xe5/0x100 ata_scsi_scan_host+0x97/0x1d0 async_run_entry_fn+0x30/0x130 process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x350/0x350 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Mem-Info: ...... The above failure happened when calling kmalloc() to allocate buffer with GFP_DMA. It requests to allocate slab page from DMA zone while no managed pages at all in there. sr_probe() --> get_capabilities() --> buffer = kmalloc(512, GFP_KERNEL | GFP_DMA); Because in the current kernel, dma-kmalloc will be created as long as CONFIG_ZONE_DMA is enabled. However, kdump kernel of x86_64 doesn't have managed pages on DMA zone since commit 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified"). The failure can be always reproduced. For now, let's mute the warning of allocation failure if requesting pages from DMA zone while no managed pages. [akpm(a)linux-foundation.org: fix warning] Link: https://lkml.kernel.org/r/20211223094435.248523-4-bhe@redhat.com Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") Signed-off-by: Baoquan He <bhe(a)redhat.com> Acked-by: John Donnelly <john.p.donnelly(a)oracle.com> Reviewed-by: Hyeonggon Yoo <42.hyeyoo(a)gmail.com> Cc: Christoph Lameter <cl(a)linux.com> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Christoph Hellwig <hch(a)lst.de> Cc: David Hildenbrand <david(a)redhat.com> Cc: David Laight <David.Laight(a)ACULAB.COM> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/mm/page_alloc.c~mm-page_allocc-do-not-warn-allocation-failure-on-zone-dma-if-no-managed-pages +++ a/mm/page_alloc.c @@ -4218,7 +4218,9 @@ void warn_alloc(gfp_t gfp_mask, nodemask va_list args; static DEFINE_RATELIMIT_STATE(nopage_rs, 10*HZ, 1); - if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(&nopage_rs)) + if ((gfp_mask & __GFP_NOWARN) || + !__ratelimit(&nopage_rs) || + ((gfp_mask & __GFP_DMA) && !has_managed_dma())) return; va_start(args, fmt); _ Patches currently in -mm which might be from bhe(a)redhat.com are

2 years, 11 months

1
0
0 0

[merged] dma-pool-create-dma-atomic-pool-only-if-dma-zone-has-managed-pages.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: dma/pool: create dma atomic pool only if dma zone has managed pages has been removed from the -mm tree. Its filename was dma-pool-create-dma-atomic-pool-only-if-dma-zone-has-managed-pages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Baoquan He <bhe(a)redhat.com> Subject: dma/pool: create dma atomic pool only if dma zone has managed pages Currently three dma atomic pools are initialized as long as the relevant kernel codes are built in. While in kdump kernel of x86_64, this is not right when trying to create atomic_pool_dma, because there's no managed pages in DMA zone. In the case, DMA zone only has low 1M memory presented and locked down by memblock allocator. So no pages are added into buddy of DMA zone. Please check commit f1d4d47c5851 ("x86/setup: Always reserve the first 1M of RAM"). Then in kdump kernel of x86_64, it always prints below failure message: DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations swapper/0: page allocation failure: order:5, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-0.rc5.20210611git929d931f2b40.42.fc35.x86_64 #1 Hardware name: Dell Inc. PowerEdge R910/0P658H, BIOS 2.12.0 06/04/2018 Call Trace: dump_stack+0x7f/0xa1 warn_alloc.cold+0x72/0xd6 ? _raw_spin_unlock_irq+0x24/0x40 ? __alloc_pages_direct_compact+0x90/0x1b0 __alloc_pages_slowpath.constprop.0+0xf29/0xf50 ? __cond_resched+0x16/0x50 ? prepare_alloc_pages.constprop.0+0x19d/0x1b0 __alloc_pages+0x24d/0x2c0 ? __dma_atomic_pool_init+0x93/0x93 alloc_page_interleave+0x13/0xb0 atomic_pool_expand+0x118/0x210 ? __dma_atomic_pool_init+0x93/0x93 __dma_atomic_pool_init+0x45/0x93 dma_atomic_pool_init+0xdb/0x176 do_one_initcall+0x67/0x320 ? rcu_read_lock_sched_held+0x3f/0x80 kernel_init_freeable+0x290/0x2dc ? rest_init+0x24f/0x24f kernel_init+0xa/0x111 ret_from_fork+0x22/0x30 Mem-Info: ...... DMA: failed to allocate 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocation DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations Here, let's check if DMA zone has managed pages, then create atomic_pool_dma if yes. Otherwise just skip it. Link: https://lkml.kernel.org/r/20211223094435.248523-3-bhe@redhat.com Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") Signed-off-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Acked-by: John Donnelly <john.p.donnelly(a)oracle.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Christoph Lameter <cl(a)linux.com> Cc: David Laight <David.Laight(a)ACULAB.COM> Cc: David Rientjes <rientjes(a)google.com> Cc: Hyeonggon Yoo <42.hyeyoo(a)gmail.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/dma/pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/kernel/dma/pool.c~dma-pool-create-dma-atomic-pool-only-if-dma-zone-has-managed-pages +++ a/kernel/dma/pool.c @@ -203,7 +203,7 @@ static int __init dma_atomic_pool_init(v GFP_KERNEL); if (!atomic_pool_kernel) ret = -ENOMEM; - if (IS_ENABLED(CONFIG_ZONE_DMA)) { + if (has_managed_dma()) { atomic_pool_dma = __dma_atomic_pool_init(atomic_pool_size, GFP_KERNEL | GFP_DMA); if (!atomic_pool_dma) @@ -226,7 +226,7 @@ static inline struct gen_pool *dma_guess if (prev == NULL) { if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32)) return atomic_pool_dma32; - if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA)) + if (atomic_pool_dma && (gfp & GFP_DMA)) return atomic_pool_dma; return atomic_pool_kernel; } _ Patches currently in -mm which might be from bhe(a)redhat.com are

2 years, 11 months

1
0
0 0

[merged] mm_zone-add-function-to-check-if-managed-dma-zone-exists.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm_zone: add function to check if managed dma zone exists has been removed from the -mm tree. Its filename was mm_zone-add-function-to-check-if-managed-dma-zone-exists.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Baoquan He <bhe(a)redhat.com> Subject: mm_zone: add function to check if managed dma zone exists Patch series "Handle warning of allocation failure on DMA zone w/o managed pages", v4. **Problem observed: On x86_64, when crash is triggered and entering into kdump kernel, page allocation failure can always be seen. --------------------------------- DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations swapper/0: page allocation failure: order:5, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 1 Comm: swapper/0 Call Trace: dump_stack+0x7f/0xa1 warn_alloc.cold+0x72/0xd6 ...... __alloc_pages+0x24d/0x2c0 ...... dma_atomic_pool_init+0xdb/0x176 do_one_initcall+0x67/0x320 ? rcu_read_lock_sched_held+0x3f/0x80 kernel_init_freeable+0x290/0x2dc ? rest_init+0x24f/0x24f kernel_init+0xa/0x111 ret_from_fork+0x22/0x30 Mem-Info: ------------------------------------ ***Root cause: In the current kernel, it assumes that DMA zone must have managed pages and try to request pages if CONFIG_ZONE_DMA is enabled. While this is not always true. E.g in kdump kernel of x86_64, only low 1M is presented and locked down at very early stage of boot, so that this low 1M won't be added into buddy allocator to become managed pages of DMA zone. This exception will always cause page allocation failure if page is requested from DMA zone. ***Investigation: This failure happens since below commit merged into linus's tree. 1a6a9044b967 x86/setup: Remove CONFIG_X86_RESERVE_LOW and reservelow= options 23721c8e92f7 x86/crash: Remove crash_reserve_low_1M() f1d4d47c5851 x86/setup: Always reserve the first 1M of RAM 7c321eb2b843 x86/kdump: Remove the backup region handling 6f599d84231f x86/kdump: Always reserve the low 1M when the crashkernel option is specified Before them, on x86_64, the low 640K area will be reused by kdump kernel. So in kdump kernel, the content of low 640K area is copied into a backup region for dumping before jumping into kdump. Then except of those firmware reserved region in [0, 640K], the left area will be added into buddy allocator to become available managed pages of DMA zone. However, after above commits applied, in kdump kernel of x86_64, the low 1M is reserved by memblock, but not released to buddy allocator. So any later page allocation requested from DMA zone will fail. At the beginning, if crashkernel is reserved, the low 1M need be locked down because AMD SME encrypts memory making the old backup region mechanims impossible when switching into kdump kernel. Later, it was also observed that there are BIOSes corrupting memory under 1M. To solve this, in commit f1d4d47c5851, the entire region of low 1M is always reserved after the real mode trampoline is allocated. Besides, recently, Intel engineer mentioned their TDX (Trusted domain extensions) which is under development in kernel also needs to lock down the low 1M. So we can't simply revert above commits to fix the page allocation failure from DMA zone as someone suggested. ***Solution: Currently, only DMA atomic pool and dma-kmalloc will initialize and request page allocation with GFP_DMA during bootup. So only initializ DMA atomic pool when DMA zone has available managed pages, otherwise just skip the initialization. For dma-kmalloc(), for the time being, let's mute the warning of allocation failure if requesting pages from DMA zone while no manged pages. Meanwhile, change code to use dma_alloc_xx/dma_map_xx API to replace kmalloc(GFP_DMA), or do not use GFP_DMA when calling kmalloc() if not necessary. Christoph is posting patches to fix those under drivers/scsi/. Finally, we can remove the need of dma-kmalloc() as people suggested. This patch (of 3): In some places of the current kernel, it assumes that dma zone must have managed pages if CONFIG_ZONE_DMA is enabled. While this is not always true. E.g in kdump kernel of x86_64, only low 1M is presented and locked down at very early stage of boot, so that there's no managed pages at all in DMA zone. This exception will always cause page allocation failure if page is requested from DMA zone. Here add function has_managed_dma() and the relevant helper functions to check if there's DMA zone with managed pages. It will be used in later patches. Link: https://lkml.kernel.org/r/20211223094435.248523-1-bhe@redhat.com Link: https://lkml.kernel.org/r/20211223094435.248523-2-bhe@redhat.com Fixes: 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified") Signed-off-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Acked-by: John Donnelly <john.p.donnelly(a)oracle.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Christoph Lameter <cl(a)linux.com> Cc: Hyeonggon Yoo <42.hyeyoo(a)gmail.com> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: David Laight <David.Laight(a)ACULAB.COM> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mmzone.h | 9 +++++++++ mm/page_alloc.c | 15 +++++++++++++++ 2 files changed, 24 insertions(+) --- a/include/linux/mmzone.h~mm_zone-add-function-to-check-if-managed-dma-zone-exists +++ a/include/linux/mmzone.h @@ -1047,6 +1047,15 @@ static inline int is_highmem_idx(enum zo #endif } +#ifdef CONFIG_ZONE_DMA +bool has_managed_dma(void); +#else +static inline bool has_managed_dma(void) +{ + return false; +} +#endif + /** * is_highmem - helper function to quickly check if a struct zone is a * highmem zone or not. This is an attempt to keep references --- a/mm/page_alloc.c~mm_zone-add-function-to-check-if-managed-dma-zone-exists +++ a/mm/page_alloc.c @@ -9518,3 +9518,18 @@ bool take_page_off_buddy(struct page *pa return ret; } #endif + +#ifdef CONFIG_ZONE_DMA +bool has_managed_dma(void) +{ + struct pglist_data *pgdat; + + for_each_online_pgdat(pgdat) { + struct zone *zone = &pgdat->node_zones[ZONE_DMA]; + + if (managed_zone(zone)) + return true; + } + return false; +} +#endif /* CONFIG_ZONE_DMA */ _ Patches currently in -mm which might be from bhe(a)redhat.com are

2 years, 11 months

1
0
0 0

stable-rc/queue/4.4 baseline: 102 runs, 1 regressions (v4.4.299-9-g7958be08b7c2)

by kernelci.org bot

stable-rc/queue/4.4 baseline: 102 runs, 1 regressions (v4.4.299-9-g7958be08b7c2) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.4/kernel/v4.4.299-… Test: baseline Tree: stable-rc Branch: queue/4.4 Describe: v4.4.299-9-g7958be08b7c2 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 7958be08b7c2f5e180fd9a35077dd90b1342cd31 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/61e99feb384f444b15abbd1b Results: 4 PASS, 1 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.299-9-g7958be08b7c2/… HTML log: https://storage.kernelci.org//stable-rc/queue-4.4/v4.4.299-9-g7958be08b7c2/… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/61e99feb384f444b15abbd21 new failure (last pass: v4.4.299-9-gf0ed06ea70f9) 2 lines 2022-01-20T17:45:58.503864 [ 18.825378] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=pass UNITS=lines MEASUREMENT=0> 2022-01-20T17:45:58.547967 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/112 2022-01-20T17:45:58.557033 kern :emerg : lock: emif_lock+0x0/0xfffff25c [emif], .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0

2 years, 11 months

1
0
0 0

[merged] shmem-fix-a-race-between-shmem_unused_huge_shrink-and-shmem_evict_inode.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: shmem: fix a race between shmem_unused_huge_shrink and shmem_evict_inode has been removed from the -mm tree. Its filename was shmem-fix-a-race-between-shmem_unused_huge_shrink-and-shmem_evict_inode.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Gang Li <ligang.bdlg(a)bytedance.com> Subject: shmem: fix a race between shmem_unused_huge_shrink and shmem_evict_inode Fix a data race in commit 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure"). Here are call traces causing race: Call Trace 1: shmem_unused_huge_shrink+0x3ae/0x410 ? __list_lru_walk_one.isra.5+0x33/0x160 super_cache_scan+0x17c/0x190 shrink_slab.part.55+0x1ef/0x3f0 shrink_node+0x10e/0x330 kswapd+0x380/0x740 kthread+0xfc/0x130 ? mem_cgroup_shrink_node+0x170/0x170 ? kthread_create_on_node+0x70/0x70 ret_from_fork+0x1f/0x30 Call Trace 2: shmem_evict_inode+0xd8/0x190 evict+0xbe/0x1c0 do_unlinkat+0x137/0x330 do_syscall_64+0x76/0x120 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 A simple explanation: Image there are 3 items in the local list (@list). In the first traversal, A is not deleted from @list. 1) A->B->C ^ | pos (leave) In the second traversal, B is deleted from @list. Concurrently, A is deleted from @list through shmem_evict_inode() since last reference counter of inode is dropped by other thread. Then the @list is corrupted. 2) A->B->C ^ ^ | | evict pos (drop) We should make sure the inode is either on the global list or deleted from any local list before iput(). Fixed by moving inodes back to global list before we put them. [akpm(a)linux-foundation.org: coding style fixes] Link: https://lkml.kernel.org/r/20211125064502.99983-1-ligang.bdlg@bytedance.com Fixes: 779750d20b93 ("shmem: split huge pages beyond i_size under memory pressure") Signed-off-by: Gang Li <ligang.bdlg(a)bytedance.com> Reviewed-by: Muchun Song <songmuchun(a)bytedance.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-) --- a/mm/shmem.c~shmem-fix-a-race-between-shmem_unused_huge_shrink-and-shmem_evict_inode +++ a/mm/shmem.c @@ -554,7 +554,7 @@ static unsigned long shmem_unused_huge_s struct shmem_inode_info *info; struct page *page; unsigned long batch = sc ? sc->nr_to_scan : 128; - int removed = 0, split = 0; + int split = 0; if (list_empty(&sbinfo->shrinklist)) return SHRINK_STOP; @@ -569,7 +569,6 @@ static unsigned long shmem_unused_huge_s /* inode is about to be evicted */ if (!inode) { list_del_init(&info->shrinklist); - removed++; goto next; } @@ -577,12 +576,12 @@ static unsigned long shmem_unused_huge_s if (round_up(inode->i_size, PAGE_SIZE) == round_up(inode->i_size, HPAGE_PMD_SIZE)) { list_move(&info->shrinklist, &to_remove); - removed++; goto next; } list_move(&info->shrinklist, &list); next: + sbinfo->shrinklist_len--; if (!--batch) break; } @@ -602,7 +601,7 @@ next: inode = &info->vfs_inode; if (nr_to_split && split >= nr_to_split) - goto leave; + goto move_back; page = find_get_page(inode->i_mapping, (inode->i_size & HPAGE_PMD_MASK) >> PAGE_SHIFT); @@ -616,38 +615,44 @@ next: } /* - * Leave the inode on the list if we failed to lock - * the page at this time. + * Move the inode on the list back to shrinklist if we failed + * to lock the page at this time. * * Waiting for the lock may lead to deadlock in the * reclaim path. */ if (!trylock_page(page)) { put_page(page); - goto leave; + goto move_back; } ret = split_huge_page(page); unlock_page(page); put_page(page); - /* If split failed leave the inode on the list */ + /* If split failed move the inode on the list back to shrinklist */ if (ret) - goto leave; + goto move_back; split++; drop: list_del_init(&info->shrinklist); - removed++; -leave: + goto put; +move_back: + /* + * Make sure the inode is either on the global list or deleted + * from any local list before iput() since it could be deleted + * in another thread once we put the inode (then the local list + * is corrupted). + */ + spin_lock(&sbinfo->shrinklist_lock); + list_move(&info->shrinklist, &sbinfo->shrinklist); + sbinfo->shrinklist_len++; + spin_unlock(&sbinfo->shrinklist_lock); +put: iput(inode); } - spin_lock(&sbinfo->shrinklist_lock); - list_splice_tail(&list, &sbinfo->shrinklist); - sbinfo->shrinklist_len -= removed; - spin_unlock(&sbinfo->shrinklist_lock); - return split; } _ Patches currently in -mm which might be from ligang.bdlg(a)bytedance.com are

2 years, 11 months

1
0
0 0

stable-rc/linux-4.4.y baseline: 280 runs, 3 regressions (v4.4.299)

by kernelci.org bot

stable-rc/linux-4.4.y baseline: 280 runs, 3 regressions (v4.4.299) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 qemu_i386 | i386 | lab-cip | gcc-10 | i386_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.299/… Test: baseline Tree: stable-rc Branch: linux-4.4.y Describe: v4.4.299 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: b0ee52316847cf279a1028334117985a5d633c0c Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/61e3ec69b3b9c29e62ef6743 Results: 4 PASS, 1 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.299/arm/omap2plus_… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.299/arm/omap2plus_… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2021… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/61e3ec69b3b9c29e62ef6746 failing since 17 days (last pass: v4.4.296-18-gea28db322a98, first fail: v4.4.297) 2 lines 2022-01-16T09:58:49.344939 [ 19.041595] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=pass UNITS=lines MEASUREMENT=0> 2022-01-16T09:58:49.388470 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/118 2022-01-16T09:58:49.397841 kern :emerg : lock: emif_lock+0x0/0xfffff25c [emif], .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 platform | arch | lab | compiler | defconfig | regressions ----------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-10 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/61e998b9eb656cbe91abbd2b Results: 4 PASS, 1 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.299/arm/omap2plus_… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.299/arm/omap2plus_… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/61e998b9eb656cbe91abbd31 failing since 17 days (last pass: v4.4.296-18-gea28db322a98, first fail: v4.4.297) 2 lines 2022-01-20T17:15:14.030747 kern :emerg : BUG: spinlock bad magic on CPU#0, udevd/119 2022-01-20T17:15:14.040203 kern :emerg : lock: emif_lock+0x0/0xfffff25c [emif], .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 2022-01-20T17:15:14.057106 [ 19.355377] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=emerg RESULT=fail UNITS=lines MEASUREMENT=2> platform | arch | lab | compiler | defconfig | regressions ----------+------+---------------+----------+---------------------+------------ qemu_i386 | i386 | lab-cip | gcc-10 | i386_defconfig | 1 Details: https://kernelci.org/test/plan/id/61e99986297ef36a9fabbd1b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: i386_defconfig Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.299/i386/i386_defc… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.299/i386/i386_defc… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/61e99986297ef36a9fabbd1c new failure (last pass: v4.4.299-10-g5f58931b34ba)

2 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2022