Messages in this thread | | | Subject | Re: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit | From | Thomas Hellström (VMware) <> | Date | Thu, 12 Sep 2019 10:29:24 +0200 |
| |
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
| |