From: Jeremy Linton <jeremy.linton@arm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, mhiramat@kernel.org,
peterz@infradead.org, acme@kernel.org, namhyung@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com,
kan.liang@linux.intel.com, thiago.bauermann@linaro.org,
broonie@kernel.org, yury.khrustalev@arm.com,
kristina.martsenko@arm.com, liaochang1@huawei.com,
catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] uprobes: Allow the use of uprobe_warn() in arch code
Date: Wed, 19 Mar 2025 11:40:35 -0500 [thread overview]
Message-ID: <83cf1b26-3a30-47fd-93e9-84903193bf07@arm.com> (raw)
In-Reply-To: <20250319145057.GA10753@redhat.com>
Hi,
On 3/19/25 9:51 AM, Oleg Nesterov wrote:
> On 03/18, Jeremy Linton wrote:
>>
>> --- a/include/linux/uprobes.h
>> +++ b/include/linux/uprobes.h
>> @@ -185,6 +185,7 @@ struct uprobes_state {
>> };
>>
>> extern void __init uprobes_init(void);
>> +extern void uprobe_warn(struct task_struct *t, const char *msg);
>> extern int set_swbp(struct arch_uprobe *aup, struct mm_struct *mm, unsigned long vaddr);
>> extern int set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm, unsigned long vaddr);
>> extern bool is_swbp_insn(uprobe_opcode_t *insn);
>> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
>> index b4ca8898fe17..613c1c76f227 100644
>> --- a/kernel/events/uprobes.c
>> +++ b/kernel/events/uprobes.c
>> @@ -118,7 +118,7 @@ struct xol_area {
>> unsigned long vaddr; /* Page(s) of instruction slots */
>> };
>>
>> -static void uprobe_warn(struct task_struct *t, const char *msg)
>> +void uprobe_warn(struct task_struct *t, const char *msg)
>> {
>> pr_warn("uprobe: %s:%d failed to %s\n", current->comm, current->pid, msg);
>> }
>
> Oh, no, please don't.
>
> uprobe_warn() is ugly and needs changes. If nothing else it doesn't even use
> its "t" argument.
Ha, I didn't look that closely at it. That is basically the same bug 1/7
here is fixing for the gcs task function!
This is in its own patch to allow it to be easily dropped, which is what
will happen as I'm aware of previous variations of this discussion.
While Mark R's perspective is valid, it remains worthwhile to again
point out that the uprobes subsystem (and a few like it) is a bit of a
mystery box. Some of these error conditions are very opaque for a user
who isn't also sufficiently familiar with uprobes to be able to both
find the code as well as understand or instrument it when it tosses an
error. Discoverability is made more difficult by the extensive use of
inline/static. End users try to work around this. For example Brendan
Gregg's perf-tools uprobe wrapper will dump the last two lines of the
kernel log when it hits unexpected errors.
next prev parent reply other threads:[~2025-03-19 16:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 20:48 [PATCH 0/7] arm64: Enable UPROBES with GCS Jeremy Linton
2025-03-18 20:48 ` [PATCH 1/7] arm64/gcs: task_gcs_el0_enable() should use passed task Jeremy Linton
2025-03-19 13:12 ` Mark Brown
2025-03-19 14:26 ` Mark Rutland
2025-03-19 15:03 ` Mark Brown
2025-03-18 20:48 ` [PATCH 2/7] arm64: probes: Break ret out from bl/blr Jeremy Linton
2025-03-18 20:48 ` [PATCH 3/7] arm64: uaccess: Add additional userspace GCS accessors Jeremy Linton
2025-03-19 13:24 ` Mark Brown
2025-03-21 23:43 ` Jeremy Linton
2025-03-25 18:23 ` Mark Brown
2025-03-18 20:48 ` [PATCH 4/7] arm64: probes: Add GCS support to bl/blr/ret Jeremy Linton
2025-03-18 20:48 ` [PATCH 5/7] arm64: uprobes: Add GCS support to uretprobes Jeremy Linton
2025-03-18 20:48 ` [PATCH 6/7] uprobes: Allow the use of uprobe_warn() in arch code Jeremy Linton
2025-03-19 13:32 ` Mark Brown
2025-03-19 14:34 ` Mark Rutland
2025-03-19 14:51 ` Oleg Nesterov
2025-03-19 16:40 ` Jeremy Linton [this message]
2025-03-18 20:48 ` [PATCH 7/7] arm64: Kconfig: Remove GCS restrictions on UPROBES Jeremy Linton
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=83cf1b26-3a30-47fd-93e9-84903193bf07@arm.com \
--to=jeremy.linton@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kristina.martsenko@arm.com \
--cc=liaochang1@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=thiago.bauermann@linaro.org \
--cc=will@kernel.org \
--cc=yury.khrustalev@arm.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
all inboxes | Powered by JetHome®