May 2019 - Linux-stable-mirror

stable-rc/linux-4.9.y boot: 112 boots: 0 failed, 107 passed with 2 offline, 3 conflicts (v4.9.174-29-g50bbfeb1e2a3)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 112 boots: 0 failed, 107 passed with 2 offline, 3 conflicts (v4.9.174-29-g50bbfeb1e2a3) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.174-29-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.174-29-g50bbfeb1e2a3 Git Commit: 50bbfeb1e2a357db99ff35681cfa95341b33103a Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 52 unique boards, 22 SoC families, 15 builds out of 197 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: omap4-panda: lab-baylibre: new failure (last pass: v4.9.174) arm64: defconfig: gcc-8: meson-gxbb-p200: lab-baylibre: new failure (last pass: v4.9.174) Offline Platforms: arm: multi_v7_defconfig: gcc-8 stih410-b2120: 1 offline lab tegra20-iris-512: 1 offline lab Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: omap2plus_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) davinci_all_defconfig: da850-lcdk: lab-baylibre: PASS (gcc-8) lab-baylibre-seattle: FAIL (gcc-8) arm64: defconfig: meson-gxbb-p200: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

stable-rc/linux-5.0.y boot: 143 boots: 1 failed, 141 passed with 1 untried/unknown (v5.0.14-96-gdf1376651d49)

by kernelci.org bot

stable-rc/linux-5.0.y boot: 143 boots: 1 failed, 141 passed with 1 untried/unknown (v5.0.14-96-gdf1376651d49) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.0.y/kernel/v5.0.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.0.y/kernel/v5.0.14-96-g… Tree: stable-rc Branch: linux-5.0.y Git Describe: v5.0.14-96-gdf1376651d49 Git Commit: df1376651d496484d341d374c3d2566a089b1969 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 77 unique boards, 25 SoC families, 15 builds out of 208 Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

stable-rc/linux-3.18.y boot: 59 boots: 5 failed, 53 passed with 1 conflict (v3.18.139-64-gf6ad567f1ce4)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 59 boots: 5 failed, 53 passed with 1 conflict (v3.18.139-64-gf6ad567f1ce4) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.139-6… Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.139-64-gf6ad567f1ce4 Git Commit: f6ad567f1ce462b792c1747195066c73c429f9a9 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 24 unique boards, 12 SoC families, 13 builds out of 189 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: omap4-panda: lab-baylibre: failing since 1 day (last pass: v3.18.139-52-gf85e9af98591 - first fail: v3.18.139) Boot Failures Detected: x86_64: x86_64_defconfig: gcc-8: minnowboard-turbot-E3826: 1 failed lab qemu: 4 failed labs Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: multi_v7_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

stable-rc/linux-4.19.y boot: 135 boots: 1 failed, 132 passed with 2 conflicts (v4.19.41-67-g82fd2fd59cff)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 135 boots: 1 failed, 132 passed with 2 conflicts (v4.19.41-67-g82fd2fd59cff) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.41-67… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.41-67-g82fd2fd59cff Git Commit: 82fd2fd59cffa3045f205da555c0defe8bb35912 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 71 unique boards, 25 SoC families, 15 builds out of 206 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: omap4-panda: lab-baylibre: failing since 1 day (last pass: v4.19.40-100-gf897c76a347c - first fail: v4.19.41) x86_64: x86_64_defconfig: gcc-8: qemu: lab-collabora: new failure (last pass: v4.19.41-56-g487b15502665) Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu: lab-baylibre: PASS (gcc-8) lab-mhart: PASS (gcc-8) lab-drue: PASS (gcc-8) lab-collabora: FAIL (gcc-8) arm: omap2plus_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

Re: [PATCH] hugetlbfs: always use address space in inode for resv_map pointer

by yuyufen

On 2019/4/20 4:44, Mike Kravetz wrote: > Continuing discussion about commit 58b6e5e8f1ad ("hugetlbfs: fix memory > leak for resv_map") brought up the issue that inode->i_mapping may not > point to the address space embedded within the inode at inode eviction > time. The hugetlbfs truncate routine handles this by explicitly using > inode->i_data. However, code cleaning up the resv_map will still use > the address space pointed to by inode->i_mapping. Luckily, private_data > is NULL for address spaces in all such cases today but, there is no > guarantee this will continue. > > Change all hugetlbfs code getting a resv_map pointer to explicitly get > it from the address space embedded within the inode. In addition, add > more comments in the code to indicate why this is being done. > > Reported-by: Yufen Yu <yuyufen(a)huawei.com> > Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> > --- > fs/hugetlbfs/inode.c | 11 +++++++++-- > mm/hugetlb.c | 19 ++++++++++++++++++- > 2 files changed, 27 insertions(+), 3 deletions(-) > > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c > index 9285dd4f4b1c..cbc649cd1722 100644 > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -499,8 +499,15 @@ static void hugetlbfs_evict_inode(struct inode *inode) > struct resv_map *resv_map; > > remove_inode_hugepages(inode, 0, LLONG_MAX); > - resv_map = (struct resv_map *)inode->i_mapping->private_data; > - /* root inode doesn't have the resv_map, so we should check it */ > + > + /* > + * Get the resv_map from the address space embedded in the inode. > + * This is the address space which points to any resv_map allocated > + * at inode creation time. If this is a device special inode, > + * i_mapping may not point to the original address space. > + */ > + resv_map = (struct resv_map *)(&inode->i_data)->private_data; > + /* Only regular and link inodes have associated reserve maps */ > if (resv_map) > resv_map_release(&resv_map->refs); > clear_inode(inode); > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 6cdc7b2d9100..b30e97b0ef37 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -740,7 +740,15 @@ void resv_map_release(struct kref *ref) > > static inline struct resv_map *inode_resv_map(struct inode *inode) > { > - return inode->i_mapping->private_data; > + /* > + * At inode evict time, i_mapping may not point to the original > + * address space within the inode. This original address space > + * contains the pointer to the resv_map. So, always use the > + * address space embedded within the inode. > + * The VERY common case is inode->mapping == &inode->i_data but, > + * this may not be true for device special inodes. > + */ > + return (struct resv_map *)(&inode->i_data)->private_data; > } > > static struct resv_map *vma_resv_map(struct vm_area_struct *vma) > @@ -4477,6 +4485,11 @@ int hugetlb_reserve_pages(struct inode *inode, > * called to make the mapping read-write. Assume !vma is a shm mapping > */ > if (!vma || vma->vm_flags & VM_MAYSHARE) { > + /* > + * resv_map can not be NULL as hugetlb_reserve_pages is only > + * called for inodes for which resv_maps were created (see > + * hugetlbfs_get_inode). > + */ > resv_map = inode_resv_map(inode); > > chg = region_chg(resv_map, from, to); > @@ -4568,6 +4581,10 @@ long hugetlb_unreserve_pages(struct inode *inode, long start, long end, > struct hugepage_subpool *spool = subpool_inode(inode); > long gbl_reserve; > > + /* > + * Since this routine can be called in the evict inode path for all > + * hugetlbfs inodes, resv_map could be NULL. > + */ > if (resv_map) { > chg = region_del(resv_map, start, end); > /* Dose this patch have been applied? I think it is better to add fixes label, like: Fixes: 58b6e5e8f1ad ("hugetlbfs: fix memory leak for resv_map") Since the commit 58b6e5e8f1a has been merged to stable, this patch also be needed. https://www.spinics.net/lists/stable/msg298740.html

5 years, 9 months

3
3
0 0

stable-rc/linux-4.4.y boot: 98 boots: 2 failed, 95 passed with 1 conflict (v4.4.179-160-g2c68c4c9b112)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 98 boots: 2 failed, 95 passed with 1 conflict (v4.4.179-160-g2c68c4c9b112) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.179-160… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.179-160-g2c68c4c9b112 Git Commit: 2c68c4c9b1128c52fd9915bf8529f31601fc81b6 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 44 unique boards, 21 SoC families, 14 builds out of 190 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: omap4-panda: lab-baylibre: new failure (last pass: v4.4.179) Boot Failures Detected: arm: multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab arm64: defconfig: gcc-8: qcom-qdf2400: 1 failed lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: omap2plus_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

+ mm-hugetlb-dont-put_page-in-lock-of-hugetlb_lock.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/hugetlb.c: don't put_page in lock of hugetlb_lock has been added to the -mm tree. Its filename is mm-hugetlb-dont-put_page-in-lock-of-hugetlb_lock.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-dont-put_page-in-lock-o… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-dont-put_page-in-lock-o… 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 and is updated there every 3-4 working days ------------------------------------------------------ From: Kai Shen <shenkai8(a)huawei.com> Subject: mm/hugetlb.c: don't put_page in lock of hugetlb_lock spinlock recursion happened when do LTP test: #!/bin/bash ./runltp -p -f hugetlb & ./runltp -p -f hugetlb & ./runltp -p -f hugetlb & ./runltp -p -f hugetlb & ./runltp -p -f hugetlb & The dtor returned by get_compound_page_dtor in __put_compound_page may be the function of free_huge_page which will lock the hugetlb_lock, so don't put_page in lock of hugetlb_lock. BUG: spinlock recursion on CPU#0, hugemmap05/1079 lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0 Call trace: dump_backtrace+0x0/0x198 show_stack+0x24/0x30 dump_stack+0xa4/0xcc spin_dump+0x84/0xa8 do_raw_spin_lock+0xd0/0x108 _raw_spin_lock+0x20/0x30 free_huge_page+0x9c/0x260 __put_compound_page+0x44/0x50 __put_page+0x2c/0x60 alloc_surplus_huge_page.constprop.19+0xf0/0x140 hugetlb_acct_memory+0x104/0x378 hugetlb_reserve_pages+0xe0/0x250 hugetlbfs_file_mmap+0xc0/0x140 mmap_region+0x3e8/0x5b0 do_mmap+0x280/0x460 vm_mmap_pgoff+0xf4/0x128 ksys_mmap_pgoff+0xb4/0x258 __arm64_sys_mmap+0x34/0x48 el0_svc_common+0x78/0x130 el0_svc_handler+0x38/0x78 el0_svc+0x8/0xc Link: http://lkml.kernel.org/r/b8ade452-2d6b-0372-32c2-703644032b47@huawei.com Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks") Signed-off-by: Kai Shen <shenkai8(a)huawei.com> Signed-off-by: Feilong Lin <linfeilong(a)huawei.com> Reported-by: Wang Wang <wangwang2(a)huawei.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/hugetlb.c~mm-hugetlb-dont-put_page-in-lock-of-hugetlb_lock +++ a/mm/hugetlb.c @@ -1574,8 +1574,9 @@ static struct page *alloc_surplus_huge_p */ if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) { SetPageHugeTemporary(page); + spin_unlock(&hugetlb_lock); put_page(page); - page = NULL; + return NULL; } else { h->surplus_huge_pages++; h->surplus_huge_pages_node[page_to_nid(page)]++; _ Patches currently in -mm which might be from shenkai8(a)huawei.com are mm-hugetlb-dont-put_page-in-lock-of-hugetlb_lock.patch

5 years, 9 months

1
0
0 0

+ mm-huge_memory-fix-vmf_insert_pfn_pmd-pud-crash-handle-unaligned-addresses.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/huge_memory: fix vmf_insert_pfn_{pmd, pud}() crash, handle unaligned addresses has been added to the -mm tree. Its filename is mm-huge_memory-fix-vmf_insert_pfn_pmd-pud-crash-handle-unaligned-addresses.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-huge_memory-fix-vmf_insert_pfn_… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-huge_memory-fix-vmf_insert_pfn_… 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 and is updated there every 3-4 working days ------------------------------------------------------ From: Dan Williams <dan.j.williams(a)intel.com> Subject: mm/huge_memory: fix vmf_insert_pfn_{pmd, pud}() crash, handle unaligned addresses Starting with c6f3c5ee40c1 ("mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd()") vmf_insert_pfn_pmd() internally calls pmdp_set_access_flags(). That helper enforces a pmd aligned @address argument via VM_BUG_ON() assertion. Update the implementation to take a 'struct vm_fault' argument directly and apply the address alignment fixup internally to fix crash signatures like: kernel BUG at arch/x86/mm/pgtable.c:515! invalid opcode: 0000 [#1] SMP NOPTI CPU: 51 PID: 43713 Comm: java Tainted: G OE 4.19.35 #1 [..] RIP: 0010:pmdp_set_access_flags+0x48/0x50 [..] Call Trace: vmf_insert_pfn_pmd+0x198/0x350 dax_iomap_fault+0xe82/0x1190 ext4_dax_huge_fault+0x103/0x1f0 ? __switch_to_asm+0x40/0x70 __handle_mm_fault+0x3f6/0x1370 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 handle_mm_fault+0xda/0x200 __do_page_fault+0x249/0x4f0 do_page_fault+0x32/0x110 ? page_fault+0x8/0x30 page_fault+0x1e/0x30 Link: http://lkml.kernel.org/r/155741946350.372037.11148198430068238140.stgit@dwi… Fixes: c6f3c5ee40c1 ("mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd()") Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Reported-by: Piotr Balcer <piotr.balcer(a)intel.com> Tested-by: Yan Ma <yan.ma(a)intel.com> Reviewed-by: Matthew Wilcox <willy(a)infradead.org> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com> Cc: Chandan Rajendra <chandan(a)linux.ibm.com> Cc: Souptick Joarder <jrdr.linux(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/dax/device.c | 6 ++---- fs/dax.c | 6 ++---- include/linux/huge_mm.h | 6 ++---- mm/huge_memory.c | 16 ++++++++++------ 4 files changed, 16 insertions(+), 18 deletions(-) --- a/drivers/dax/device.c~mm-huge_memory-fix-vmf_insert_pfn_pmd-pud-crash-handle-unaligned-addresses +++ a/drivers/dax/device.c @@ -184,8 +184,7 @@ static vm_fault_t __dev_dax_pmd_fault(st *pfn = phys_to_pfn_t(phys, dax_region->pfn_flags); - return vmf_insert_pfn_pmd(vmf->vma, vmf->address, vmf->pmd, *pfn, - vmf->flags & FAULT_FLAG_WRITE); + return vmf_insert_pfn_pmd(vmf, *pfn, vmf->flags & FAULT_FLAG_WRITE); } #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD @@ -235,8 +234,7 @@ static vm_fault_t __dev_dax_pud_fault(st *pfn = phys_to_pfn_t(phys, dax_region->pfn_flags); - return vmf_insert_pfn_pud(vmf->vma, vmf->address, vmf->pud, *pfn, - vmf->flags & FAULT_FLAG_WRITE); + return vmf_insert_pfn_pud(vmf, *pfn, vmf->flags & FAULT_FLAG_WRITE); } #else static vm_fault_t __dev_dax_pud_fault(struct dev_dax *dev_dax, --- a/fs/dax.c~mm-huge_memory-fix-vmf_insert_pfn_pmd-pud-crash-handle-unaligned-addresses +++ a/fs/dax.c @@ -1575,8 +1575,7 @@ static vm_fault_t dax_iomap_pmd_fault(st } trace_dax_pmd_insert_mapping(inode, vmf, PMD_SIZE, pfn, entry); - result = vmf_insert_pfn_pmd(vma, vmf->address, vmf->pmd, pfn, - write); + result = vmf_insert_pfn_pmd(vmf, pfn, write); break; case IOMAP_UNWRITTEN: case IOMAP_HOLE: @@ -1686,8 +1685,7 @@ dax_insert_pfn_mkwrite(struct vm_fault * ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn); #ifdef CONFIG_FS_DAX_PMD else if (order == PMD_ORDER) - ret = vmf_insert_pfn_pmd(vmf->vma, vmf->address, vmf->pmd, - pfn, true); + ret = vmf_insert_pfn_pmd(vmf, pfn, FAULT_FLAG_WRITE); #endif else ret = VM_FAULT_FALLBACK; --- a/include/linux/huge_mm.h~mm-huge_memory-fix-vmf_insert_pfn_pmd-pud-crash-handle-unaligned-addresses +++ a/include/linux/huge_mm.h @@ -47,10 +47,8 @@ extern bool move_huge_pmd(struct vm_area extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, pgprot_t newprot, int prot_numa); -vm_fault_t vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr, - pmd_t *pmd, pfn_t pfn, bool write); -vm_fault_t vmf_insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr, - pud_t *pud, pfn_t pfn, bool write); +vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write); +vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write); enum transparent_hugepage_flag { TRANSPARENT_HUGEPAGE_FLAG, TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG, --- a/mm/huge_memory.c~mm-huge_memory-fix-vmf_insert_pfn_pmd-pud-crash-handle-unaligned-addresses +++ a/mm/huge_memory.c @@ -793,11 +793,13 @@ out_unlock: pte_free(mm, pgtable); } -vm_fault_t vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr, - pmd_t *pmd, pfn_t pfn, bool write) +vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) { + unsigned long addr = vmf->address & PMD_MASK; + struct vm_area_struct *vma = vmf->vma; pgprot_t pgprot = vma->vm_page_prot; pgtable_t pgtable = NULL; + /* * If we had pmd_special, we could avoid all these restrictions, * but we need to be consistent with PTEs and architectures that @@ -820,7 +822,7 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_ track_pfn_insert(vma, &pgprot, pfn); - insert_pfn_pmd(vma, addr, pmd, pfn, pgprot, write, pgtable); + insert_pfn_pmd(vma, addr, vmf->pmd, pfn, pgprot, write, pgtable); return VM_FAULT_NOPAGE; } EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd); @@ -869,10 +871,12 @@ out_unlock: spin_unlock(ptl); } -vm_fault_t vmf_insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr, - pud_t *pud, pfn_t pfn, bool write) +vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write) { + unsigned long addr = vmf->address & PUD_MASK; + struct vm_area_struct *vma = vmf->vma; pgprot_t pgprot = vma->vm_page_prot; + /* * If we had pud_special, we could avoid all these restrictions, * but we need to be consistent with PTEs and architectures that @@ -889,7 +893,7 @@ vm_fault_t vmf_insert_pfn_pud(struct vm_ track_pfn_insert(vma, &pgprot, pfn); - insert_pfn_pud(vma, addr, pud, pfn, pgprot, write); + insert_pfn_pud(vma, addr, vmf->pud, pfn, pgprot, write); return VM_FAULT_NOPAGE; } EXPORT_SYMBOL_GPL(vmf_insert_pfn_pud); _ Patches currently in -mm which might be from dan.j.williams(a)intel.com are mm-huge_memory-fix-vmf_insert_pfn_pmd-pud-crash-handle-unaligned-addresses.patch mm-shuffle-initial-free-memory-to-improve-memory-side-cache-utilization.patch mm-shuffle-initial-free-memory-to-improve-memory-side-cache-utilization-fix.patch mm-move-buddy-list-manipulations-into-helpers.patch mm-move-buddy-list-manipulations-into-helpers-fix.patch mm-maintain-randomization-of-page-free-lists.patch

5 years, 9 months

1
0
0 0

[PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush

by Yang Shi

A few new fields were added to mmu_gather to make TLB flush smarter for huge page by telling what level of page table is changed. __tlb_reset_range() is used to reset all these page table state to unchanged, which is called by TLB flush for parallel mapping changes for the same range under non-exclusive lock (i.e. read mmap_sem). Before commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"), MADV_DONTNEED is the only one who may do page zapping in parallel and it doesn't remove page tables. But, the forementioned commit may do munmap() under read mmap_sem and free page tables. This causes a bug [1] reported by Jan Stancek since __tlb_reset_range() may pass the wrong page table state to architecture specific TLB flush operations. So, removing __tlb_reset_range() sounds sane. This may cause more TLB flush for MADV_DONTNEED, but it should be not called very often, hence the impact should be negligible. The original proposed fix came from Jan Stancek who mainly debugged this issue, I just wrapped up everything together. [1] https://lore.kernel.org/linux-mm/342bf1fd-f1bf-ed62-1127-e911b5032274@linux… Reported-by: Jan Stancek <jstancek(a)redhat.com> Tested-by: Jan Stancek <jstancek(a)redhat.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: stable(a)vger.kernel.org Signed-off-by: Yang Shi <yang.shi(a)linux.alibaba.com> Signed-off-by: Jan Stancek <jstancek(a)redhat.com> --- mm/mmu_gather.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c index 99740e1..9fd5272 100644 --- a/mm/mmu_gather.c +++ b/mm/mmu_gather.c @@ -249,11 +249,12 @@ void tlb_finish_mmu(struct mmu_gather *tlb, * flush by batching, a thread has stable TLB entry can fail to flush * the TLB by observing pte_none|!pte_dirty, for example so flush TLB * forcefully if we detect parallel PTE batching threads. + * + * munmap() may change mapping under non-excluse lock and also free + * page tables. Do not call __tlb_reset_range() for it. */ - if (mm_tlb_flush_nested(tlb->mm)) { - __tlb_reset_range(tlb); + if (mm_tlb_flush_nested(tlb->mm)) __tlb_adjust_range(tlb, start, end - start); - } tlb_flush_mmu(tlb); -- 1.8.3.1

5 years, 9 months

5
14
0 0

✅ PASS: Test report for kernel 4.19.42-rc1-bea1e73.cki (stable)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 82fd2fd59cff - Linux 4.19.42-rc1 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/kernel-stable-aarch64-82fd… kernel build: https://artifacts.cki-project.org/builds/aarch64/kernel-stable-aarch64-82fd… ppc64le: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable-ppc64le-82fd… kernel build: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable-ppc64le-82fd… s390x: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/s390x/kernel-stable-s390x-82fd2fd5… kernel build: https://artifacts.cki-project.org/builds/s390x/kernel-stable-s390x-82fd2fd5… x86_64: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/kernel-stable-x86_64-82fd2f… kernel build: https://artifacts.cki-project.org/builds/x86_64/kernel-stable-x86_64-82fd2f… Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ AMTU (Abstract Machine Test Utility) [4] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] ✅ Boot test [0] ✅ xfstests: ext4 [13] ✅ xfstests: xfs [13] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] 🚧 ✅ selinux-policy: serge-testsuite [18] ppc64le: ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ AMTU (Abstract Machine Test Utility) [4] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] ✅ Boot test [0] ✅ xfstests: ext4 [13] ✅ xfstests: xfs [13] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] 🚧 ✅ selinux-policy: serge-testsuite [18] s390x: ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] ✅ Boot test [0] ✅ Boot test [0] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] 🚧 ✅ kdump: sysrq-c [19] 🚧 ✅ selinux-policy: serge-testsuite [18] x86_64: ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ AMTU (Abstract Machine Test Utility) [4] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] ✅ Boot test [0] ✅ Boot test [0] ✅ xfstests: ext4 [13] ✅ xfstests: xfs [13] ✅ Boot test [0] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] 🚧 ✅ kdump: sysrq-c [19] 🚧 ✅ selinux-policy: serge-testsuite [18] 🚧 ✅ kdump: sysrq-c - megaraid_sas [19] Test source: [0]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [1]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [2]: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/memory/func… [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/red… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/red… [10]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [11]: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… [12]: https://github.com/CKI-project/tests-beaker/archive/master.zip#storage/lvm/… [13]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… [14]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [15]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [16]: https://github.com/CKI-project/tests-beaker/archive/master.zip#storage/blk [17]: https://github.com/CKI-project/tests-beaker/archive/master.zip#stress/stres… [18]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/packages/se… [19]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/kdump/kdump… Waived tests (marked with 🚧) ----------------------------- This test run included waived tests. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed.

5 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2019