February 2021 - Linux-stable-mirror

[PATCH AUTOSEL 4.19 01/14] arm64: dts: rockchip: Fix PCIe DT properties on rk3399

by Sasha Levin

From: Marc Zyngier <maz(a)kernel.org> [ Upstream commit 43f20b1c6140896916f4e91aacc166830a7ba849 ] It recently became apparent that the lack of a 'device_type = "pci"' in the PCIe root complex node for rk3399 is a violation of the PCI binding, as documented in IEEE Std 1275-1994. Changes to the kernel's parsing of the DT made such violation fatal, as drivers cannot probe the controller anymore. Add the missing property makes the PCIe node compliant. While we are at it, drop the pointless linux,pci-domain property, which only makes sense when there are multiple host bridges. Signed-off-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20200815125112.462652-3-maz@kernel.org Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index f4ee7c4f83b8b..b1c1a88a1c20c 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -198,6 +198,7 @@ pcie0: pcie@f8000000 { reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>; reg-names = "axi-base", "apb-base"; + device_type = "pci"; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; @@ -216,7 +217,6 @@ pcie0: pcie@f8000000 { <0 0 0 2 &pcie0_intc 1>, <0 0 0 3 &pcie0_intc 2>, <0 0 0 4 &pcie0_intc 3>; - linux,pci-domain = <0>; max-link-speed = <1>; msi-map = <0x0 &its 0x0 0x1000>; phys = <&pcie_phy 0>, <&pcie_phy 1>, -- 2.27.0

3 years, 11 months

1
13
0 0

[PATCH AUTOSEL 5.4 01/19] arm64: dts: rockchip: Fix PCIe DT properties on rk3399

by Sasha Levin

From: Marc Zyngier <maz(a)kernel.org> [ Upstream commit 43f20b1c6140896916f4e91aacc166830a7ba849 ] It recently became apparent that the lack of a 'device_type = "pci"' in the PCIe root complex node for rk3399 is a violation of the PCI binding, as documented in IEEE Std 1275-1994. Changes to the kernel's parsing of the DT made such violation fatal, as drivers cannot probe the controller anymore. Add the missing property makes the PCIe node compliant. While we are at it, drop the pointless linux,pci-domain property, which only makes sense when there are multiple host bridges. Signed-off-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20200815125112.462652-3-maz@kernel.org Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index bb7d0aac6b9db..9d6ed8cda2c86 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -232,6 +232,7 @@ pcie0: pcie@f8000000 { reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>; reg-names = "axi-base", "apb-base"; + device_type = "pci"; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; @@ -250,7 +251,6 @@ pcie0: pcie@f8000000 { <0 0 0 2 &pcie0_intc 1>, <0 0 0 3 &pcie0_intc 2>, <0 0 0 4 &pcie0_intc 3>; - linux,pci-domain = <0>; max-link-speed = <1>; msi-map = <0x0 &its 0x0 0x1000>; phys = <&pcie_phy 0>, <&pcie_phy 1>, -- 2.27.0

3 years, 11 months

1
18
0 0

[merged] mm-hugetlb-fix-missing-put_page-in-gather_surplus_pages.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: hugetlb: fix missing put_page in gather_surplus_pages() has been removed from the -mm tree. Its filename was mm-hugetlb-fix-missing-put_page-in-gather_surplus_pages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Muchun Song <songmuchun(a)bytedance.com> Subject: mm: hugetlb: fix missing put_page in gather_surplus_pages() The VM_BUG_ON_PAGE avoids the generation of any code, even if that expression has side-effects when !CONFIG_DEBUG_VM. Link: https://lkml.kernel.org/r/20210126031009.96266-1-songmuchun@bytedance.com Fixes: e5dfacebe4a4 ("mm/hugetlb.c: just use put_page_testzero() instead of page_count()") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-missing-put_page-in-gather_surplus_pages +++ a/mm/hugetlb.c @@ -2047,13 +2047,16 @@ retry: /* Free the needed pages to the hugetlb pool */ list_for_each_entry_safe(page, tmp, &surplus_list, lru) { + int zeroed; + if ((--needed) < 0) break; /* * This page is now managed by the hugetlb allocator and has * no users -- drop the buddy allocator's reference. */ - VM_BUG_ON_PAGE(!put_page_testzero(page), page); + zeroed = put_page_testzero(page); + VM_BUG_ON_PAGE(!zeroed, page); enqueue_huge_page(h, page); } free: _ Patches currently in -mm which might be from songmuchun(a)bytedance.com are mm-memcontrol-optimize-per-lruvec-stats-counter-memory-usage.patch mm-memcontrol-fix-nr_anon_thps-accounting-in-charge-moving.patch mm-memcontrol-convert-nr_anon_thps-account-to-pages.patch mm-memcontrol-convert-nr_file_thps-account-to-pages.patch mm-memcontrol-convert-nr_shmem_thps-account-to-pages.patch mm-memcontrol-convert-nr_shmem_pmdmapped-account-to-pages.patch mm-memcontrol-convert-nr_file_pmdmapped-account-to-pages.patch mm-memcontrol-make-the-slab-calculation-consistent.patch mm-memcontrol-replace-the-loop-with-a-list_for_each_entry.patch hugetlb-convert-page_huge_active-hpagemigratable-flag-fix.patch

3 years, 11 months

1
0
0 0

[merged] mm-filemap-adding-missing-mem_cgroup_uncharge-to-__add_to_page_cache_locked.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked() has been removed from the -mm tree. Its filename was mm-filemap-adding-missing-mem_cgroup_uncharge-to-__add_to_page_cache_locked.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Waiman Long <longman(a)redhat.com> Subject: mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked() commit 3fea5a499d57 ("mm: memcontrol: convert page cache to a new mem_cgroup_charge() API") introduced a bug in __add_to_page_cache_locked() causing the following splat: [ 1570.068330] page dumped because: VM_BUG_ON_PAGE(page_memcg(page)) [ 1570.068333] pages's memcg:ffff8889a4116000 [ 1570.068343] ------------[ cut here ]------------ [ 1570.068346] kernel BUG at mm/memcontrol.c:2924! [ 1570.068355] invalid opcode: 0000 [#1] SMP KASAN PTI [ 1570.068359] CPU: 35 PID: 12345 Comm: cat Tainted: G S W I 5.11.0-rc4-debug+ #1 [ 1570.068363] Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 v01.25 12/06/2017 [ 1570.068365] RIP: 0010:commit_charge+0xf4/0x130 : [ 1570.068375] RSP: 0018:ffff8881b38d70e8 EFLAGS: 00010286 [ 1570.068379] RAX: 0000000000000000 RBX: ffffea00260ddd00 RCX: 0000000000000027 [ 1570.068382] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88907ebe05a8 [ 1570.068384] RBP: ffffea00260ddd00 R08: ffffed120fd7c0b6 R09: ffffed120fd7c0b6 [ 1570.068386] R10: ffff88907ebe05ab R11: ffffed120fd7c0b5 R12: ffffea00260ddd38 [ 1570.068389] R13: ffff8889a4116000 R14: ffff8889a4116000 R15: 0000000000000001 [ 1570.068391] FS: 00007ff039638680(0000) GS:ffff88907ea00000(0000) knlGS:0000000000000000 [ 1570.068394] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1570.068396] CR2: 00007f36f354cc20 CR3: 00000008a0126006 CR4: 00000000007706e0 [ 1570.068398] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1570.068400] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1570.068402] PKRU: 55555554 [ 1570.068404] Call Trace: [ 1570.068407] mem_cgroup_charge+0x175/0x770 [ 1570.068413] __add_to_page_cache_locked+0x712/0xad0 [ 1570.068439] add_to_page_cache_lru+0xc5/0x1f0 [ 1570.068461] cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles] [ 1570.068524] __fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache] [ 1570.068540] __nfs_readpages_from_fscache+0x16d/0x630 [nfs] [ 1570.068585] nfs_readpages+0x24e/0x540 [nfs] [ 1570.068693] read_pages+0x5b1/0xc40 [ 1570.068711] page_cache_ra_unbounded+0x460/0x750 [ 1570.068729] generic_file_buffered_read_get_pages+0x290/0x1710 [ 1570.068756] generic_file_buffered_read+0x2a9/0xc30 [ 1570.068832] nfs_file_read+0x13f/0x230 [nfs] [ 1570.068872] new_sync_read+0x3af/0x610 [ 1570.068901] vfs_read+0x339/0x4b0 [ 1570.068909] ksys_read+0xf1/0x1c0 [ 1570.068920] do_syscall_64+0x33/0x40 [ 1570.068926] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1570.068930] RIP: 0033:0x7ff039135595 Before that commit, there was a try_charge() and commit_charge() in __add_to_page_cache_locked(). These 2 separated charge functions were replaced by a single mem_cgroup_charge(). However, it forgot to add a matching mem_cgroup_uncharge() when the xarray insertion failed with the page released back to the pool. Fix this by adding a mem_cgroup_uncharge() call when insertion error happens. Link: https://lkml.kernel.org/r/20210125042441.20030-1-longman@redhat.com Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new mem_cgroup_charge() API") Signed-off-by: Waiman Long <longman(a)redhat.com> Reviewed-by: Alex Shi <alex.shi(a)linux.alibaba.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Muchun Song <smuchun(a)gmail.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/filemap.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/mm/filemap.c~mm-filemap-adding-missing-mem_cgroup_uncharge-to-__add_to_page_cache_locked +++ a/mm/filemap.c @@ -835,6 +835,7 @@ noinline int __add_to_page_cache_locked( XA_STATE(xas, &mapping->i_pages, offset); int huge = PageHuge(page); int error; + bool charged = false; VM_BUG_ON_PAGE(!PageLocked(page), page); VM_BUG_ON_PAGE(PageSwapBacked(page), page); @@ -848,6 +849,7 @@ noinline int __add_to_page_cache_locked( error = mem_cgroup_charge(page, current->mm, gfp); if (error) goto error; + charged = true; } gfp &= GFP_RECLAIM_MASK; @@ -896,6 +898,8 @@ unlock: if (xas_error(&xas)) { error = xas_error(&xas); + if (charged) + mem_cgroup_uncharge(page); goto error; } _ Patches currently in -mm which might be from longman(a)redhat.com are

3 years, 11 months

1
0
0 0

[merged] memblock-do-not-start-bottom-up-allocations-with-kernel_end.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: memblock: do not start bottom-up allocations with kernel_end has been removed from the -mm tree. Its filename was memblock-do-not-start-bottom-up-allocations-with-kernel_end.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Roman Gushchin <guro(a)fb.com> Subject: memblock: do not start bottom-up allocations with kernel_end With kaslr the kernel image is placed at a random place, so starting the bottom-up allocation with the kernel_end can result in an allocation failure and a warning like this one: [ 0.002920] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node [ 0.002921] ------------[ cut here ]------------ [ 0.002922] memblock: bottom-up allocation failed, memory hotremove may be affected [ 0.002937] WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x178/0x25a [ 0.002937] Modules linked in: [ 0.002939] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #1169 [ 0.002940] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 [ 0.002942] RIP: 0010:memblock_find_in_range_node+0x178/0x25a [ 0.002944] Code: e9 6d ff ff ff 48 85 c0 0f 85 da 00 00 00 80 3d 9b 35 df 00 00 75 15 48 c7 c7 c0 75 59 88 c6 05 8b 35 df 00 01 e8 25 8a fa ff <0f> 0b 48 c7 44 24 20 ff ff ff ff 44 89 e6 44 89 ea 48 c7 c1 70 5c [ 0.002945] RSP: 0000:ffffffff88803d18 EFLAGS: 00010086 ORIG_RAX: 0000000000000000 [ 0.002947] RAX: 0000000000000000 RBX: 0000000240000000 RCX: 00000000ffffdfff [ 0.002948] RDX: 00000000ffffdfff RSI: 00000000ffffffea RDI: 0000000000000046 [ 0.002948] RBP: 0000000100000000 R08: ffffffff88922788 R09: 0000000000009ffb [ 0.002949] R10: 00000000ffffe000 R11: 3fffffffffffffff R12: 0000000000000000 [ 0.002950] R13: 0000000000000000 R14: 0000000080000000 R15: 00000001fb42c000 [ 0.002952] FS: 0000000000000000(0000) GS:ffffffff88f71000(0000) knlGS:0000000000000000 [ 0.002953] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.002954] CR2: ffffa080fb401000 CR3: 00000001fa80a000 CR4: 00000000000406b0 [ 0.002956] Call Trace: [ 0.002961] ? memblock_alloc_range_nid+0x8d/0x11e [ 0.002963] ? cma_declare_contiguous_nid+0x2c4/0x38c [ 0.002964] ? hugetlb_cma_reserve+0xdc/0x128 [ 0.002968] ? flush_tlb_one_kernel+0xc/0x20 [ 0.002969] ? native_set_fixmap+0x82/0xd0 [ 0.002971] ? flat_get_apic_id+0x5/0x10 [ 0.002973] ? register_lapic_address+0x8e/0x97 [ 0.002975] ? setup_arch+0x8a5/0xc3f [ 0.002978] ? start_kernel+0x66/0x547 [ 0.002980] ? load_ucode_bsp+0x4c/0xcd [ 0.002982] ? secondary_startup_64_no_verify+0xb0/0xbb [ 0.002986] random: get_random_bytes called from __warn+0xab/0x110 with crng_init=0 [ 0.002988] ---[ end trace f151227d0b39be70 ]--- At the same time, the kernel image is protected with memblock_reserve(), so we can just start searching at PAGE_SIZE. In this case the bottom-up allocation has the same chances to success as a top-down allocation, so there is no reason to fallback in the case of a failure. All together it simplifies the logic. Link: https://lkml.kernel.org/r/20201217201214.3414100-2-guro@fb.com Fixes: 8fabc623238e ("powerpc: Ensure that swiotlb buffer is allocated from low memory") Signed-off-by: Roman Gushchin <guro(a)fb.com> Reviewed-by: Mike Rapoport <rppt(a)linux.ibm.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Rik van Riel <riel(a)surriel.com> Cc: Wonhyuk Yang <vvghjk1234(a)gmail.com> Cc: Thiago Jung Bauermann <bauerman(a)linux.ibm.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memblock.c | 49 +++++------------------------------------------- 1 file changed, 6 insertions(+), 43 deletions(-) --- a/mm/memblock.c~memblock-do-not-start-bottom-up-allocations-with-kernel_end +++ a/mm/memblock.c @@ -275,14 +275,6 @@ __memblock_find_range_top_down(phys_addr * * Find @size free area aligned to @align in the specified range and node. * - * When allocation direction is bottom-up, the @start should be greater - * than the end of the kernel image. Otherwise, it will be trimmed. The - * reason is that we want the bottom-up allocation just near the kernel - * image so it is highly likely that the allocated memory and the kernel - * will reside in the same node. - * - * If bottom-up allocation failed, will try to allocate memory top-down. - * * Return: * Found address on success, 0 on failure. */ @@ -291,8 +283,6 @@ static phys_addr_t __init_memblock membl phys_addr_t end, int nid, enum memblock_flags flags) { - phys_addr_t kernel_end, ret; - /* pump up @end */ if (end == MEMBLOCK_ALLOC_ACCESSIBLE || end == MEMBLOCK_ALLOC_KASAN) @@ -301,40 +291,13 @@ static phys_addr_t __init_memblock membl /* avoid allocating the first page */ start = max_t(phys_addr_t, start, PAGE_SIZE); end = max(start, end); - kernel_end = __pa_symbol(_end); - - /* - * try bottom-up allocation only when bottom-up mode - * is set and @end is above the kernel image. - */ - if (memblock_bottom_up() && end > kernel_end) { - phys_addr_t bottom_up_start; - - /* make sure we will allocate above the kernel */ - bottom_up_start = max(start, kernel_end); - - /* ok, try bottom-up allocation first */ - ret = __memblock_find_range_bottom_up(bottom_up_start, end, - size, align, nid, flags); - if (ret) - return ret; - - /* - * we always limit bottom-up allocation above the kernel, - * but top-down allocation doesn't have the limit, so - * retrying top-down allocation may succeed when bottom-up - * allocation failed. - * - * bottom-up allocation is expected to be fail very rarely, - * so we use WARN_ONCE() here to see the stack trace if - * fail happens. - */ - WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), - "memblock: bottom-up allocation failed, memory hotremove may be affected\n"); - } - return __memblock_find_range_top_down(start, end, size, align, nid, - flags); + if (memblock_bottom_up()) + return __memblock_find_range_bottom_up(start, end, size, align, + nid, flags); + else + return __memblock_find_range_top_down(start, end, size, align, + nid, flags); } /** _ Patches currently in -mm which might be from guro(a)fb.com are mm-memcg-slab-pre-allocate-obj_cgroups-for-slab-caches-with-slab_account.patch mm-kmem-make-__memcg_kmem_uncharge-static.patch mm-cma-allocate-cma-areas-bottom-up.patch mm-cma-allocate-cma-areas-bottom-up-fix.patch mm-cma-allocate-cma-areas-bottom-up-fix-2.patch mm-cma-allocate-cma-areas-bottom-up-fix-3.patch mm-vmstat-fix-proc-sys-vm-stat_refresh-generating-false-warnings.patch mm-vmstat-fix-proc-sys-vm-stat_refresh-generating-false-warnings-fix.patch

3 years, 11 months

1
0
0 0

[merged] mm-thp-fix-madv_remove-deadlock-on-shmem-thp.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: thp: fix MADV_REMOVE deadlock on shmem THP has been removed from the -mm tree. Its filename was mm-thp-fix-madv_remove-deadlock-on-shmem-thp.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm: thp: fix MADV_REMOVE deadlock on shmem THP Sergey reported deadlock between kswapd correctly doing its usual lock_page(page) followed by down_read(page->mapping->i_mmap_rwsem), and madvise(MADV_REMOVE) on an madvise(MADV_HUGEPAGE) area doing down_write(page->mapping->i_mmap_rwsem) followed by lock_page(page). This happened when shmem_fallocate(punch hole)'s unmap_mapping_range() reaches zap_pmd_range()'s call to __split_huge_pmd(). The same deadlock could occur when partially truncating a mapped huge tmpfs file, or using fallocate(FALLOC_FL_PUNCH_HOLE) on it. __split_huge_pmd()'s page lock was added in 5.8, to make sure that any concurrent use of reuse_swap_page() (holding page lock) could not catch the anon THP's mapcounts and swapcounts while they were being split. Fortunately, reuse_swap_page() is never applied to a shmem or file THP (not even by khugepaged, which checks PageSwapCache before calling), and anonymous THPs are never created in shmem or file areas: so that __split_huge_pmd()'s page lock can only be necessary for anonymous THPs, on which there is no risk of deadlock with i_mmap_rwsem. Link: https://lkml.kernel.org/r/alpine.LSU.2.11.2101161409470.2022@eggly.anvils Fixes: c444eb564fb1 ("mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()") Signed-off-by: Hugh Dickins <hughd(a)google.com> Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Reviewed-by: Andrea Arcangeli <aarcange(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) --- a/mm/huge_memory.c~mm-thp-fix-madv_remove-deadlock-on-shmem-thp +++ a/mm/huge_memory.c @@ -2202,7 +2202,7 @@ void __split_huge_pmd(struct vm_area_str { spinlock_t *ptl; struct mmu_notifier_range range; - bool was_locked = false; + bool do_unlock_page = false; pmd_t _pmd; mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, @@ -2218,7 +2218,6 @@ void __split_huge_pmd(struct vm_area_str VM_BUG_ON(freeze && !page); if (page) { VM_WARN_ON_ONCE(!PageLocked(page)); - was_locked = true; if (page != pmd_page(*pmd)) goto out; } @@ -2227,19 +2226,29 @@ repeat: if (pmd_trans_huge(*pmd)) { if (!page) { page = pmd_page(*pmd); - if (unlikely(!trylock_page(page))) { - get_page(page); - _pmd = *pmd; - spin_unlock(ptl); - lock_page(page); - spin_lock(ptl); - if (unlikely(!pmd_same(*pmd, _pmd))) { - unlock_page(page); + /* + * An anonymous page must be locked, to ensure that a + * concurrent reuse_swap_page() sees stable mapcount; + * but reuse_swap_page() is not used on shmem or file, + * and page lock must not be taken when zap_pmd_range() + * calls __split_huge_pmd() while i_mmap_lock is held. + */ + if (PageAnon(page)) { + if (unlikely(!trylock_page(page))) { + get_page(page); + _pmd = *pmd; + spin_unlock(ptl); + lock_page(page); + spin_lock(ptl); + if (unlikely(!pmd_same(*pmd, _pmd))) { + unlock_page(page); + put_page(page); + page = NULL; + goto repeat; + } put_page(page); - page = NULL; - goto repeat; } - put_page(page); + do_unlock_page = true; } } if (PageMlocked(page)) @@ -2249,7 +2258,7 @@ repeat: __split_huge_pmd_locked(vma, pmd, range.start, freeze); out: spin_unlock(ptl); - if (!was_locked && page) + if (do_unlock_page) unlock_page(page); /* * No need to double call mmu_notifier->invalidate_range() callback. _ Patches currently in -mm which might be from hughd(a)google.com are

3 years, 11 months

1
0
0 0

[merged] mm-vmalloc-separate-put-pages-and-flush-vm-flags.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/vmalloc: separate put pages and flush VM flags has been removed from the -mm tree. Its filename was mm-vmalloc-separate-put-pages-and-flush-vm-flags.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Subject: mm/vmalloc: separate put pages and flush VM flags When VM_MAP_PUT_PAGES was added, it was defined with the same value as VM_FLUSH_RESET_PERMS. This doesn't seem like it will cause any big functional problems other than some excess flushing for VM_MAP_PUT_PAGES allocations. Redefine VM_MAP_PUT_PAGES to have its own value. Also, rearrange things so flags are less likely to be missed in the future. Link: https://lkml.kernel.org/r/20210122233706.9304-1-rick.p.edgecombe@intel.com Fixes: b944afc9d64d ("mm: add a VM_MAP_PUT_PAGES flag for vmap") Signed-off-by: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Suggested-by: Matthew Wilcox <willy(a)infradead.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Daniel Axtens <dja(a)axtens.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/vmalloc.h | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/include/linux/vmalloc.h~mm-vmalloc-separate-put-pages-and-flush-vm-flags +++ a/include/linux/vmalloc.h @@ -24,7 +24,8 @@ struct notifier_block; /* in notifier.h #define VM_UNINITIALIZED 0x00000020 /* vm_struct is not fully initialized */ #define VM_NO_GUARD 0x00000040 /* don't add guard page */ #define VM_KASAN 0x00000080 /* has allocated kasan shadow memory */ -#define VM_MAP_PUT_PAGES 0x00000100 /* put pages and free array in vfree */ +#define VM_FLUSH_RESET_PERMS 0x00000100 /* reset direct map and flush TLB on unmap, can't be freed in atomic context */ +#define VM_MAP_PUT_PAGES 0x00000200 /* put pages and free array in vfree */ /* * VM_KASAN is used slighly differently depending on CONFIG_KASAN_VMALLOC. @@ -37,12 +38,6 @@ struct notifier_block; /* in notifier.h * determine which allocations need the module shadow freed. */ -/* - * Memory with VM_FLUSH_RESET_PERMS cannot be freed in an interrupt or with - * vfree_atomic(). - */ -#define VM_FLUSH_RESET_PERMS 0x00000100 /* Reset direct map and flush TLB on unmap */ - /* bits [20..32] reserved for arch specific ioremap internals */ /* _ Patches currently in -mm which might be from rick.p.edgecombe(a)intel.com are

3 years, 11 months

1
0
0 0

Linux 4.4.256

by Greg Kroah-Hartman

I'm announcing the release of the 4.4.256 kernel. This, and the 4.9.256 release are a little bit "different" than normal. This contains only 1 patch, just the version bump from .255 to .256 which ends up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently than normal due to the "overflow". With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0). Nothing in the kernel build itself breaks with this change, but given that this is a userspace visible change, and some crazy tools (like glibc and gcc) have logic that checks the kernel version for different reasons, I wanted to do this release as an "empty" release to ensure that everything still works properly. So, this is a YOU MUST UPGRADE requirement of a release. If you rely on the 4.4.y kernel, please throw this release into your test builds and rebuild the world and let us know if anything breaks, or if all is well. Go forth and do full system rebuilds! Yocto and Gentoo are great for this, as will systems that use buildroot. I'll try to hold off on doing a "real" 4.4.y release for a week to give everyone a chance to test this out and get back to me. The pending patches in the 4.4.y queue are pretty serious, so I am loath to wait longer than that, consider yourself warned... The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Greg Kroah-Hartman (1): Linux 4.4.256

3 years, 11 months

4
16
0 0

[merged] mm-compaction-move-high_pfn-to-the-for-loop-scope.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, compaction: move high_pfn to the for loop scope has been removed from the -mm tree. Its filename was mm-compaction-move-high_pfn-to-the-for-loop-scope.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Rokudo Yan <wu-yan(a)tcl.com> Subject: mm, compaction: move high_pfn to the for loop scope In fast_isolate_freepages, high_pfn will be used if a prefered one(PFN >= low_fn) not found. But the high_pfn is not reset before searching an free area, so when it was used as freepage, it may from another free area searched before. And move_freelist_head(freelist, freepage) will have unexpected behavior(eg. corrupt the MOVABLE freelist) Unable to handle kernel paging request at virtual address dead000000000200 Mem abort info: ESR = 0x96000044 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000044 CM = 0, WnR = 1 [dead000000000200] address between user and kernel address ranges -000|list_cut_before(inline) -000|move_freelist_head(inline) -000|fast_isolate_freepages(inline) -000|isolate_freepages(inline) -000|compaction_alloc(?, ?) -001|unmap_and_move(inline) -001|migrate_pages([NSD:0xFFFFFF80088CBBD0] from = 0xFFFFFF80088CBD88, [NSD:0xFFFFFF80088CBBC8] get_new_p -002|__read_once_size(inline) -002|static_key_count(inline) -002|static_key_false(inline) -002|trace_mm_compaction_migratepages(inline) -002|compact_zone(?, [NSD:0xFFFFFF80088CBCB0] capc = 0x0) -003|kcompactd_do_work(inline) -003|kcompactd([X19] p = 0xFFFFFF93227FBC40) -004|kthread([X20] _create = 0xFFFFFFE1AFB26380) -005|ret_from_fork(asm) ---|end of frame The issue was reported on an smart phone product with 6GB ram and 3GB zram as swap device. This patch fixes the issue by reset high_pfn before searching each free area, which ensure freepage and freelist match when call move_freelist_head in fast_isolate_freepages(). Link: http://lkml.kernel.org/r/20190118175136.31341-12-mgorman@techsingularity.net Link: https://lkml.kernel.org/r/20210112094720.1238444-1-wu-yan@tcl.com Fixes: 5a811889de10f1eb ("mm, compaction: use free lists to quickly locate a migration target") Signed-off-by: Rokudo Yan <wu-yan(a)tcl.com> Acked-by: Mel Gorman <mgorman(a)techsingularity.net> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/compaction.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/compaction.c~mm-compaction-move-high_pfn-to-the-for-loop-scope +++ a/mm/compaction.c @@ -1342,7 +1342,7 @@ fast_isolate_freepages(struct compact_co { unsigned int limit = min(1U, freelist_scan_limit(cc) >> 1); unsigned int nr_scanned = 0; - unsigned long low_pfn, min_pfn, high_pfn = 0, highest = 0; + unsigned long low_pfn, min_pfn, highest = 0; unsigned long nr_isolated = 0; unsigned long distance; struct page *page = NULL; @@ -1387,6 +1387,7 @@ fast_isolate_freepages(struct compact_co struct page *freepage; unsigned long flags; unsigned int order_scanned = 0; + unsigned long high_pfn = 0; if (!area->nr_free) continue; _ Patches currently in -mm which might be from wu-yan(a)tcl.com are zsmalloc-account-the-number-of-compacted-pages-correctly.patch

3 years, 11 months

1
0
0 0

[merged] mm-hugetlb-remove-vm_bug_on_page-from-page_huge_active.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active has been removed from the -mm tree. Its filename was mm-hugetlb-remove-vm_bug_on_page-from-page_huge_active.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Muchun Song <songmuchun(a)bytedance.com> Subject: mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active The page_huge_active() can be called from scan_movable_pages() which do not hold a reference count to the HugeTLB page. So when we call page_huge_active() from scan_movable_pages(), the HugeTLB page can be freed parallel. Then we will trigger a BUG_ON which is in the page_huge_active() when CONFIG_DEBUG_VM is enabled. Just remove the VM_BUG_ON_PAGE. Link: https://lkml.kernel.org/r/20210115124942.46403-6-songmuchun@bytedance.com Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: David Hildenbrand <david(a)redhat.com> Cc: Yang Shi <shy828301(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-remove-vm_bug_on_page-from-page_huge_active +++ a/mm/hugetlb.c @@ -1361,8 +1361,7 @@ struct hstate *size_to_hstate(unsigned l */ bool page_huge_active(struct page *page) { - VM_BUG_ON_PAGE(!PageHuge(page), page); - return PageHead(page) && PagePrivate(&page[1]); + return PageHeadHuge(page) && PagePrivate(&page[1]); } /* never called for tail page */ _ Patches currently in -mm which might be from songmuchun(a)bytedance.com are mm-memcontrol-optimize-per-lruvec-stats-counter-memory-usage.patch mm-memcontrol-fix-nr_anon_thps-accounting-in-charge-moving.patch mm-memcontrol-convert-nr_anon_thps-account-to-pages.patch mm-memcontrol-convert-nr_file_thps-account-to-pages.patch mm-memcontrol-convert-nr_shmem_thps-account-to-pages.patch mm-memcontrol-convert-nr_shmem_pmdmapped-account-to-pages.patch mm-memcontrol-convert-nr_file_pmdmapped-account-to-pages.patch mm-memcontrol-make-the-slab-calculation-consistent.patch mm-memcontrol-replace-the-loop-with-a-list_for_each_entry.patch hugetlb-convert-page_huge_active-hpagemigratable-flag-fix.patch

3 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2021