linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Jann Horn <jannh@google.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
	linux-trace-kernel@vger.kernel.org,  peterz@infradead.org,
	oleg@redhat.com, rostedt@goodmis.org,  mhiramat@kernel.org,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	 jolsa@kernel.org, paulmck@kernel.org, willy@infradead.org,
	surenb@google.com,  akpm@linux-foundation.org,
	linux-mm@kvack.org, mjguzik@gmail.com,  brauner@kernel.org
Subject: Re: [PATCH 0/2] uprobes,mm: speculative lockless VMA-to-uprobe lookup
Date: Tue, 10 Sep 2024 10:58:44 -0700	[thread overview]
Message-ID: <CAEf4BzazZSUtJ9vPd6Xj4539MCebctOZJmO7xmdUhoQiv5mBFg@mail.gmail.com> (raw)
In-Reply-To: <CAG48ez1+Y+ifc3HfG=E5j+g=RwtzH2TiE4mAC2TZxS52idkRZg@mail.gmail.com>

On Tue, Sep 10, 2024 at 9:06 AM Jann Horn <jannh@google.com> wrote:
>
> On Fri, Sep 6, 2024 at 7:12 AM Andrii Nakryiko <andrii@kernel.org> wrote:
> > Implement speculative (lockless) resolution of VMA to inode to uprobe,
> > bypassing the need to take mmap_lock for reads, if possible. Patch #1 by Suren
> > adds mm_struct helpers that help detect whether mm_struct were changed, which
> > is used by uprobe logic to validate that speculative results can be trusted
> > after all the lookup logic results in a valid uprobe instance.
>
> Random thought: It would be nice if you could skip the MM stuff
> entirely and instead go through the GUP-fast path, but I guess going
> from a uprobe-created anon page to the corresponding uprobe is hard...
> but maybe if you used the anon_vma pointer as a lookup key to find the
> uprobe, it could work? Though then you'd need hooks in the anon_vma
> code... maybe not such a great idea.

So I'm not crystal clear on all the details here, so maybe you can
elaborate a bit. But keep in mind that a) there could be multiple
uprobes within a single user page, so lookup has to take at least
offset within the page into account somehow. But also b) single uprobe
can be installed in many independent anon VMAs across many processes.
So anon vma itself can't be part of the key.

Though maybe we could have left some sort of "cookie" stashed
somewhere to help with lookup. But then again, multiple uprobes per
page.

It does feel like lockless VMA to inode resolution would be a cleaner
solution, let's see if we can get there somehow.


  reply	other threads:[~2024-09-10 17:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06  5:12 Andrii Nakryiko
2024-09-06  5:12 ` [PATCH 1/2] mm: introduce mmap_lock_speculation_{start|end} Andrii Nakryiko
2024-09-09 12:35   ` Jann Horn
2024-09-10  2:09     ` Suren Baghdasaryan
2024-09-10 15:31       ` Jann Horn
2024-09-11 21:34       ` Andrii Nakryiko
2024-09-11 21:48         ` Suren Baghdasaryan
2024-09-12 21:02           ` [PATCH v2 1/1] " Suren Baghdasaryan
2024-09-12 21:04             ` Suren Baghdasaryan
2024-09-12 22:19               ` Andrii Nakryiko
2024-09-12 22:24                 ` Suren Baghdasaryan
2024-09-12 22:52             ` Jann Horn
2024-09-24 17:15               ` Matthew Wilcox
2024-09-24 18:00                 ` Jann Horn
2024-09-06  5:12 ` [PATCH 2/2] uprobes: add speculative lockless VMA-to-inode-to-uprobe resolution Andrii Nakryiko
2024-09-08  1:22   ` Liam R. Howlett
2024-09-09  1:08     ` Andrii Nakryiko
2024-09-09 13:12   ` Jann Horn
2024-09-09 21:29     ` Andrii Nakryiko
2024-09-10 15:39       ` Jann Horn
2024-09-10 20:56         ` Andrii Nakryiko
2024-09-10 16:32       ` Suren Baghdasaryan
2024-09-10 20:58         ` Andrii Nakryiko
2024-09-12 11:17           ` Christian Brauner
2024-09-12 17:54             ` Andrii Nakryiko
2024-09-15 15:04   ` Oleg Nesterov
2024-09-17  8:19     ` Andrii Nakryiko
2024-09-10 16:06 ` [PATCH 0/2] uprobes,mm: speculative lockless VMA-to-uprobe lookup Jann Horn
2024-09-10 17:58   ` Andrii Nakryiko [this message]
2024-09-10 18:13     ` Jann Horn

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=CAEf4BzazZSUtJ9vPd6Xj4539MCebctOZJmO7xmdUhoQiv5mBFg@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=jannh@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=surenb@google.com \
    --cc=willy@infradead.org \
    /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