[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070428175254.DA5DF151CA@wotan.suse.de>
Date: Sat, 28 Apr 2007 19:52:54 +0200 (CEST)
From: Andi Kleen <ak@...e.de>
To: "Aneesh Kumar K.V" <aneesh.kumar@...il.com>,
linux-kernel@...r.kernel.org, patches@...-64.org
Subject: [PATCH] [29/35] i386: Update __copy_to_user_inatomic linuxdoc description
From: "Aneesh Kumar K.V" <aneesh.kumar@...il.com>
Explicity specify that the caller should pin the user memory
otherwise the function will sleep
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...il.com>
Signed-off-by: Andi Kleen <ak@...e.de>
---
include/asm-i386/uaccess.h | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
Index: linux/include/asm-i386/uaccess.h
===================================================================
--- linux.orig/include/asm-i386/uaccess.h
+++ linux/include/asm-i386/uaccess.h
@@ -397,7 +397,19 @@ unsigned long __must_check __copy_from_u
unsigned long __must_check __copy_from_user_ll_nocache_nozero(void *to,
const void __user *from, unsigned long n);
-/*
+/**
+ * __copy_to_user_inatomic: - Copy a block of data into user space, with less checking.
+ * @to: Destination address, in user space.
+ * @from: Source address, in kernel space.
+ * @n: Number of bytes to copy.
+ *
+ * Context: User context only.
+ *
+ * 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 the we don't result in page fault and sleep.
+ *
* Here we special-case 1, 2 and 4-byte copy_*_user invocations. On a fault
* we return the initial request size (1, 2 or 4), as copy_*_user should do.
* If a store crosses a page boundary and gets a fault, the x86 will not write
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists