On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
On 3/23/21 8:52 PM, Williams, Dan J wrote:Yeah :-/
On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:Hmm, yes with that patch it will obviously not work as intended.
TTM sets up huge page-table-entries both to system- and devicePlease do not abuse p{m,u}d_devmap like this. I'm in the process of
memory,
and we don't want gup to assume there are always valid backing struct
pages for these. For PTEs this is handled by setting the pte_special
bit,
but for the huge PUDs and PMDs, we have neither pmd_special nor
pud_special. Normally, huge TTM entries are identified by looking at
vma_is_special_huge(), but fast gup can't do that, so as an
alternative
define _devmap entries for which there are no backing dev_pagemap as
special, update documentation and make huge TTM entries _devmap,
after
verifying that there is no backing dev_pagemap.
removing get_devpagemap() from the gup-fast path [1]. Instead there
should be space for p{m,u}d_special in the page table entries (at least
for x86-64). So the fix is to remove that old assumption that huge
pages can never be special.
[1]:
http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Given that, I think we'll need to disable the TTM huge pages for now until
we can sort out and agree on using a page table entry bit.
I think going full pud/pmd_mkspecial should then also mesh well with
Jason's request to wrap it all up into a vmf_insert_* helper, so at least
it would all look rather pretty in the end.
-Daniel