lkml.org 
[lkml]   [2019]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit
From
Date
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


\
 
 \ /
  Last update: 2019-09-12 10:30    [W:0.079 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site