From: "Björn Töpel" <bjorn@kernel.org>
To: linux-riscv@lists.infradead.org, Guo Ren <guoren@kernel.org>
Cc: bpf@vger.kernel.org, Hou Tao <houtao@huaweicloud.com>,
yonghong.song@linux.dev,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Puranjay Mohan <puranjay12@gmail.com>
Subject: RISC-V uprobe bug (Was: Re: WARNING: CPU: 3 PID: 261 at kernel/bpf/memalloc.c:342)
Date: Sat, 26 Aug 2023 15:44:48 +0200 [thread overview]
Message-ID: <87v8d19aun.fsf@all.your.base.are.belong.to.us> (raw)
In-Reply-To: <87jztjmmy4.fsf@all.your.base.are.belong.to.us>
Björn Töpel <bjorn@kernel.org> writes:
> I'm chasing a workqueue hang on RISC-V/qemu (TCG), using the bpf
> selftests on bpf-next 9e3b47abeb8f.
>
> I'm able to reproduce the hang by multiple runs of:
> | ./test_progs -a link_api -a linked_list
> I'm currently investigating that.
+Guo for uprobe
This was an interesting bug. The hang is an ebreak (RISC-V breakpoint),
that puts the kernel into an infinite loop.
To reproduce, simply run the BPF selftest:
./test_progs -v -a link_api -a linked_list
First the link_api test is being run, which exercises the uprobe
functionality. The link_api test completes, and test_progs will still
have the uprobe active/enabled. Next the linked_list test triggered a
WARN_ON (which is implemented via ebreak as well).
Now, handle_break() is entered, and the uprobe_breakpoint_handler()
returns true exiting the handle_break(), which returns to the WARN
ebreak, and we have merry-go-round.
Lucky for the RISC-V folks, the BPF memory handler had a WARN that
surfaced the bug! ;-)
This patch fixes the issue, but it's probably a prettier variant:
--8<--
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index f798c853bede..1198cb879d2f 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -248,23 +248,29 @@ static inline unsigned long get_break_insn_length(unsigned long pc)
void handle_break(struct pt_regs *regs)
{
+ bool user = user_mode(regs);
+
#ifdef CONFIG_KPROBES
- if (kprobe_single_step_handler(regs))
- return;
+ if (!user) {
+ if (kprobe_single_step_handler(regs))
+ return;
- if (kprobe_breakpoint_handler(regs))
- return;
+ if (kprobe_breakpoint_handler(regs))
+ return;
+ }
#endif
#ifdef CONFIG_UPROBES
- if (uprobe_single_step_handler(regs))
- return;
+ if (user) {
+ if (uprobe_single_step_handler(regs))
+ return;
- if (uprobe_breakpoint_handler(regs))
- return;
+ if (uprobe_breakpoint_handler(regs))
+ return;
+ }
#endif
current->thread.bad_cause = regs->cause;
- if (user_mode(regs))
+ if (user)
force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)regs->epc);
#ifdef CONFIG_KGDB
else if (notify_die(DIE_TRAP, "EBREAK", regs, 0, regs->cause, SIGTRAP)
--8<--
I'll cook a cleaner/proper patch for this, unless the uprobes folks has
a better solution.
Björn
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-08-26 13:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-25 10:32 WARNING: CPU: 3 PID: 261 at kernel/bpf/memalloc.c:342 Björn Töpel
2023-08-25 15:28 ` Yonghong Song
2023-08-25 18:53 ` Alexei Starovoitov
2023-08-25 19:49 ` Alexei Starovoitov
2023-08-25 21:31 ` Andrii Nakryiko
2023-08-26 22:49 ` Kumar Kartikeya Dwivedi
2023-08-26 3:48 ` Hou Tao
2023-08-26 9:23 ` Björn Töpel
2023-08-26 10:27 ` Hou Tao
2023-08-26 10:49 ` Björn Töpel
2023-08-27 8:37 ` Björn Töpel
2023-08-27 14:53 ` Yonghong Song
2023-08-28 13:57 ` Hou Tao
2023-08-29 0:54 ` Yonghong Song
2023-08-29 7:26 ` Björn Töpel
2023-08-29 11:46 ` Björn Töpel
2023-08-30 12:15 ` Hou Tao
2023-08-29 12:54 ` Björn Töpel
2023-08-29 15:26 ` Alexei Starovoitov
2023-08-30 12:08 ` Hou Tao
2023-08-30 21:05 ` Alexei Starovoitov
2023-08-26 13:44 ` Björn Töpel [this message]
2023-08-26 18:12 ` RISC-V uprobe bug (Was: Re: WARNING: CPU: 3 PID: 261 at kernel/bpf/memalloc.c:342) Nam Cao
2023-08-26 18:31 ` Nam Cao
2023-08-27 8:11 ` Björn Töpel
2023-08-27 8:35 ` Nam Cao
2023-08-27 9:04 ` Björn Töpel
2023-08-27 9:39 ` Nam Cao
2023-08-27 19:20 ` Björn Töpel
2023-08-27 19:41 ` Nam Cao
2023-08-27 20:15 ` Nam Cao
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=87v8d19aun.fsf@all.your.base.are.belong.to.us \
--to=bjorn@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=guoren@kernel.org \
--cc=houtao@huaweicloud.com \
--cc=linux-riscv@lists.infradead.org \
--cc=puranjay12@gmail.com \
--cc=yonghong.song@linux.dev \
/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