[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a7b9e65-b073-4132-9680-efc2b3af6af0@redhat.com>
Date: Tue, 30 Apr 2024 21:25:32 +0200
From: David Hildenbrand <david@...hat.com>
To: Guillaume Morin <guillaume@...infr.org>
Cc: oleg@...hat.com, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, muchun.song@...ux.dev
Subject: Re: [RFC][PATCH] uprobe: support for private hugetlb mappings
On 26.04.24 21:55, Guillaume Morin wrote:
> On 26 Apr 9:19, David Hildenbrand wrote:
>> A couple of points:
>>
>> a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want
>> to check PageAnonExclusive.
>>
>> b) If you're not following the can_follow_write_pte/_pmd model, you are
>> doing something wrong :)
>>
>> c) The code was heavily changed in mm/mm-unstable. It was merged with t
>> the common code.
>>
>> Likely, in mm/mm-unstable, the existing can_follow_write_pte and
>> can_follow_write_pmd checks will already cover what you want in most cases.
>>
>> We'd need a can_follow_write_pud() to cover follow_huge_pud() and
>> (unfortunately) something to handle follow_hugepd() as well similarly.
>>
>> Copy-pasting what we do in can_follow_write_pte() and adjusting for
>> different PTE types is the right thing to do. Maybe now it's time to factor
>> out the common checks into a separate helper.
>
> I tried to get the hugepd stuff right but this was the first I heard
> about it :-) Afaict follow_huge_pmd and friends were already DTRT
I'll have to have a closer look at some details (the hugepd writability
check looks a bit odd), but it's mostly what I would have expected!
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists