From: Christoph Hellwig <hch@lst.de>
To: Sven Schnelle <svens@linux.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: kprobes string reading broken on s390
Date: Fri, 5 Jun 2020 15:25:41 +0200 [thread overview]
Message-ID: <20200605132541.GB31829@lst.de> (raw)
In-Reply-To: <20200605110533.GA57038@tuxmaker.boeblingen.de.ibm.com>
Yes, this looks correct. You probably want to write a small changelog
and add a Fixes tag, though.
On Fri, Jun 05, 2020 at 01:05:34PM +0200, Sven Schnelle wrote:
> 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);
>
---end quoted text---
next prev parent reply other threads:[~2020-06-05 13:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-05 11:05 Sven Schnelle
2020-06-05 13:25 ` Christoph Hellwig [this message]
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=20200605132541.GB31829@lst.de \
--to=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=svens@linux.ibm.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®