Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1648213
| From | Punit Agrawal <punit.agrawal@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v3 2/6] mm, gup: Ensure real head page is ref-counted when using hugepages |
| Date | 2017-05-23 17:50 +0200 |
| Message-ID | <tKkel-58v-3@gated-at.bofh.it> (permalink) |
| References | <tJVIZ-6iD-3@gated-at.bofh.it> <tJVJ0-6iD-27@gated-at.bofh.it> <tKi2S-3Kj-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
"Kirill A. Shutemov" <kirill@shutemov.name> writes: > On Mon, May 22, 2017 at 02:36:00PM +0100, Punit Agrawal wrote: >> When speculatively taking references to a hugepage using >> page_cache_add_speculative() in gup_huge_pmd(), it is assumed that the >> page returned by pmd_page() is the head page. Although normally true, >> this assumption doesn't hold when the hugepage comprises of successive >> page table entries such as when using contiguous bit on arm64 at PTE or >> PMD levels. >> >> This can be addressed by ensuring that the page passed to >> page_cache_add_speculative() is the real head or by de-referencing the >> head page within the function. >> >> We take the first approach to keep the usage pattern aligned with >> page_cache_get_speculative() where users already pass the appropriate >> page, i.e., the de-referenced head. >> >> Apply the same logic to fix gup_huge_[pud|pgd]() as well. > > Hm. Okay. But I'm kinda surprise that this is the only place that need to > be adjusted. > > Have you validated all other pmd_page() use-cases? I came across the gup issues were found while investigating a failing test from mce-tests. I think the problem here is not due to the use of pmd_page() but because page_cache_[add|get]_speculative() don't ensure they ref-count the head page as is done in get_page(). Having said that, I had a quick look at the other uses of pmd_page() - Quite a few of them are followed by an explicit BUG_ON() to check that the page returned is a head page. All other instances seem to be dealing with transparent hugepages where contiguous hugepages are not supported. I don't see any call sites that ring alarm bells. Did you have any particular part of the code in mind where pmd_page() usage might be a problem? Thanks, Punit
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v3 0/6] Support for contiguous pte hugepages Punit Agrawal <punit.agrawal@arm.com> - 2017-05-22 15:40 +0200
[PATCH v3 1/6] mm, gup: Remove broken VM_BUG_ON_PAGE compound check for hugepages Punit Agrawal <punit.agrawal@arm.com> - 2017-05-22 15:40 +0200
Re: [PATCH v3 1/6] mm, gup: Remove broken VM_BUG_ON_PAGE compound check for hugepages "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-05-23 15:20 +0200
[PATCH v3 6/6] mm: rmap: Use correct helper when poisoning hugepages Punit Agrawal <punit.agrawal@arm.com> - 2017-05-22 15:40 +0200
[PATCH v3 2/6] mm, gup: Ensure real head page is ref-counted when using hugepages Punit Agrawal <punit.agrawal@arm.com> - 2017-05-22 15:40 +0200
Re: [PATCH v3 2/6] mm, gup: Ensure real head page is ref-counted when using hugepages "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-05-23 15:30 +0200
Re: [PATCH v3 2/6] mm, gup: Ensure real head page is ref-counted when using hugepages Punit Agrawal <punit.agrawal@arm.com> - 2017-05-23 17:50 +0200
[PATCH v3 5/6] mm/hugetlb: Introduce set_huge_swap_pte_at() helper Punit Agrawal <punit.agrawal@arm.com> - 2017-05-22 15:40 +0200
[PATCH v3.1 5/6] mm/hugetlb: Introduce set_huge_swap_pte_at() helper Punit Agrawal <punit.agrawal@arm.com> - 2017-05-22 18:40 +0200
csiph-web