From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org,
Andy Lutomirski <luto@amacapital.net>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Changbin Du <changbin.du@gmail.com>, Jann Horn <jannh@google.com>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@kernel.org>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Nadav Amit <namit@vmware.com>,
Joel Fernandes <joel@joelfernandes.org>,
yhs@fb.com
Subject: Re: [RFC PATCH v6 1/6] x86/uaccess: Allow access_ok() in irq context if pagefault_disabled
Date: Thu, 21 Mar 2019 22:46:02 -0400 [thread overview]
Message-ID: <20190321224602.1e31aded@oasis.local.home> (raw)
In-Reply-To: <155289139725.7218.17265500814527931961.stgit@devnote2>
On Mon, 18 Mar 2019 15:43:17 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> WARN_ON_IN_IRQ() assumes that the access_ok() and following
> user memory access can sleep. But this assumption is not
> always correct; when the pagefault is disabled, following
> memory access will just returns -EFAULT and never sleep.
>
> Add pagefault_disabled() check in WARN_ON_ONCE() so that
> it can ignore the case we call it with disabling pagefault.
> For this purpose, this modified pagefault_disabled() as
> an inline function.
>
Actually, accessing user space from an interrupt doesn't really make
sense. Now I'm differentiating a true interrupt (like a device handler)
from an exception. The difference is that an exception is synchronous
with the execution of the code, but an interrupt is something where you
don't know what task is running. A uaccess in this type of interrupt
will randomly grab some user space memory but have no idea what task is
running.
The one time this makes sense is if you are doing some kind of
profiling, where the randomness is fine.
I'm curious, what interrupt handler are kprobes executing in that needs
random user space addresses?
-- Steve
next prev parent reply other threads:[~2019-03-22 2:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-18 6:42 [RFC PATCH v6 0/6] tracing/probes: uaccess: Add support user-space access Masami Hiramatsu
2019-03-18 6:43 ` [RFC PATCH v6 1/6] x86/uaccess: Allow access_ok() in irq context if pagefault_disabled Masami Hiramatsu
2019-03-22 2:46 ` Steven Rostedt [this message]
2019-05-06 15:22 ` Masami Hiramatsu
2019-05-06 15:39 ` Steven Rostedt
2019-03-18 6:43 ` [RFC PATCH v6 2/6] uaccess: Add non-pagefault user-space read functions Masami Hiramatsu
2019-03-18 6:43 ` [RFC PATCH v6 3/6] tracing/probe: Add ustring type for user-space string Masami Hiramatsu
2019-03-18 6:43 ` [RFC PATCH v6 4/6] tracing/probe: Support user-space dereference Masami Hiramatsu
2019-05-06 15:52 ` Steven Rostedt
2019-05-08 4:11 ` Masami Hiramatsu
2019-05-08 15:22 ` Steven Rostedt
2019-05-13 12:11 ` Masami Hiramatsu
2019-03-18 6:44 ` [RFC PATCH v6 5/6] selftests/ftrace: Add user-memory access syntax testcase Masami Hiramatsu
2019-03-18 6:44 ` [RFC PATCH v6 6/6] perf-probe: Add user memory access attribute support Masami Hiramatsu
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=20190321224602.1e31aded@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=changbin.du@gmail.com \
--cc=jannh@google.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.org \
--cc=torvalds@linux-foundation.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).