Avoiding page reference-count overflows

I think it's a question of tradeoffs (as so much of programming is). Getting an object that uses a refcount_t always succeeds. It may have the side-effect of making the object indestructible, but there's no new rarely-executed, security-critical code-path to test.

get_user_pages() can already fail, so all users should be prepared for that. If not, they're currently a security hole -- consider one thread which calls munmap() on addresses that another thread is passing to a syscall.

refcount_t isn't the appropriate fix for this problem, but is generally a better approach than a silently overflowing / wrapping atomic_t