odd pte_mfn_to_pfn() behavior

odd pte_mfn_to_pfn() behavior

[Jan Beulich]

Jürgen, Boris,

in figuring out why a W+X mapping warning has magically disappeared
(I now at least know that it was for the shared info fixmap page)
in 5.6, besides finding two logic errors in 2ae27137b2db ("x86: mm:
convert dump_pagetables to use walk_page_range") - one in the way
st->prot_levels[] gets maintained, the other it truncating 64-bit
PAE PTEs to 32 bits when calling note_page() - I've also noticed
that the observed (in note_page()) PTE for the shared info page is
now 0x62 (not present, PFN 0). Up to 5.5, only the PTE flags were
involved, and pte_flags() behaves better than pte_val() for this
particular PTE - pte_mfn_to_pfn() zaps _PAGE_PRESENT and the frame
number when it can't translate the MFN to a PFN.

Presumably this behavior is acceptable in most cases, but it
clearly is wrong here and would - even with aforementioned bugs
addressed - still prevent the W+X warning to reappear. I have no
idea whether it would be acceptable for the generic framework to
be changed to use pte_flags() again instead of pte_val().

Having looked at this code (and the prior logic) I have to admit
that I haven't been able to figure yet why I've seen these W+X
mapping warnings for the shared info page only ever on 32-bit.

Jan