From: Jiri Olsa <jolsa@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, x86@kernel.org,
"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
"John Fastabend" <john.fastabend@gmail.com>,
"Hao Luo" <haoluo@google.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Alan Maguire" <alan.maguire@oracle.com>,
"David Laight" <David.Laight@ACULAB.COM>,
"Thomas Weißschuh" <thomas@t-8ch.de>
Subject: [PATCH RFCv3 07/23] uprobes: Remove breakpoint in unapply_uprobe under mmap_write_lock
Date: Thu, 20 Mar 2025 12:41:42 +0100 [thread overview]
Message-ID: <20250320114200.14377-8-jolsa@kernel.org> (raw)
In-Reply-To: <20250320114200.14377-1-jolsa@kernel.org>
Currently unapply_uprobe takes mmap_read_lock, but it might call
remove_breakpoint which eventually changes user pages.
Current code writes either breakpoint or original instruction,
so it probably go away with that, but with the upcoming changes
that use multiple instructions on the probed address we need to
ensure that any update to mm's pages is exclusive.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
kernel/events/uprobes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 92fed5e50ec1..bd4bc62f80d7 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1465,7 +1465,7 @@ static int unapply_uprobe(struct uprobe *uprobe, struct mm_struct *mm)
struct vm_area_struct *vma;
int err = 0;
- mmap_read_lock(mm);
+ mmap_write_lock(mm);
for_each_vma(vmi, vma) {
unsigned long vaddr;
loff_t offset;
@@ -1482,7 +1482,7 @@ static int unapply_uprobe(struct uprobe *uprobe, struct mm_struct *mm)
vaddr = offset_to_vaddr(vma, uprobe->offset);
err |= remove_breakpoint(uprobe, mm, vaddr);
}
- mmap_read_unlock(mm);
+ mmap_write_unlock(mm);
return err;
}
--
2.49.0
next prev parent reply other threads:[~2025-03-20 11:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 11:41 [PATCH RFCv3 00/23] uprobes: Add support to optimize usdt probes on x86_64 Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 01/23] uprobes: Rename arch_uretprobe_trampoline function Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 02/23] uprobes: Make copy_from_page global Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 03/23] uprobes: Move ref_ctr_offset update out of uprobe_write_opcode Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 04/23] uprobes: Add uprobe_write function Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 05/23] uprobes: Add nbytes argument to uprobe_write_opcode Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 06/23] uprobes: Add orig argument to uprobe_write and uprobe_write_opcode Jiri Olsa
2025-04-04 20:33 ` Andrii Nakryiko
2025-04-07 11:13 ` Jiri Olsa
2025-03-20 11:41 ` Jiri Olsa [this message]
2025-03-20 11:41 ` [PATCH RFCv3 08/23] uprobes/x86: Add uprobe syscall to speed up uprobe Jiri Olsa
2025-04-04 20:33 ` Andrii Nakryiko
2025-04-07 10:58 ` Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 09/23] uprobes/x86: Add mapping for optimized uprobe trampolines Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 10/23] uprobes/x86: Add support to emulate nop5 instruction Jiri Olsa
2025-04-04 20:33 ` Andrii Nakryiko
2025-04-07 11:07 ` Jiri Olsa
2025-04-08 20:21 ` Jiri Olsa
2025-04-09 18:19 ` Andrii Nakryiko
2025-04-11 12:18 ` Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 11/23] uprobes/x86: Add support to optimize uprobes Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 12/23] selftests/bpf: Use 5-byte nop for x86 usdt probes Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 13/23] selftests/bpf: Reorg the uprobe_syscall test function Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 14/23] selftests/bpf: Rename uprobe_syscall_executed prog to test_uretprobe_multi Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 15/23] selftests/bpf: Add uprobe/usdt syscall tests Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 16/23] selftests/bpf: Add hit/attach/detach race optimized uprobe test Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 17/23] selftests/bpf: Add uprobe syscall sigill signal test Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 18/23] selftests/bpf: Add optimized usdt variant for basic usdt test Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 19/23] selftests/bpf: Add uprobe_regs_equal test Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 20/23] selftests/bpf: Change test_uretprobe_regs_change for uprobe and uretprobe Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 21/23] selftests/bpf: Add 5-byte nop uprobe trigger bench Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 22/23] seccomp: passthrough uprobe systemcall without filtering Jiri Olsa
2025-03-20 11:41 ` [PATCH RFCv3 23/23] selftests/seccomp: validate uprobe syscall passes through seccomp Jiri Olsa
2025-03-20 12:23 ` [PATCH RFCv3 00/23] uprobes: Add support to optimize usdt probes on x86_64 Oleg Nesterov
2025-03-20 13:51 ` Jiri Olsa
2025-04-04 20:36 ` Andrii Nakryiko
2025-04-07 11:17 ` Jiri Olsa
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=20250320114200.14377-8-jolsa@kernel.org \
--to=jolsa@kernel.org \
--cc=David.Laight@ACULAB.COM \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=songliubraving@fb.com \
--cc=thomas@t-8ch.de \
--cc=x86@kernel.org \
--cc=yhs@fb.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;
as well as URLs for NNTP newsgroup(s).