Balbir Singh <[email protected]> writes:

> [ text/plain ]
>
>
> On 27/03/16 19:23, Aneesh Kumar K.V wrote:
>> This split _PAGE_RW bit to _PAGE_READ and _PAGE_WRITE. It also remove
>> the dependency on _PAGE_USER for implying read only. Few things to note
>> here is that, we have read implied with write and execute permission.
>> Hence we should always find _PAGE_READ set on hash pte fault.
>>
>> We still can't switch PROT_NONE to !(_PAGE_RWX). Auto numa do depend
>> on marking a prot none pte _PAGE_WRITE. (For more details look at
>> b191f9b106ea "mm: numa: preserve PTE write permissions across a NUMA hinting 
>> fault")
>>

......


>> diff --git a/arch/powerpc/mm/hash_utils_64.c 
>> b/arch/powerpc/mm/hash_utils_64.c
>> index 90dd9280894f..ea23403b3fc0 100644
>> --- a/arch/powerpc/mm/hash_utils_64.c
>> +++ b/arch/powerpc/mm/hash_utils_64.c
>> @@ -175,8 +175,9 @@ unsigned long htab_convert_pte_flags(unsigned long 
>> pteflags)
>>       * or PP=0x3 for read-only (including writeable but clean pages).
>>       */
>>      if (pteflags & _PAGE_USER) {
>> -            rflags |= 0x2;
>> -            if (!((pteflags & _PAGE_RW) && (pteflags & _PAGE_DIRTY)))
>> +            if (pteflags & _PAGE_RWX)
> Should this be pteflags & _PAGE_RW?

That will work, because we always have _PAGE_READ set for _PAGE_EXEC.
But what we really need to check here is READ/WRITE/EXEC.


>> +                    rflags |= 0x2;
>> +            if (!((pteflags & _PAGE_WRITE) && (pteflags & _PAGE_DIRTY)))
>>                      rflags |= 0x1;
> if pteflags == _PAGE_USER | _PAGE_WRITE | _PAGE_DIRTY, what is rflags set to?
>


rflags will be 0x2. and for readlyonly 0x3. That is documented above. 



>
>
>>      }
>>      /*
>> @@ -1205,7 +1206,7 @@ EXPORT_SYMBOL_GPL(hash_page);
>>  int __hash_page(unsigned long ea, unsigned long msr, unsigned long trap,
>>              unsigned long dsisr)
>>  {
>> -    unsigned long access = _PAGE_PRESENT;
>> +    unsigned long access = _PAGE_PRESENT | _PAGE_READ;
>>      unsigned long flags = 0;
>>      struct mm_struct *mm = current->mm;


....

>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>> index 83dfd7925c72..98b5c03e344d 100644
>> --- a/arch/powerpc/mm/pgtable.c
>> +++ b/arch/powerpc/mm/pgtable.c
>> @@ -177,8 +177,8 @@ void set_pte_at(struct mm_struct *mm, unsigned long 
>> addr, pte_t *ptep,
>>       * _PAGE_PRESENT, but we can be sure that it is not in hpte.
>>       * Hence we can use set_pte_at for them.
>>       */
>> -    VM_WARN_ON((pte_val(*ptep) & (_PAGE_PRESENT | _PAGE_USER)) ==
>> -            (_PAGE_PRESENT | _PAGE_USER));
>> +    VM_WARN_ON(pte_present(*ptep) && !pte_protnone(*ptep));
>> +
> What was wrong with the previous check? The compiler will optimize it, but 
> the new
> check uses two pte_val() calls on *ptep

That was confusing, even though we documented it clearly above, it does
confuse, because checking for _PAGE_USER is an indirect hint for prot
numa ptes.


>>      /*
>>       * Add the pte bit when tryint set a pte
>>       */
>> diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
>> index aa742aa35b64..00d8d985bba3 100644
>> --- a/arch/powerpc/mm/pgtable_64.c
>> +++ b/arch/powerpc/mm/pgtable_64.c
>> @@ -277,7 +277,7 @@ void __iomem * ioremap_prot(phys_addr_t addr, unsigned 
>> long size,
>>      void *caller = __builtin_return_address(0);
>>  
>>      /* writeable implies dirty for kernel addresses */
>> -    if (flags & _PAGE_RW)
>> +    if (flags & _PAGE_WRITE)
>>              flags |= _PAGE_DIRTY;
>>  
>>      /* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
>> @@ -681,8 +681,7 @@ void set_pmd_at(struct mm_struct *mm, unsigned long addr,
>>              pmd_t *pmdp, pmd_t pmd)
>>  {
>>  #ifdef CONFIG_DEBUG_VM
>> -    WARN_ON((pmd_val(*pmdp) & (_PAGE_PRESENT | _PAGE_USER)) ==
>> -            (_PAGE_PRESENT | _PAGE_USER));
>> +    WARN_ON(pte_present(pmd_pte(*pmdp)) && !pte_protnone(pmd_pte(*pmdp)));
> Same as above, plus I think we can move these to VM_WARN_ON just to be 
> consistent

We already have #ifdef CONFIG_DEBUG_VM around, hence we can avoid using
VM_WARN_ON.

-aneesh

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to