From: David Hildenbrand <david@redhat.com>
To: Guillaume Morin <guillaume@morinfr.org>
Cc: oleg@redhat.com, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, muchun.song@linux.dev
Subject: Re: [RFC][PATCH] uprobe: support for private hugetlb mappings
Date: Wed, 24 Apr 2024 23:00:12 +0200 [thread overview]
Message-ID: <b1cf78f8-8480-4451-bbf8-78694ebd0438@redhat.com> (raw)
In-Reply-To: <ZilvOi7ceSXmwkNq@bender.morinfr.org>
On 24.04.24 22:44, Guillaume Morin wrote:
> On 24 Apr 22:09, David Hildenbrand wrote:
>>>> Let me try to see if we can get this done cleaner.
>>>>
>>>> One ugly part (in general here) is the custom page replacement in the
>>>> registration part.
>>>>
>>>> We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing pages
>>>> ourselves (which we likely shouldn't do ...) ... maybe we could use
>>>> FAULT_FLAG_UNSHARE faults such that we will get an anonymous folio
>>>> populated. (like KSM does nowadays)
>>>>
>>>> Punching FOLL_PIN|FOLL_LONGTERM into GUP would achieve the same thing, but
>>>> using FOLL_WRITE would not work on many file systems. So maybe we have to
>>>> trigger an unsharing fault ourselves.
>>
>> ^ realizing that we already use FOLL_FORCE, so we can just use FOLL_WRITE to
>> break COW.
>
> It was never clear to me why uprobes was not doing FOLL_WRITE in the
> first place, I must say.
It's quite dated code ...
The use of FOLL_FORCE really is ugly here. When registering, we require
VM_WRITE but ... when unregistering, we don't ...
>
> One issue here is that FOLL_FORCE|FOLL_WRITE is not implemented for
> hugetlb mappings. However this was also on my TODO and I have a draft
> patch that implements it.
Yes, I documented it back then and added sanity checks in GUP code to
fence it off. Shouldn't be too hard to implement (famous last words) and
would be the cleaner thing to use here once I manage to switch over to
FOLL_WRITE|FOLL_FORCE to break COW.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-04-24 21:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 18:37 Guillaume Morin
2024-04-22 9:39 ` David Hildenbrand
2024-04-22 18:11 ` Guillaume Morin
2024-04-22 18:59 ` David Hildenbrand
2024-04-22 20:53 ` Guillaume Morin
2024-04-24 20:09 ` David Hildenbrand
2024-04-24 20:44 ` Guillaume Morin
2024-04-24 21:00 ` David Hildenbrand [this message]
2024-04-25 15:19 ` Guillaume Morin
2024-04-25 15:42 ` David Hildenbrand
2024-04-25 19:56 ` David Hildenbrand
2024-04-26 0:09 ` Guillaume Morin
2024-04-26 7:19 ` David Hildenbrand
2024-04-26 19:55 ` Guillaume Morin
2024-04-30 15:22 ` Guillaume Morin
2024-04-30 18:21 ` David Hildenbrand
2024-04-30 18:58 ` Guillaume Morin
2024-04-30 19:25 ` David Hildenbrand
2024-05-02 3:59 ` Guillaume Morin
2024-05-16 17:44 ` Guillaume Morin
2024-05-16 19:52 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1cf78f8-8480-4451-bbf8-78694ebd0438@redhat.com \
--to=david@redhat.com \
--cc=guillaume@morinfr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=muchun.song@linux.dev \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®