From: Steven Rostedt <rostedt@goodmis.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, Kees Cook <keescook@chromium.org>,
Aleksa Sarai <cyphar@cyphar.com>,
Al Viro <viro@ZenIV.linux.org.uk>
Subject: [PATCH] uaccess: Comment that copy to/from inatomic requires page fault disabled
Date: Wed, 10 Sep 2025 16:18:20 -0400 [thread overview]
Message-ID: <20250910161820.247f526a@gandalf.local.home> (raw)
From: Steven Rostedt <rostedt@goodmis.org>
The functions __copy_from_user_inatomic() and __copy_to_user_inatomic()
both require that either the user space memory is pinned, or that page
faults are disabled when they are called. If page faults are not disabled,
and the memory is not present, the fault handling of reading or writing to
that memory may cause the kernel to schedule. That would be bad in an
atomic context.
Link: https://lore.kernel.org/all/20250819105152.2766363-1-luogengkun@huaweicloud.com/
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
include/linux/uaccess.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 1beb5b395d81..add99fa9b656 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -86,6 +86,12 @@
* as usual) and both source and destination can trigger faults.
*/
+/*
+ * __copy_from_user_inatomic() is safe to use in an atomic context but
+ * the user space memory must either be pinned in memory, or page faults
+ * must be disabled, otherwise the page fault handling may cause the function
+ * to schedule.
+ */
static __always_inline __must_check unsigned long
__copy_from_user_inatomic(void *to, const void __user *from, unsigned long n)
{
@@ -124,7 +130,8 @@ __copy_from_user(void *to, const void __user *from, unsigned long n)
* Copy data from kernel space to user space. Caller must check
* the specified block with access_ok() before calling this function.
* The caller should also make sure he pins the user space address
- * so that we don't result in page fault and sleep.
+ * or call page_fault_disable() so that we don't result in a page fault
+ * and sleep.
*/
static __always_inline __must_check unsigned long
__copy_to_user_inatomic(void __user *to, const void *from, unsigned long n)
--
2.50.1
next reply other threads:[~2025-09-10 20:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 20:18 Steven Rostedt [this message]
2025-09-12 1:07 ` Masami Hiramatsu
2025-09-15 15:43 ` David Laight
2025-09-15 23:37 ` Steven Rostedt
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=20250910161820.247f526a@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=cyphar@cyphar.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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