The trouble with get_user_pages()

FWIW, a big problem with that approach is that get_user_pages_fast() is pretty much lost after that. As it is, a good way to think of get_user_pages_fast() is to consider it a simulated TLB miss. If we manage to resolve that out of page tables, everything's nice and fast (and lockless, at that). If we run into something trickier, that simulated TLB miss escalates into a full-blown simulated page fault, which is where we start grabbing locks, hitting page cache, doing allocations, hitting disk, etc. That's what "_fast" in get_user_pages_fast() is about and that's what we lose with that approach. Even finding out which (if any) file is backing the area we are hitting requires pretty much the full-blown page fault locking.

Doing that for the sake of infinibad playing silly buggers with long-term page references looks like a bad idea - the interface is used for a lot more than that and punishing the regular users that way is not an appealing prospect...