Re: [PATCH v3 13/13] mm/debug_vm_pgtable: populate a pte entry before fetching it

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 09/01/2020 03:28 PM, Aneesh Kumar K.V wrote:
> On 9/1/20 1:08 PM, Anshuman Khandual wrote:
>>
>>
>> On 09/01/2020 12:07 PM, Aneesh Kumar K.V wrote:
>>> On 9/1/20 8:55 AM, Anshuman Khandual wrote:
>>>>
>>>>
>>>> On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
>>>>> pte_clear_tests operate on an existing pte entry. Make sure that is not a none
>>>>> pte entry.
>>>>>
>>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx>
>>>>> ---
>>>>>    mm/debug_vm_pgtable.c | 6 ++++--
>>>>>    1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>>>>> index 21329c7d672f..8527ebb75f2c 100644
>>>>> --- a/mm/debug_vm_pgtable.c
>>>>> +++ b/mm/debug_vm_pgtable.c
>>>>> @@ -546,7 +546,7 @@ static void __init pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp,
>>>>>    static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
>>>>>                       unsigned long vaddr)
>>>>>    {
>>>>> -    pte_t pte = ptep_get(ptep);
>>>>> +    pte_t pte =  ptep_get_and_clear(mm, vaddr, ptep);
>>>>
>>>> Seems like ptep_get_and_clear() here just clears the entry in preparation
>>>> for a following set_pte_at() which otherwise would have been a problem on
>>>> ppc64 as you had pointed out earlier i.e set_pte_at() should not update an
>>>> existing valid entry. So the commit message here is bit misleading.
>>>>
>>>
>>> and also fetch the pte value which is used further.
>>>
>>>
>>>>>          pr_debug("Validating PTE clear\n");
>>>>>        pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
>>>>> @@ -944,7 +944,7 @@ static int __init debug_vm_pgtable(void)
>>>>>        p4d_t *p4dp, *saved_p4dp;
>>>>>        pud_t *pudp, *saved_pudp;
>>>>>        pmd_t *pmdp, *saved_pmdp, pmd;
>>>>> -    pte_t *ptep;
>>>>> +    pte_t *ptep, pte;
>>>>>        pgtable_t saved_ptep;
>>>>>        pgprot_t prot, protnone;
>>>>>        phys_addr_t paddr;
>>>>> @@ -1049,6 +1049,8 @@ static int __init debug_vm_pgtable(void)
>>>>>         */
>>>>>          ptep = pte_alloc_map_lock(mm, pmdp, vaddr, &ptl);
>>>>> +    pte = pfn_pte(pte_aligned, prot);
>>>>> +    set_pte_at(mm, vaddr, ptep, pte);
>>>>
>>>> Not here, creating and populating an entry must be done in respective
>>>> test functions itself. Besides, this seems bit redundant as well. The
>>>> test pte_clear_tests() with the above change added, already
>>>>
>>>> - Clears the PTEP entry with ptep_get_and_clear()
>>>
>>> and fetch the old value set previously.
>>
>> In that case, please move above two lines i.e
>>
>> pte = pfn_pte(pte_aligned, prot);
>> set_pte_at(mm, vaddr, ptep, pte);
>>
>> from debug_vm_pgtable() to pte_clear_tests() and update it's arguments
>> as required.
>>
> 
> Frankly, I don't understand what these tests are testing. It all looks like some random clear and set.

The idea here is to have some value with some randomness preferably, in
a given PTEP before attempting to clear the entry, in order to make sure
that pte_clear() is indeed clearing something of non-zero value.

> 
> static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
>                    unsigned long vaddr, unsigned long pfn,
>                    pgprot_t prot)
> {
> 
>     pte_t pte = pfn_pte(pfn, prot);
>     set_pte_at(mm, vaddr, ptep, pte);
> 
>     pte =  ptep_get_and_clear(mm, vaddr, ptep);

Looking at this again, this preceding pfn_pte() followed by set_pte_at()
is not really required. Its reasonable to start with what ever was there
in the PTEP as a seed value which anyway gets added with RANDOM_ORVALUE.
s/ptep_get/ptep_get_and_clear is sufficient to take care of the powerpc
set_pte_at() constraint.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux