hugetlb_vmtruncate_list was misconverted to prio_tree: its prio_tree is in units
of PAGE_SIZE (PAGE_CACHE_SIZE) like any other, not HPAGE_SIZE (whereas its
radix_tree is kept in units of HPAGE_SIZE, otherwise slots would be absurdly
sparse).

At first I thought the error benign, just calling __unmap_hugepage_range on more
vmas than necessary; but on 32-bit machines, when the prio_tree is searched
correctly, it happens to ensure the v_offset calculation won't overflow.  As it
stood, when truncating at or beyond 4GB, it was liable to discard pages COWed
from lower offsets; or even to clear pmd entries of preceding vmas, triggering
exit_mmap's BUG_ON(nr_ptes).