From: Oleg Nesterov <oleg@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Russell King <linux@armlinux.org.uk>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
Tong Tiangen <tongtiangen@huawei.com>
Subject: Re: [PATCH -next v1 3/3] kernel/events/uprobes: uprobe_write_opcode() rewrite
Date: Tue, 11 Mar 2025 13:32:42 +0100 [thread overview]
Message-ID: <20250311123241.GB3493@redhat.com> (raw)
In-Reply-To: <79ec5aa9-1937-436e-8cf4-436746142f7b@redhat.com>
On 03/11, David Hildenbrand wrote:
>
> Regarding both questions, the code is fairly racy. Nothing would stop user
> space from (a) modifying that memory
Yes, but we don't really care. uprobes.c assumes that user-space won't play
with the probed memory.
Note that if is_register is false, then vma can be even writable. Hmm, why?
Perhaps valid_vma() should ignore is_register and nack VM_MAYWRITE ? But
this doesn't really matter, say, gdb can change this memory anyway. Again,
we don't really care.
> >do something like
> >
> > /* Walk the page tables again, to perform the actual update. */
> > ret = -EAGAIN;
> > folio = folio_walk_start(&fw, vma, vaddr, 0);
> > if (folio) {
> > if (fw.page == page) {
> > WARN_ON(is_register && !folio_test_anon(folio));
>
> Yes, that would work (we could leave the WARN_ON in __uprobe_write_opcode),
> but I am not sure if the end result is better better. No strong opinion on
> the details though.
Will, this way __uprobe_write_opcode() will look a little bit simpler...
But I won't insist, please do what you think is better.
Oleg.
next prev parent reply other threads:[~2025-03-11 12:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 15:48 [PATCH -next v1 0/3] kernel/events/uprobes: uprobe_write_opcode() rewrite David Hildenbrand
2025-03-04 15:48 ` [PATCH -next v1 1/3] kernel/events/uprobes: pass VMA instead of MM to remove_breakpoint() David Hildenbrand
2025-03-04 15:48 ` [PATCH -next v1 2/3] kernel/events/uprobes: pass VMA to set_swbp(), set_orig_insn() and uprobe_write_opcode() David Hildenbrand
2025-03-04 15:48 ` [PATCH -next v1 3/3] kernel/events/uprobes: uprobe_write_opcode() rewrite David Hildenbrand
2025-03-05 19:30 ` Matthew Wilcox
2025-03-05 19:37 ` David Hildenbrand
2025-03-10 17:03 ` Oleg Nesterov
2025-03-11 9:54 ` David Hildenbrand
2025-03-11 12:32 ` Oleg Nesterov [this message]
2025-03-11 20:02 ` David Hildenbrand
2025-03-05 15:20 ` [PATCH -next v1 0/3] " Oleg Nesterov
2025-03-05 19:43 ` Andrii Nakryiko
2025-03-05 19:47 ` David Hildenbrand
2025-03-05 19:58 ` Andrii Nakryiko
2025-03-05 20:53 ` 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=20250311123241.GB3493@redhat.com \
--to=oleg@redhat.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=david@redhat.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tongtiangen@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.