[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8cbd44d9-f39b-4ee8-b1c1-ba89c12c0e23@redhat.com>
Date: Thu, 29 Aug 2024 17:31:21 +0200
From: David Hildenbrand <david@...hat.com>
To: Qi Zheng <zhengqi.arch@...edance.com>, muchun.song@...ux.dev
Cc: hughd@...gle.com, willy@...radead.org, vbabka@...nel.org,
akpm@...ux-foundation.org, rppt@...nel.org, vishal.moola@...il.com,
peterx@...hat.com, ryan.roberts@....com,
christophe.leroy2@...soprasteria.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2 01/14] mm: pgtable: introduce
pte_offset_map_{ro|rw}_nolock()
On 29.08.24 12:59, Qi Zheng wrote:
>
>
> On 2024/8/28 18:48, David Hildenbrand wrote:
>> On 27.08.24 06:33, Qi Zheng wrote:
>
> [...]
>
>>> sufficient AFAIUK.
>>
>> Drop the "AFAIUK" :)
>>
>> "For R/O access this is sufficient."
>>
>>>
>>> pte_offset_map_rw_nolock(mm, pmd, addr, pmdvalp, ptlp), above, is like
>>> pte_offset_map_ro_nolock(); but when successful, it also outputs the
>>> pdmval. For R/W access, the callers can not accept that the page table
>>> it sees has been unmapped and is about to get freed. The pmdval can help
>>> callers to recheck pmd_same() to identify this case once the spinlock is
>>> taken. For some cases where exclusivity is already guaranteed, such as
>>> holding the write lock of mmap_lock, or in cases where checking is
>>> sufficient, such as a !pte_none() pte will be rechecked after the
>>> spinlock is taken, there is no need to recheck pdmval.
>>
>> Right, using pte_same() one can achieve a similar result, assuming that
>> the freed page table gets all ptes set to pte_none().
>>
>> page_table_check_pte_clear_range() before pte_free_defer() in
>> retract_page_tables/collapse_pte_mapped_thp() sanity checks that I think.
>
> Since commit 1d65b771bc08, retract_page_tables() only holds the
> i_mmap_lock_read(mapping) but not mmap_lock, so it seems that
> holding the write lock of mmap_lock cannot guarantee the stability
> of the PTE page.
Guess it depends. khugepaged on anonymous memory will block any page
table walkers (like anon THP collapse does) -- per-VMA lock, mmap lock,
mapping lock/RMAP lock ... so it *should* be sufficient to hold any of
these, right?
So at least for now, these (anonymous memory) cases would be ok. Likely
that will change when reclaiming empty page tables.
>
> IIUC, I will also perform a pmd_same() check on the case where the
> write lock of mmap_lock is held in v3. Or do I miss something?
Can you spell out the instances where you think it might be required.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists