public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Morin <guillaume@morinfr.org>
To: David Hildenbrand <david@redhat.com>
Cc: Guillaume Morin <guillaume@morinfr.org>,
	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 22:44:42 +0200	[thread overview]
Message-ID: <ZilvOi7ceSXmwkNq@bender.morinfr.org> (raw)
In-Reply-To: <8d5314ac-5afe-41d4-9d27-9512cd96d21c@redhat.com>

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.

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.

> 
> > > 
> > > That would do the page replacement for us and we "should" be able to lookup
> > > an anonymous folio that we can then just modify, like ptrace would.
> > > 
> > > But then, there is also unregistration part, with weird conditional page
> > > replacement. Zapping the anon page if the content matches the content of the
> > > original page is one thing. But why are we placing an existing anonymous
> > > page by a new anonymous page when the content from the original page differs
> > > (but matches the one from the just copied page?)?
> > > 
> > > I'll have to further think about that one. It's all a bit nasty.
> > 
> > Sounds good to me. I am willing to help with the code when you have a
> > plan or testing as you see fit. Let me know.
> 
> I'm hacking on a redesign that removes the manual COW breaking logic and
> *might* make it easier to integrate hugetlb. (very likely, but until I have
> the redesign running I cannot promise anything :) )
> 
> I'll let you know once I have something ready so you could integrate the
> hugetlb portion.

Sounds good.

-- 
Guillaume Morin <guillaume@morinfr.org>

  reply	other threads:[~2024-04-24 20:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19 18:37 [RFC][PATCH] uprobe: support for private hugetlb mappings 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 [this message]
2024-04-24 21:00             ` David Hildenbrand
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=ZilvOi7ceSXmwkNq@bender.morinfr.org \
    --to=guillaume@morinfr.org \
    --cc=david@redhat.com \
    --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