On 4/29/2022 3:03 PM, Stephen Hemminger wrote:
On Fri, 29 Apr 2022 14:52:03 -0400
Don Wallwork <d...@xsightlabs.com> wrote:
The expectation is that use of this optional feature would be limited to cases
where the performance gains justify the implications of these tradeoffs. For
example, a specific data plane application may be okay with limited stack size
and could be tested to ensure stack usage remains within limits.
How to identify the required stack size and verify it... If aiming for small
stacks, some instrumentation would be nice, like rte_mempool_audit() and
rte_mempool_list_dump().
Theoretically, a region of memory following the stack could be populated
with a poison pattern that could be audited. Not as robust as hw
mprotect/MMU, but it could provide some protection.
Usually just doing mmap(.., PROT_NONE) will create a page that will cause SEGV
on access
which is what you want.
As mentioned elsewhere, the problem with this is we don't want to
allocate an entire hugepage per stack just to get a guard page.
There is a simple way to verify this. If the application is run without
the hugepage stacks option and it does not seg fault, then we know it is
safe to run the application with the hugepage stacks given the same
thread stack size.
