| Message ID | 400a4584f6f628998a7093aee49d9f86c592754b.1719386613.git-series.apopple@nvidia.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | fs/dax: Fix FS DAX page reference counts | expand |
Hi, Alistair, On Thu, Jun 27, 2024 at 10:54:26AM +1000, Alistair Popple wrote: > Now that DAX is managing page reference counts the same as normal > pages there are no callers for vmf_insert_pXd functions so remove > them. > > Signed-off-by: Alistair Popple <apopple@nvidia.com> > --- > include/linux/huge_mm.h | 2 +- > mm/huge_memory.c | 165 +----------------------------------------- > 2 files changed, 167 deletions(-) > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index 9207d8e..0fb6bff 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -37,8 +37,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > pmd_t *pmd, unsigned long addr, pgprot_t newprot, > unsigned long cp_flags); > > -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); > vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write); > vm_fault_t dax_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write); There's a plan to support huge pfnmaps in VFIO, which may still make good use of these functions. I think it's fine to remove them but it may mean we'll need to add them back when supporting pfnmaps with no memmap. Is it still possible to make the old API generic to both service the new dax refcount plan, but at the meantime working for pfn injections when there's no page struct? Thanks,
Peter Xu <peterx@redhat.com> writes: > Hi, Alistair, > > On Thu, Jun 27, 2024 at 10:54:26AM +1000, Alistair Popple wrote: >> Now that DAX is managing page reference counts the same as normal >> pages there are no callers for vmf_insert_pXd functions so remove >> them. >> >> Signed-off-by: Alistair Popple <apopple@nvidia.com> >> --- >> include/linux/huge_mm.h | 2 +- >> mm/huge_memory.c | 165 +----------------------------------------- >> 2 files changed, 167 deletions(-) >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >> index 9207d8e..0fb6bff 100644 >> --- a/include/linux/huge_mm.h >> +++ b/include/linux/huge_mm.h >> @@ -37,8 +37,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, >> pmd_t *pmd, unsigned long addr, pgprot_t newprot, >> unsigned long cp_flags); >> >> -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); >> vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write); >> vm_fault_t dax_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write); > > There's a plan to support huge pfnmaps in VFIO, which may still make good > use of these functions. I think it's fine to remove them but it may mean > we'll need to add them back when supporting pfnmaps with no memmap. I'm ok with that. If we need them back in future it shouldn't be too hard to add them back again. I just couldn't find any callers of them once DAX stopped using them and the usual policy is to remove unused functions. > Is it still possible to make the old API generic to both service the new > dax refcount plan, but at the meantime working for pfn injections when > there's no page struct? I don't think so - this new dax refcount plan relies on having a struct page to take references on so I don't think it makes much sense to combine it with something that doesn't have a struct page. It sounds like the situation is the analogue of vm_insert_page() vs. vmf_insert_pfn() - it's possible for both to exist but there's not really anything that can be shared between the two APIs as one has a page and the other is just a raw PFN. > Thanks,
On Tue, Jul 09, 2024 at 02:07:31PM +1000, Alistair Popple wrote: > > Peter Xu <peterx@redhat.com> writes: > > > Hi, Alistair, > > > > On Thu, Jun 27, 2024 at 10:54:26AM +1000, Alistair Popple wrote: > >> Now that DAX is managing page reference counts the same as normal > >> pages there are no callers for vmf_insert_pXd functions so remove > >> them. > >> > >> Signed-off-by: Alistair Popple <apopple@nvidia.com> > >> --- > >> include/linux/huge_mm.h | 2 +- > >> mm/huge_memory.c | 165 +----------------------------------------- > >> 2 files changed, 167 deletions(-) > >> > >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > >> index 9207d8e..0fb6bff 100644 > >> --- a/include/linux/huge_mm.h > >> +++ b/include/linux/huge_mm.h > >> @@ -37,8 +37,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > >> pmd_t *pmd, unsigned long addr, pgprot_t newprot, > >> unsigned long cp_flags); > >> > >> -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); > >> vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write); > >> vm_fault_t dax_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write); > > > > There's a plan to support huge pfnmaps in VFIO, which may still make good > > use of these functions. I think it's fine to remove them but it may mean > > we'll need to add them back when supporting pfnmaps with no memmap. > > I'm ok with that. If we need them back in future it shouldn't be too > hard to add them back again. I just couldn't find any callers of them > once DAX stopped using them and the usual policy is to remove unused > functions. True. Currently the pmd/pud helpers are only used in dax. > > > Is it still possible to make the old API generic to both service the new > > dax refcount plan, but at the meantime working for pfn injections when > > there's no page struct? > > I don't think so - this new dax refcount plan relies on having a struct > page to take references on so I don't think it makes much sense to > combine it with something that doesn't have a struct page. It sounds > like the situation is the analogue of vm_insert_page() > vs. vmf_insert_pfn() - it's possible for both to exist but there's not > really anything that can be shared between the two APIs as one has a > page and the other is just a raw PFN. I still think most of the codes should be shared on e.g. most of sanity checks, pgtable injections, pgtable deposits (for pmd) and so on. To be explicit, I wonder whether something like below diff would be applicable on top of the patch "huge_memory: Allow mappings of PMD sized pages" in this series, which introduced dax_insert_pfn_pmd() for dax: $ diff origin new 1c1 < vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) --- > vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) 55,58c55,60 < folio = page_folio(page); < folio_get(folio); < folio_add_file_rmap_pmd(folio, page, vma); < add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR); --- > if (page) { > folio = page_folio(page); > folio_get(folio); > folio_add_file_rmap_pmd(folio, page, vma); > add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR); > } As most of the rest look very similar to what pfn injections would need.. and in the PoC of ours we're using vmf_insert_pfn_pmd/pud(). That also reminds me on whether it'll be easier to implement the new dax support for page struct on top of vmf_insert_pfn_pmd/pud, rather than removing the 1st then adding the new one. Maybe it'll reduce code churns, and would that also make reviews easier? It's also possible I missed something important so the old function must be removed. Thanks,
Peter Xu <peterx@redhat.com> writes: > On Tue, Jul 09, 2024 at 02:07:31PM +1000, Alistair Popple wrote: >> >> Peter Xu <peterx@redhat.com> writes: >> >> > Hi, Alistair, >> > >> > On Thu, Jun 27, 2024 at 10:54:26AM +1000, Alistair Popple wrote: >> >> Now that DAX is managing page reference counts the same as normal >> >> pages there are no callers for vmf_insert_pXd functions so remove >> >> them. >> >> >> >> Signed-off-by: Alistair Popple <apopple@nvidia.com> >> >> --- >> >> include/linux/huge_mm.h | 2 +- >> >> mm/huge_memory.c | 165 +----------------------------------------- >> >> 2 files changed, 167 deletions(-) >> >> >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >> >> index 9207d8e..0fb6bff 100644 >> >> --- a/include/linux/huge_mm.h >> >> +++ b/include/linux/huge_mm.h >> >> @@ -37,8 +37,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, >> >> pmd_t *pmd, unsigned long addr, pgprot_t newprot, >> >> unsigned long cp_flags); >> >> >> >> -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); >> >> vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write); >> >> vm_fault_t dax_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write); >> > >> > There's a plan to support huge pfnmaps in VFIO, which may still make good >> > use of these functions. I think it's fine to remove them but it may mean >> > we'll need to add them back when supporting pfnmaps with no memmap. >> >> I'm ok with that. If we need them back in future it shouldn't be too >> hard to add them back again. I just couldn't find any callers of them >> once DAX stopped using them and the usual policy is to remove unused >> functions. > > True. Currently the pmd/pud helpers are only used in dax. > >> >> > Is it still possible to make the old API generic to both service the new >> > dax refcount plan, but at the meantime working for pfn injections when >> > there's no page struct? >> >> I don't think so - this new dax refcount plan relies on having a struct >> page to take references on so I don't think it makes much sense to >> combine it with something that doesn't have a struct page. It sounds >> like the situation is the analogue of vm_insert_page() >> vs. vmf_insert_pfn() - it's possible for both to exist but there's not >> really anything that can be shared between the two APIs as one has a >> page and the other is just a raw PFN. > > I still think most of the codes should be shared on e.g. most of sanity > checks, pgtable injections, pgtable deposits (for pmd) and so on. Yeah, it was mostly the BUG_ON's that weren't applicable once pXd_devmap went away. > To be explicit, I wonder whether something like below diff would be > applicable on top of the patch "huge_memory: Allow mappings of PMD sized > pages" in this series, which introduced dax_insert_pfn_pmd() for dax: > > $ diff origin new > 1c1 > < vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) > --- >> vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) > 55,58c55,60 > < folio = page_folio(page); > < folio_get(folio); > < folio_add_file_rmap_pmd(folio, page, vma); > < add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR); > --- >> if (page) { >> folio = page_folio(page); >> folio_get(folio); >> folio_add_file_rmap_pmd(folio, page, vma); >> add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR); >> } We get the page from calling pfn_t_to_page(pfn). This is safe for the DAX case but is it safe to use a page returned by this more generally? From an API perspective it would make more sense for the DAX code to pass the page rather than the pfn. I didn't do that because device DAX just had the PFN and this was DAX-specific code. But if we want to make it generic I'd rather have callers pass the page in. Of course that probably doesn't help you, because then the call would be vmf_insert_page_pmd() rather than a raw pfn, but as you point out there might be some common code we could share. > > As most of the rest look very similar to what pfn injections would need.. > and in the PoC of ours we're using vmf_insert_pfn_pmd/pud(). Do you have the PoC posted anywhere so I can get an understanding of how this might be used? > That also reminds me on whether it'll be easier to implement the new dax > support for page struct on top of vmf_insert_pfn_pmd/pud, rather than > removing the 1st then adding the new one. Maybe it'll reduce code churns, > and would that also make reviews easier? Yeah, that's a good observation. I think it was just a quirk of how I was developing this and also not caring about the PFN case so I'll see what that looks like. > It's also possible I missed something important so the old function must be > removed. > > Thanks,
On Fri, Jul 12, 2024 at 12:40:39PM +1000, Alistair Popple wrote: > > Peter Xu <peterx@redhat.com> writes: > > > On Tue, Jul 09, 2024 at 02:07:31PM +1000, Alistair Popple wrote: > >> > >> Peter Xu <peterx@redhat.com> writes: > >> > >> > Hi, Alistair, > >> > > >> > On Thu, Jun 27, 2024 at 10:54:26AM +1000, Alistair Popple wrote: > >> >> Now that DAX is managing page reference counts the same as normal > >> >> pages there are no callers for vmf_insert_pXd functions so remove > >> >> them. > >> >> > >> >> Signed-off-by: Alistair Popple <apopple@nvidia.com> > >> >> --- > >> >> include/linux/huge_mm.h | 2 +- > >> >> mm/huge_memory.c | 165 +----------------------------------------- > >> >> 2 files changed, 167 deletions(-) > >> >> > >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > >> >> index 9207d8e..0fb6bff 100644 > >> >> --- a/include/linux/huge_mm.h > >> >> +++ b/include/linux/huge_mm.h > >> >> @@ -37,8 +37,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > >> >> pmd_t *pmd, unsigned long addr, pgprot_t newprot, > >> >> unsigned long cp_flags); > >> >> > >> >> -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); > >> >> vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write); > >> >> vm_fault_t dax_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write); > >> > > >> > There's a plan to support huge pfnmaps in VFIO, which may still make good > >> > use of these functions. I think it's fine to remove them but it may mean > >> > we'll need to add them back when supporting pfnmaps with no memmap. > >> > >> I'm ok with that. If we need them back in future it shouldn't be too > >> hard to add them back again. I just couldn't find any callers of them > >> once DAX stopped using them and the usual policy is to remove unused > >> functions. > > > > True. Currently the pmd/pud helpers are only used in dax. > > > >> > >> > Is it still possible to make the old API generic to both service the new > >> > dax refcount plan, but at the meantime working for pfn injections when > >> > there's no page struct? > >> > >> I don't think so - this new dax refcount plan relies on having a struct > >> page to take references on so I don't think it makes much sense to > >> combine it with something that doesn't have a struct page. It sounds > >> like the situation is the analogue of vm_insert_page() > >> vs. vmf_insert_pfn() - it's possible for both to exist but there's not > >> really anything that can be shared between the two APIs as one has a > >> page and the other is just a raw PFN. > > > > I still think most of the codes should be shared on e.g. most of sanity > > checks, pgtable injections, pgtable deposits (for pmd) and so on. > > Yeah, it was mostly the BUG_ON's that weren't applicable once pXd_devmap > went away. > > > To be explicit, I wonder whether something like below diff would be > > applicable on top of the patch "huge_memory: Allow mappings of PMD sized > > pages" in this series, which introduced dax_insert_pfn_pmd() for dax: > > > > $ diff origin new > > 1c1 > > < vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) > > --- > >> vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) > > 55,58c55,60 > > < folio = page_folio(page); > > < folio_get(folio); > > < folio_add_file_rmap_pmd(folio, page, vma); > > < add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR); > > --- > >> if (page) { > >> folio = page_folio(page); > >> folio_get(folio); > >> folio_add_file_rmap_pmd(folio, page, vma); > >> add_mm_counter(mm, mm_counter_file(folio), HPAGE_PMD_NR); > >> } > > We get the page from calling pfn_t_to_page(pfn). This is safe for the > DAX case but is it safe to use a page returned by this more generally? Good question. I thought it should work when the caller doesn't set any bit in PFN_FLAGS_MASK, but it turns out it's not the case? As I just notice: static inline bool pfn_t_has_page(pfn_t pfn) { return (pfn.val & PFN_MAP) == PFN_MAP || (pfn.val & PFN_DEV) == 0; } So it looks like "no PFN_FLAGS" case should also fall into this category of "(pfn.val & PFN_DEV) == 0".. I'm not sure whether my understanding is correct, though. Maybe we'd want to double check with pfn_valid() when it's a generic function. > > From an API perspective it would make more sense for the DAX code to > pass the page rather than the pfn. I didn't do that because device DAX > just had the PFN and this was DAX-specific code. But if we want to make > it generic I'd rather have callers pass the page in. > > Of course that probably doesn't help you, because then the call would be > vmf_insert_page_pmd() rather than a raw pfn, but as you point out there > might be some common code we could share. It'll be fine if it needs page*, then it'll be NULL for VFIO. So far it looks cleaner if it has the pgtable entry anyway to me, as that indeed contains the pfn. But I'd trust you more on what should it look like, as I didn't read the whole series here. > > > > > As most of the rest look very similar to what pfn injections would need.. > > and in the PoC of ours we're using vmf_insert_pfn_pmd/pud(). > > Do you have the PoC posted anywhere so I can get an understanding of how > this might be used? https://github.com/xzpeter/linux/commits/vfio-pfnmap-all/ Specifically Alex's commit here: https://github.com/xzpeter/linux/commit/afd05f1082bc78738e280f1fc1937da52b2572ed Just a note that it's still work in progress. Alex did run it through (not this tree, but an older one) and it works pretty well so far. I think it's because so far nothing involves the pfn flags, the only one has it involved is (taking pmd as example): insert_pfn_pmd(): if (!pmd_none(*pmd)) { if (write) { if (pmd_pfn(*pmd) != pfn_t_to_pfn(pfn)) { WARN_ON_ONCE(!is_huge_zero_pmd(*pmd)); goto out_unlock; } entry = pmd_mkyoung(*pmd); entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); if (pmdp_set_access_flags(vma, addr, pmd, entry, 1)) update_mmu_cache_pmd(vma, addr, pmd); } goto out_unlock; } But for VFIO it'll definitely be pmd_none() here, so the whole path ignores pfn flags so far here, I assume. > > > That also reminds me on whether it'll be easier to implement the new dax > > support for page struct on top of vmf_insert_pfn_pmd/pud, rather than > > removing the 1st then adding the new one. Maybe it'll reduce code churns, > > and would that also make reviews easier? > > Yeah, that's a good observation. I think it was just a quirk of how I > was developing this and also not caring about the PFN case so I'll see > what that looks like. Great! I hope it'll reduce the diff for this series too, so it could be a win-win. Thanks,
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index 9207d8e..0fb6bff 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -37,8 +37,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, pgprot_t newprot, unsigned long cp_flags); -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); vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write); vm_fault_t dax_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write); diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 5191f91..de39af4 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1111,97 +1111,6 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf) return __do_huge_pmd_anonymous_page(vmf, &folio->page, gfp); } -static void insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr, - pmd_t *pmd, pfn_t pfn, pgprot_t prot, bool write, - pgtable_t pgtable) -{ - struct mm_struct *mm = vma->vm_mm; - pmd_t entry; - spinlock_t *ptl; - - ptl = pmd_lock(mm, pmd); - if (!pmd_none(*pmd)) { - if (write) { - if (pmd_pfn(*pmd) != pfn_t_to_pfn(pfn)) { - WARN_ON_ONCE(!is_huge_zero_pmd(*pmd)); - goto out_unlock; - } - entry = pmd_mkyoung(*pmd); - entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); - if (pmdp_set_access_flags(vma, addr, pmd, entry, 1)) - update_mmu_cache_pmd(vma, addr, pmd); - } - - goto out_unlock; - } - - entry = pmd_mkhuge(pfn_t_pmd(pfn, prot)); - if (pfn_t_devmap(pfn)) - entry = pmd_mkdevmap(entry); - if (write) { - entry = pmd_mkyoung(pmd_mkdirty(entry)); - entry = maybe_pmd_mkwrite(entry, vma); - } - - if (pgtable) { - pgtable_trans_huge_deposit(mm, pmd, pgtable); - mm_inc_nr_ptes(mm); - pgtable = NULL; - } - - set_pmd_at(mm, addr, pmd, entry); - update_mmu_cache_pmd(vma, addr, pmd); - -out_unlock: - spin_unlock(ptl); - if (pgtable) - pte_free(mm, pgtable); -} - -/** - * vmf_insert_pfn_pmd - insert a pmd size pfn - * @vmf: Structure describing the fault - * @pfn: pfn to insert - * @write: whether it's a write fault - * - * Insert a pmd size pfn. See vmf_insert_pfn() for additional info. - * - * Return: vm_fault_t value. - */ -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 - * can't support a 'special' bit. - */ - BUG_ON(!(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) && - !pfn_t_devmap(pfn)); - BUG_ON((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) == - (VM_PFNMAP|VM_MIXEDMAP)); - BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); - - if (addr < vma->vm_start || addr >= vma->vm_end) - return VM_FAULT_SIGBUS; - - if (arch_needs_pgtable_deposit()) { - pgtable = pte_alloc_one(vma->vm_mm); - if (!pgtable) - return VM_FAULT_OOM; - } - - track_pfn_insert(vma, &pgprot, pfn); - - insert_pfn_pmd(vma, addr, vmf->pmd, pfn, pgprot, write, pgtable); - return VM_FAULT_NOPAGE; -} -EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd); - vm_fault_t dax_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write) { struct vm_area_struct *vma = vmf->vma; @@ -1280,80 +1189,6 @@ static pud_t maybe_pud_mkwrite(pud_t pud, struct vm_area_struct *vma) return pud; } -static void insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr, - pud_t *pud, pfn_t pfn, bool write) -{ - struct mm_struct *mm = vma->vm_mm; - pgprot_t prot = vma->vm_page_prot; - pud_t entry; - spinlock_t *ptl; - - ptl = pud_lock(mm, pud); - if (!pud_none(*pud)) { - if (write) { - if (pud_pfn(*pud) != pfn_t_to_pfn(pfn)) { - WARN_ON_ONCE(!is_huge_zero_pud(*pud)); - goto out_unlock; - } - entry = pud_mkyoung(*pud); - entry = maybe_pud_mkwrite(pud_mkdirty(entry), vma); - if (pudp_set_access_flags(vma, addr, pud, entry, 1)) - update_mmu_cache_pud(vma, addr, pud); - } - goto out_unlock; - } - - entry = pud_mkhuge(pfn_t_pud(pfn, prot)); - if (pfn_t_devmap(pfn)) - entry = pud_mkdevmap(entry); - if (write) { - entry = pud_mkyoung(pud_mkdirty(entry)); - entry = maybe_pud_mkwrite(entry, vma); - } - set_pud_at(mm, addr, pud, entry); - update_mmu_cache_pud(vma, addr, pud); - -out_unlock: - spin_unlock(ptl); -} - -/** - * vmf_insert_pfn_pud - insert a pud size pfn - * @vmf: Structure describing the fault - * @pfn: pfn to insert - * @write: whether it's a write fault - * - * Insert a pud size pfn. See vmf_insert_pfn() for additional info. - * - * Return: vm_fault_t value. - */ -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 - * can't support a 'special' bit. - */ - BUG_ON(!(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) && - !pfn_t_devmap(pfn)); - BUG_ON((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) == - (VM_PFNMAP|VM_MIXEDMAP)); - BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); - - if (addr < vma->vm_start || addr >= vma->vm_end) - return VM_FAULT_SIGBUS; - - track_pfn_insert(vma, &pgprot, pfn); - - insert_pfn_pud(vma, addr, vmf->pud, pfn, write); - return VM_FAULT_NOPAGE; -} -EXPORT_SYMBOL_GPL(vmf_insert_pfn_pud); - /** * dax_insert_pfn_pud - insert a pud size pfn backed by a normal page * @vmf: Structure describing the fault
Now that DAX is managing page reference counts the same as normal pages there are no callers for vmf_insert_pXd functions so remove them. Signed-off-by: Alistair Popple <apopple@nvidia.com> --- include/linux/huge_mm.h | 2 +- mm/huge_memory.c | 165 +----------------------------------------- 2 files changed, 167 deletions(-)