Re: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit

From: Thomas HellstrÃm (VMware)
Date: Thu Sep 12 2019 - 04:29:38 EST

On 9/11/19 8:03 PM, Andy Lutomirski wrote:

That distinction is important because if it ever comes to a choice
between adding a new lock to protect vm_page_prot (and consequently slow
down the whole vm system) and using the WRITE_ONCE solution in TTM, we
should know what the implications are. As it turns out previous choices
in this area actually seem to have opted for the lockless WRITE_ONCE /
READ_ONCE / ptl solution. See __split_huge_pmd_locked() and
I think it would be even better if the whole thing could work without
ever writing to vm_page_prot. This would be a requirement for vvar in
the unlikely event that the vvar vma ever supported splittable huge
pages. Fortunately, that seems unlikely :)

Yeah, for TTM the situation is different since we want huge vm pages at some point.

But I re-read __split_huge_pmd_locked() and it actually looks like vm_page_prot is only accessed for anonymous vmas. For other vmas, it appears it just simply zaps the PMD, relying on re-faulting the page table enries if necessary (as also suggested by Christian in another thread).

So perhaps we should be good never writing to vm_page_prot.