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: Mon, 10 Mar 2025 18:03:21 +0100 [thread overview]
Message-ID: <20250310170320.GC26382@redhat.com> (raw)
In-Reply-To: <20250304154846.1937958-4-david@redhat.com>
On 03/04, David Hildenbrand wrote:
>
> uprobe_write_opcode() does some pretty low-level things that really, it
> shouldn't be doing:
Agreed. Thanks again for doing this.
David, as I said, I can't review. I don't understand this mm/folio magic
with or without your changes.
However. With your changes the code looks "better" and more understandable
to me. So I'd vote for your patches even if I can't ack them.
But I'd like to ask some stupid (no, really) questions.
__uprobe_write_opcode() does:
/* We're done if we don't find an anonymous folio when unregistering. */
if (!folio_test_anon(folio))
return is_register ? -EFAULT : 0;
Yes, but we do not expect !folio_test_anon() if register == true, right?
See also below.
/* Verify that the page content is still as expected. */
if (verify_opcode(fw->page, opcode_vaddr, &opcode) <= 0) {
set_pte_at(vma->vm_mm, vaddr, fw->ptep, fw->pte);
return -EAGAIN;
}
The caller, uprobe_write_opcode(), has already called verify_opcode(),
why do we need to re-check?
But whatever reason we have. Can we change uprobe_write_opcode() to
"delay" put_page() and instead of
/* Walk the page tables again, to perform the actual update. */
folio = folio_walk_start(&fw, vma, vaddr, 0);
if (folio) {
ret = __uprobe_write_opcode(vma, &fw, folio, opcode_vaddr,
opcode);
folio_walk_end(&fw, vma);
} else {
ret = -EAGAIN;
}
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));
ret = __uprobe_write_opcode(vma, &fw, folio, opcode_vaddr,
opcode);
}
folio_walk_end(&fw, vma);
}
?
Once again, I am not trying to review. I am trying to understand the
basics of your code.
Thanks,
Oleg.
next prev parent reply other threads:[~2025-03-10 17:13 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 [this message]
2025-03-11 9:54 ` David Hildenbrand
2025-03-11 12:32 ` Oleg Nesterov
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=20250310170320.GC26382@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.