[PATCH v2 07/19] mm/fork: Accept huge pfnmap entries
David Hildenbrand
david at redhat.com
Thu Aug 29 12:44:01 PDT 2024
On 29.08.24 20:26, Peter Xu wrote:
> On Thu, Aug 29, 2024 at 05:10:42PM +0200, David Hildenbrand wrote:
>> On 26.08.24 22:43, Peter Xu wrote:
>>> Teach the fork code to properly copy pfnmaps for pmd/pud levels. Pud is
>>> much easier, the write bit needs to be persisted though for writable and
>>> shared pud mappings like PFNMAP ones, otherwise a follow up write in either
>>> parent or child process will trigger a write fault.
>>>
>>> Do the same for pmd level.
>>>
>>> Signed-off-by: Peter Xu <peterx at redhat.com>
>>> ---
>>> mm/huge_memory.c | 29 ++++++++++++++++++++++++++---
>>> 1 file changed, 26 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index e2c314f631f3..15418ffdd377 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -1559,6 +1559,24 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
>>> pgtable_t pgtable = NULL;
>>> int ret = -ENOMEM;
>>> + pmd = pmdp_get_lockless(src_pmd);
>>> + if (unlikely(pmd_special(pmd))) {
>>
>> I assume I have to clean up your mess here as well?
>
> Can you leave meaningful and explicit comment? I'll try to address.
Sorry Peter, but I raised all that as reply to v1. For example, I
stated that vm_normal_page_pmd() already *exist* and why these
pmd_special() checks should be kept there.
I hear you, you're not interested in cleaning that up. So at this point
it's easier for me to clean it up myself.
--
Cheers,
David / dhildenb
More information about the linux-arm-kernel
mailing list