From: Sven Schnelle <svens@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-kernel@vger.kernel.org
Subject: kprobes string reading broken on s390
Date: Fri, 5 Jun 2020 13:05:34 +0200 [thread overview]
Message-ID: <20200605110533.GA57038@tuxmaker.boeblingen.de.ibm.com> (raw)
Hi Christoph,
with the latest linux-next i noticed that some tests in the
ftrace test suites are failing on s390, namely:
[FAIL] Kprobe event symbol argument
[FAIL] Kprobe event with comm arguments
The following doesn't work anymore:
cd /sys/kernel/tracing
echo 'p:testprobe _do_fork comm=$comm ' >kprobe_events
echo 1 >/sys/kernel/tracing/events/kprobes/testprobe/enable
cat /sys/kernel/tracing/trace
it will just show
test.sh-519 [012] .... 18.580625: testprobe: (_do_fork+0x0/0x3c8) comm=(fault)
Looking at d411a9c4e95a ("tracing/kprobes: handle mixed kernel/userspace probes
better") i see that there are two helpers for reading strings:
fetch_store_string_user() -> read string from user space
fetch_store_string() -> read string from kernel space(?)
but in the end both are using strncpy_from_user_nofault(), but i would
think that fetch_store_string() should use strncpy_from_kernel_nofault().
However, i'm not sure about the exact semantics of fetch_store_string(),
as there where a lot of wrong assumptions in the past, especially since
on x86 you usually don't fail if you use the same function for accessing kernel
and userspace although it's technically wrong.
Regards,
Sven
commit 81408eab8fcc79dc0871a95462b13176d3446f5e
Author: Sven Schnelle <svens@linux.ibm.com>
Date: Fri Jun 5 13:01:24 2020 +0200
kprobes: use strncpy_from_kernel_nofault() in fetch_store_string()
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index b1f21d558e45..ea8d0b094f1b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1278,7 +1278,7 @@ fetch_store_string(unsigned long addr, void *dest, void *base)
* Try to get string again, since the string can be changed while
* probing.
*/
- ret = strncpy_from_user_nofault(__dest, (void *)addr, maxlen);
+ ret = strncpy_from_kernel_nofault(__dest, (void *)addr, maxlen);
if (ret >= 0)
*(u32 *)dest = make_data_loc(ret, __dest - base);
next reply other threads:[~2020-06-05 11:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-05 11:05 Sven Schnelle [this message]
2020-06-05 13:25 ` Christoph Hellwig
2020-06-05 16:58 ` Masami Hiramatsu
2020-06-05 17:44 ` Sven Schnelle
2020-06-06 7:57 ` Christoph Hellwig
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=20200605110533.GA57038@tuxmaker.boeblingen.de.ibm.com \
--to=svens@linux.ibm.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.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 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®