Corner cases are slightly non-obvious problems implementing huge pages.  If you think of one, please archive it here so it doesn't come back and bite us later.

 * NUMA-aware allocation - don't want all the memory accesses going through one controller!  See [http://www-941.ibm.com/collaboration/wiki/display/LinuxP/Tuning+stream+with+libhugetlbfs IBM's page about tuning Stream].
   * STREAM and hugetlb is a huge issue unless you have chipset level interleave no matter what
 * Fork of an application with huge pages when no huge pages are left - must fail over to small pages.
 * mmap of a file that is partially in cache already
 * mmap of a file that then gets replaced on disk
  (say glibc text and then glibc gets upgraded to a newer version)
 * MAP_GROWSDOWN for stacks including automatic growth
 * mprotect to executable (scenario: dlopen of a shared lib that
  requires executable stack, causing all thread stacks to be
  mprotected executable)
 * write() of mmaped area to the same file at an offset either
  inside or outside the same 2Mb page
 * same but for an O_DIRECT write
 * same but for AIO write
 * sendfile() of a non-4Kb region
 * truncate of 4Mb mmaped file to 1Mb, then truncate to 1.5Mb
  then 0.5Mb (creates a sparse file)
 * mmap of a 2Mb region in 2 parts: first 1Mb gets mmaped writable private,
  second 2Mb gets mmaped shared writable; then write a few bytes to each part