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

[Thomas HellstrÃm (VMware)]

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
> > vma_set_page_prot().
> 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.

/Thomas