linux-kernel - Re: [PATCH v2] mm: add access/dirty bit on numa page fault

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Mar 2022 09:21:46 +0100
From:   David Hildenbrand <david@...hat.com>
To:     maobibo <maobibo@...ngson.cn>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Anshuman Khandual <anshuman.khandual@....com>
Subject: Re: [PATCH v2] mm: add access/dirty bit on numa page fault

On 18.03.22 02:17, maobibo wrote:
> 
> 
> On 03/17/2022 08:32 PM, David Hildenbrand wrote:
>> On 17.03.22 07:50, Bibo Mao wrote:
>>> On platforms like x86/arm which supports hw page walking, access
>>> and dirty bit is set by hw, however on some platforms without
>>> such hw functions, access and dirty bit is set by software in
>>> next trap.
>>>
>>> During numa page fault, dirty bit can be added for old pte if
>>> fail to migrate on write fault. And if it succeeds to migrate,
>>> access bit can be added for migrated new pte, also dirty bit
>>> can be added for write fault.
>>>
>>> Signed-off-by: Bibo Mao <maobibo@...ngson.cn>
>>> ---
>>>  mm/memory.c | 21 ++++++++++++++++++++-
>>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index c125c4969913..65813bec9c06 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -4404,6 +4404,22 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
>>>  	if (migrate_misplaced_page(page, vma, target_nid)) {
>>>  		page_nid = target_nid;
>>>  		flags |= TNF_MIGRATED;
>>> +
>>> +		/*
>>> +		 * update pte entry with access bit, and dirty bit for
>>> +		 * write fault
>>> +		 */
>>> +		spin_lock(vmf->ptl);
>>
>> Ehm, are you sure? We did a pte_unmap_unlock(), so you most certainly need a
>>
>> vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
> yes, we need probe pte entry again after function pte_unmap_unlock().
>>
>>
>> Also, don't we need pte_same() checks before we do anything after
>> dropping the PT lock?
> I do not think so. If page succeeds in migration, pte entry should be changed
> also, it should be different.
> 

We have to be very careful here. Page migration succeeded, so I do
wonder if you have to do anything on this branch *at all*. I'd assume
that page migration too care of that already.

See, when only holding the mmap lock in read mode, there are absolutely
no guarantees what will happen after dropping the PT lock. The page
could get unmapped and another page could get mapped. The page could
have been mapped R/O in the meantime.

So I'm pretty sure that unconditionally modifying the PTE here is wrong.

-- 
Thanks,

David / dhildenb