Thread (46 messages) 46 messages, 6 authors, 2019-06-25

Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2019-06-21 15:54:18
Also in: linux-mips, linux-sh, linuxppc-dev, lkml, sparclinux

On Fri, Jun 21, 2019 at 09:35:11AM -0600, Khalid Aziz wrote:
On 6/21/19 7:39 AM, Jason Gunthorpe wrote:
quoted
On Tue, Jun 11, 2019 at 04:40:47PM +0200, Christoph Hellwig wrote:
quoted
This will allow sparc64 to override its ADI tags for
get_user_pages and get_user_pages_fast.

Signed-off-by: Christoph Hellwig <hch@lst.de>
 mm/gup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index ddde097cf9e4..6bb521db67ec 100644
+++ b/mm/gup.c
@@ -2146,7 +2146,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
 	unsigned long flags;
 	int nr = 0;
 
-	start &= PAGE_MASK;
+	start = untagged_addr(start) & PAGE_MASK;
 	len = (unsigned long) nr_pages << PAGE_SHIFT;
 	end = start + len;
Hmm, this function, and the other, goes on to do:

        if (unlikely(!access_ok((void __user *)start, len)))
                return 0;

and I thought that access_ok takes in the tagged pointer?

How about re-order it a bit?
access_ok() can handle tagged or untagged pointers. It just strips the
tag bits from the top bits. Current order doesn't really matter from
functionality point of view. There might be minor gain in delaying
untagging in __get_user_pages_fast() but I could go either way.
I understand the current ARM and SPARC implementations don't do much
with the tags, but it feels like a really big assumption for the core
code that all future uses of tags will be fine to have them stripped
out of 'void __user *' pointers. IMHO that is something we should not
be doing in the core kernel..

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help