* simplify follow_pte a bit
@ 2020-10-29 10:14 Christoph Hellwig
2020-10-29 10:14 ` [PATCH 1/2] mm: unexport follow_pte_pmd Christoph Hellwig
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Christoph Hellwig @ 2020-10-29 10:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Dan Williams, Daniel Vetter, linux-nvdimm, linux-kernel, linux-mm
Hi Andrew,
this small series drops the not needed follow_pte_pmd exports, and
simplifies the follow_pte family of functions a bit.
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH 1/2] mm: unexport follow_pte_pmd 2020-10-29 10:14 simplify follow_pte a bit Christoph Hellwig @ 2020-10-29 10:14 ` Christoph Hellwig 2020-11-10 18:32 ` Matthew Wilcox 2020-10-29 10:14 ` [PATCH 2/2] mm: simplify follow_pte{,pmd} Christoph Hellwig 2020-11-10 18:26 ` simplify follow_pte a bit Christoph Hellwig 2 siblings, 1 reply; 11+ messages in thread From: Christoph Hellwig @ 2020-10-29 10:14 UTC (permalink / raw) To: Andrew Morton Cc: Dan Williams, Daniel Vetter, linux-nvdimm, linux-kernel, linux-mm follow_pte_pmd is only used by the DAX code, which can't be modular. Signed-off-by: Christoph Hellwig <hch@lst.de> --- mm/memory.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/memory.c b/mm/memory.c index c48f8df6e50268..00458e7b49fef8 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4787,7 +4787,6 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long address, ptepp, pmdpp, ptlp))); return res; } -EXPORT_SYMBOL(follow_pte_pmd); /** * follow_pfn - look up PFN at a user virtual address -- 2.28.0 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] mm: unexport follow_pte_pmd 2020-10-29 10:14 ` [PATCH 1/2] mm: unexport follow_pte_pmd Christoph Hellwig @ 2020-11-10 18:32 ` Matthew Wilcox 0 siblings, 0 replies; 11+ messages in thread From: Matthew Wilcox @ 2020-11-10 18:32 UTC (permalink / raw) To: Christoph Hellwig Cc: Andrew Morton, Dan Williams, Daniel Vetter, linux-nvdimm, linux-kernel, linux-mm On Thu, Oct 29, 2020 at 11:14:31AM +0100, Christoph Hellwig wrote: > follow_pte_pmd is only used by the DAX code, which can't be modular. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] mm: simplify follow_pte{,pmd} 2020-10-29 10:14 simplify follow_pte a bit Christoph Hellwig 2020-10-29 10:14 ` [PATCH 1/2] mm: unexport follow_pte_pmd Christoph Hellwig @ 2020-10-29 10:14 ` Christoph Hellwig 2020-11-10 18:42 ` Matthew Wilcox 2020-11-11 2:21 ` Nick Desaulniers 2020-11-10 18:26 ` simplify follow_pte a bit Christoph Hellwig 2 siblings, 2 replies; 11+ messages in thread From: Christoph Hellwig @ 2020-10-29 10:14 UTC (permalink / raw) To: Andrew Morton Cc: Dan Williams, Daniel Vetter, linux-nvdimm, linux-kernel, linux-mm Merge __follow_pte_pmd, follow_pte_pmd and follow_pte into a single follow_pte function and just pass two additional NULL arguments for the two previous follow_pte callers. Signed-off-by: Christoph Hellwig <hch@lst.de> --- fs/dax.c | 9 ++++----- include/linux/mm.h | 6 +++--- mm/memory.c | 35 +++++------------------------------ 3 files changed, 12 insertions(+), 38 deletions(-) diff --git a/fs/dax.c b/fs/dax.c index 5b47834f2e1bb5..26d5dcd2d69e5c 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -810,12 +810,11 @@ static void dax_entry_mkclean(struct address_space *mapping, pgoff_t index, address = pgoff_address(index, vma); /* - * Note because we provide range to follow_pte_pmd it will - * call mmu_notifier_invalidate_range_start() on our behalf - * before taking any lock. + * Note because we provide range to follow_pte it will call + * mmu_notifier_invalidate_range_start() on our behalf before + * taking any lock. */ - if (follow_pte_pmd(vma->vm_mm, address, &range, - &ptep, &pmdp, &ptl)) + if (follow_pte(vma->vm_mm, address, &range, &ptep, &pmdp, &ptl)) continue; /* diff --git a/include/linux/mm.h b/include/linux/mm.h index ef360fe70aafcf..113b0b4fd90af5 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1655,9 +1655,9 @@ void free_pgd_range(struct mmu_gather *tlb, unsigned long addr, unsigned long end, unsigned long floor, unsigned long ceiling); int copy_page_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma); -int follow_pte_pmd(struct mm_struct *mm, unsigned long address, - struct mmu_notifier_range *range, - pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp); +int follow_pte(struct mm_struct *mm, unsigned long address, + struct mmu_notifier_range *range, pte_t **ptepp, pmd_t **pmdpp, + spinlock_t **ptlp); int follow_pfn(struct vm_area_struct *vma, unsigned long address, unsigned long *pfn); int follow_phys(struct vm_area_struct *vma, unsigned long address, diff --git a/mm/memory.c b/mm/memory.c index 00458e7b49fef8..fa00682f7a4312 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4696,9 +4696,9 @@ int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address) } #endif /* __PAGETABLE_PMD_FOLDED */ -static int __follow_pte_pmd(struct mm_struct *mm, unsigned long address, - struct mmu_notifier_range *range, - pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp) +int follow_pte(struct mm_struct *mm, unsigned long address, + struct mmu_notifier_range *range, pte_t **ptepp, pmd_t **pmdpp, + spinlock_t **ptlp) { pgd_t *pgd; p4d_t *p4d; @@ -4763,31 +4763,6 @@ static int __follow_pte_pmd(struct mm_struct *mm, unsigned long address, return -EINVAL; } -static inline int follow_pte(struct mm_struct *mm, unsigned long address, - pte_t **ptepp, spinlock_t **ptlp) -{ - int res; - - /* (void) is needed to make gcc happy */ - (void) __cond_lock(*ptlp, - !(res = __follow_pte_pmd(mm, address, NULL, - ptepp, NULL, ptlp))); - return res; -} - -int follow_pte_pmd(struct mm_struct *mm, unsigned long address, - struct mmu_notifier_range *range, - pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp) -{ - int res; - - /* (void) is needed to make gcc happy */ - (void) __cond_lock(*ptlp, - !(res = __follow_pte_pmd(mm, address, range, - ptepp, pmdpp, ptlp))); - return res; -} - /** * follow_pfn - look up PFN at a user virtual address * @vma: memory mapping @@ -4808,7 +4783,7 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long address, if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) return ret; - ret = follow_pte(vma->vm_mm, address, &ptep, &ptl); + ret = follow_pte(vma->vm_mm, address, NULL, &ptep, NULL, &ptl); if (ret) return ret; *pfn = pte_pfn(*ptep); @@ -4829,7 +4804,7 @@ int follow_phys(struct vm_area_struct *vma, if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) goto out; - if (follow_pte(vma->vm_mm, address, &ptep, &ptl)) + if (follow_pte(vma->vm_mm, address, NULL, &ptep, NULL, &ptl)) goto out; pte = *ptep; -- 2.28.0 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] mm: simplify follow_pte{,pmd} 2020-10-29 10:14 ` [PATCH 2/2] mm: simplify follow_pte{,pmd} Christoph Hellwig @ 2020-11-10 18:42 ` Matthew Wilcox 2020-11-11 2:21 ` Nick Desaulniers 1 sibling, 0 replies; 11+ messages in thread From: Matthew Wilcox @ 2020-11-10 18:42 UTC (permalink / raw) To: Christoph Hellwig Cc: Andrew Morton, Dan Williams, Daniel Vetter, linux-nvdimm, linux-kernel, linux-mm On Thu, Oct 29, 2020 at 11:14:32AM +0100, Christoph Hellwig wrote: > Merge __follow_pte_pmd, follow_pte_pmd and follow_pte into a single > follow_pte function and just pass two additional NULL arguments for > the two previous follow_pte callers. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> I'm not entirely convinced this is the right interface, but your patch makes things better, so I approve. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] mm: simplify follow_pte{,pmd} 2020-10-29 10:14 ` [PATCH 2/2] mm: simplify follow_pte{,pmd} Christoph Hellwig 2020-11-10 18:42 ` Matthew Wilcox @ 2020-11-11 2:21 ` Nick Desaulniers 2020-11-11 8:18 ` Christoph Hellwig 1 sibling, 1 reply; 11+ messages in thread From: Nick Desaulniers @ 2020-11-11 2:21 UTC (permalink / raw) To: hch Cc: akpm, dan.j.williams, daniel, linux-kernel, linux-mm, linux-nvdimm, Heiko Carstens, Vasily Gorbik, Christian Borntraeger, clang-built-linux Sorry, I think this patch may be causing a regression for us for s390? https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/432129279#L768 (via https://lore.kernel.org/linux-mm/20201029101432.47011-3-hch@lst.de) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] mm: simplify follow_pte{,pmd} 2020-11-11 2:21 ` Nick Desaulniers @ 2020-11-11 8:18 ` Christoph Hellwig 2020-11-11 8:26 ` Christian Borntraeger 0 siblings, 1 reply; 11+ messages in thread From: Christoph Hellwig @ 2020-11-11 8:18 UTC (permalink / raw) To: Nick Desaulniers Cc: hch, akpm, dan.j.williams, daniel, linux-kernel, linux-mm, linux-nvdimm, Heiko Carstens, Vasily Gorbik, Christian Borntraeger, clang-built-linux On Tue, Nov 10, 2020 at 06:21:22PM -0800, Nick Desaulniers wrote: > Sorry, I think this patch may be causing a regression for us for s390? > https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/432129279#L768 > > (via https://lore.kernel.org/linux-mm/20201029101432.47011-3-hch@lst.de) Hmm, the call to follow_pte_pmd in the s390 code does not actually exist in my tree. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] mm: simplify follow_pte{,pmd} 2020-11-11 8:18 ` Christoph Hellwig @ 2020-11-11 8:26 ` Christian Borntraeger 2020-11-11 8:28 ` Christoph Hellwig 0 siblings, 1 reply; 11+ messages in thread From: Christian Borntraeger @ 2020-11-11 8:26 UTC (permalink / raw) To: Christoph Hellwig, Nick Desaulniers Cc: akpm, dan.j.williams, daniel, linux-kernel, linux-mm, linux-nvdimm, Heiko Carstens, Vasily Gorbik, clang-built-linux, Linux-Next Mailing List On 11.11.20 09:18, Christoph Hellwig wrote: > On Tue, Nov 10, 2020 at 06:21:22PM -0800, Nick Desaulniers wrote: >> Sorry, I think this patch may be causing a regression for us for s390? >> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/432129279#L768 >> >> (via https://lore.kernel.org/linux-mm/20201029101432.47011-3-hch@lst.de) > > Hmm, the call to follow_pte_pmd in the s390 code does not actually exist > in my tree. This is a mid-air collision in linux-next between b2ff5796a934 ("mm: simplify follow_pte{,pmd}") a67a88b0b8de ("s390/pci: remove races against pte updates") ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] mm: simplify follow_pte{,pmd} 2020-11-11 8:26 ` Christian Borntraeger @ 2020-11-11 8:28 ` Christoph Hellwig 2020-11-11 11:12 ` Stephen Rothwell 0 siblings, 1 reply; 11+ messages in thread From: Christoph Hellwig @ 2020-11-11 8:28 UTC (permalink / raw) To: Christian Borntraeger Cc: Christoph Hellwig, Nick Desaulniers, akpm, dan.j.williams, daniel, linux-kernel, linux-mm, linux-nvdimm, Heiko Carstens, Vasily Gorbik, clang-built-linux, Linux-Next Mailing List On Wed, Nov 11, 2020 at 09:26:20AM +0100, Christian Borntraeger wrote: > > On 11.11.20 09:18, Christoph Hellwig wrote: > > On Tue, Nov 10, 2020 at 06:21:22PM -0800, Nick Desaulniers wrote: > >> Sorry, I think this patch may be causing a regression for us for s390? > >> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/432129279#L768 > >> > >> (via https://lore.kernel.org/linux-mm/20201029101432.47011-3-hch@lst.de) > > > > Hmm, the call to follow_pte_pmd in the s390 code does not actually exist > > in my tree. > > This is a mid-air collision in linux-next between > > b2ff5796a934 ("mm: simplify follow_pte{,pmd}") > a67a88b0b8de ("s390/pci: remove races against pte updates") Ah. The fixup is trivial: just s/follow_pte_pmd/follow_pte/. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] mm: simplify follow_pte{,pmd} 2020-11-11 8:28 ` Christoph Hellwig @ 2020-11-11 11:12 ` Stephen Rothwell 0 siblings, 0 replies; 11+ messages in thread From: Stephen Rothwell @ 2020-11-11 11:12 UTC (permalink / raw) To: Christoph Hellwig Cc: Christian Borntraeger, Nick Desaulniers, akpm, dan.j.williams, daniel, linux-kernel, linux-mm, linux-nvdimm, Heiko Carstens, Vasily Gorbik, clang-built-linux, Linux-Next Mailing List [-- Attachment #1: Type: text/plain, Size: 2211 bytes --] Hi Christoph, On Wed, 11 Nov 2020 09:28:42 +0100 Christoph Hellwig <hch@lst.de> wrote: > > On Wed, Nov 11, 2020 at 09:26:20AM +0100, Christian Borntraeger wrote: > > > > On 11.11.20 09:18, Christoph Hellwig wrote: > > > On Tue, Nov 10, 2020 at 06:21:22PM -0800, Nick Desaulniers wrote: > > >> Sorry, I think this patch may be causing a regression for us for s390? > > >> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/432129279#L768 > > >> > > >> (via https://lore.kernel.org/linux-mm/20201029101432.47011-3-hch@lst.de) > > > > > > Hmm, the call to follow_pte_pmd in the s390 code does not actually exist > > > in my tree. > > > > This is a mid-air collision in linux-next between > > > > b2ff5796a934 ("mm: simplify follow_pte{,pmd}") > > a67a88b0b8de ("s390/pci: remove races against pte updates") > > Ah. The fixup is trivial: just s/follow_pte_pmd/follow_pte/. ok, so tomorrow I will add the following to the merge of the akpm-current tree: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 11 Nov 2020 22:08:32 +1100 Subject: [PATCH] merge fix for "s390/pci: remove races against pte updates" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/s390/pci/pci_mmio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c index 1a6adbc68ee8..4a4993837413 100644 --- a/arch/s390/pci/pci_mmio.c +++ b/arch/s390/pci/pci_mmio.c @@ -173,7 +173,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr, if (!(vma->vm_flags & VM_WRITE)) goto out_unlock_mmap; - ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); + ret = follow_pte(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); if (ret) goto out_unlock_mmap; @@ -317,7 +317,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr, if (!(vma->vm_flags & VM_WRITE)) goto out_unlock_mmap; - ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); + ret = follow_pte(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); if (ret) goto out_unlock_mmap; -- 2.29.2 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: simplify follow_pte a bit 2020-10-29 10:14 simplify follow_pte a bit Christoph Hellwig 2020-10-29 10:14 ` [PATCH 1/2] mm: unexport follow_pte_pmd Christoph Hellwig 2020-10-29 10:14 ` [PATCH 2/2] mm: simplify follow_pte{,pmd} Christoph Hellwig @ 2020-11-10 18:26 ` Christoph Hellwig 2 siblings, 0 replies; 11+ messages in thread From: Christoph Hellwig @ 2020-11-10 18:26 UTC (permalink / raw) To: Andrew Morton Cc: Dan Williams, Daniel Vetter, linux-nvdimm, linux-kernel, linux-mm On Thu, Oct 29, 2020 at 11:14:30AM +0100, Christoph Hellwig wrote: > Hi Andrew, > > this small series drops the not needed follow_pte_pmd exports, and > simplifies the follow_pte family of functions a bit. any comments? ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-11-11 11:13 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-29 10:14 simplify follow_pte a bit Christoph Hellwig
2020-10-29 10:14 ` [PATCH 1/2] mm: unexport follow_pte_pmd Christoph Hellwig
2020-11-10 18:32 ` Matthew Wilcox
2020-10-29 10:14 ` [PATCH 2/2] mm: simplify follow_pte{,pmd} Christoph Hellwig
2020-11-10 18:42 ` Matthew Wilcox
2020-11-11 2:21 ` Nick Desaulniers
2020-11-11 8:18 ` Christoph Hellwig
2020-11-11 8:26 ` Christian Borntraeger
2020-11-11 8:28 ` Christoph Hellwig
2020-11-11 11:12 ` Stephen Rothwell
2020-11-10 18:26 ` simplify follow_pte a bit Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).