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] [day] [month] [year] [list]

Message-ID: <ff5391b2-be84-3192-407b-be5177612ce6@loongson.cn>
Date:   Sat, 19 Mar 2022 10:58:05 +0800
From:   maobibo <maobibo@...ngson.cn>
To:     David Hildenbrand <david@...hat.com>,
        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 03/18/2022 04:21 PM, David Hildenbrand wrote:
> 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.
yes, there will be problem change pte directly, thanks for your guidance:)
it should be done on page migration flow, i will check code of page migration.