On Friday 18 April 2008 21:31:20 Andrew Morton wrote:
I tested it when I wrote it, but just wrote a tester again:
base len npages
0 1 1
0xfff 1 1
0x1000 1 1
0 4096 1
0x1 4096 2
0xfff 4096 2
0x1000 4096 1
0xfffff000 4096 1
0xfffff000 4097 4293918722
Since only root can open the tun device, it's currently OK. The old code
kmalloced and copied: is there some mm-fu reason why pinning userspace memory
is worse?
But I actually think it's OK even for non-root, since these become skbs, which
means they either go into an outgoing device queue or a socket queue which is
accounted for exactly for this reason.
Damn, you had me reworking this until I realized why. It's not: we're
inside a loop, doing one iovec array element at a time.
To simplify the failure path. Hmm, I would use release_pages here...
... but I didn't know that existed. Had to include pagemap.h, and it's not
exported. It seems to be a useful interface; see patch.
Cheers,
Rusty.
Subject: Export release_pages; nice undo for get_user_pages.
Andrew Morton suggests tun/tap use release_pages, but it's not
exported. It's not clear to me why this is in swap.c, but it exists
even without CONFIG_SWAP, so that's OK.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r abd2ad431e5c mm/swap.c
--- a/mm/swap.c Sat Apr 19 00:34:54 2008 +1000
+++ b/mm/swap.c Sat Apr 19 01:11:40 2008 +1000
@@ -346,6 +346,7 @@ void release_pages(struct page **pages,
pagevec_free(&pages_to_free);
}
+EXPORT_SYMBOL(release_pages);
/*
* The pages which we're about to release may be in the deferred lru-addition
--