The steps of the technique to replace stack with hugetlbfs map are as
follows:
(1) Prepare a hugetlbfs map with the size of rlim_cur
(2) Copy the active region of the stack to the hugetlbfs map.
The range to copy is determined by reading /proc/[pid]/maps.
(3) Replace the stack map with the hugetlbfs map
The step (2) tries to copy a huge region if McKernel doesn't grow the
stack at run-time.
Change-Id: I5858c35b5c26dd0a42cccf9e3cc4c64b1a81f160
* manage pages by an array
* fix mmap of fd created by memfd_create() populates the map
* refactor pgsize and pgshift handling
Change-Id: Icaf015b10afc35f2b95f93059adf1a1b6b92e14e
refs: #1475
We do not need two debug.h files.
Take Fujitsu's STATIC_ASSERT over BUILD_BUG_ON because it is more used
Change-Id: If04c17fbb7406ab15fe86267fed8d6da460cec62
Fujitsu: POSTK_DEBUG_ARCH_DEP_9
Hugetlbfs file mappings are handled differently than regular files:
- pager_req_create will tell us the file is in a hugetlbfs
- allocate memory upfront, we need to fail if not enough memory
- the memory needs to be given again if another process maps the same
file
This implementation still has some hacks, in particular, the memory
needs to be freed when all mappings are done and the file has been
deleted/closed by all processes.
We cannot know when the file is closed/unlinked easily, so clean up
memory when all processes have exited.
To test, install libhugetlbfs and link a program with the additional
LDFLAGS += -B /usr/share/libhugetlbfs -Wl,--hugetlbfs-align
Then run with HUGETLB_ELFMAP=RW set, you can check this works with
HUGETLB_DEBUG=1 HUGETLB_VERBOSE=2
Change-Id: I327920ff06efd82e91b319b27319f41912169af1
