https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894
--- Comment #9 from Kurt Miller <k...@intricatesoftware.com> ---
(In reply to Konstantin Belousov from comment #7)
Answering your questions:
Attempting execute code on the stack I believe with raise a SIGSEGV.
The JVM uses pthread stacks.
Currently the jvm does an mmap(MAP_ANON) before an mprotect(PROT_NONE) on the
Hotspot Guard pages at the end of the stack as reported by
pthread_attr_getstack(). On 13-current, the kernel moves the kernel managed
guard page as follows:
Low memory addresses
+------------------------+
| |\ Java thread created by VM does not have
| pthread guard page | - pthread guard, attached Java thread usually
| |/ has 1 pthread guard page.
P1 +------------------------+ Thread::stack_base() - Thread::stack_size()
| |\
| HotSpot Guard Pages | - red, yellow and reserved pages
| |/
+------------------------+ JavaThread::stack_reserved_zone_base()
| |\
| kernel guard page(s) | - This page is the problem
| |/
+------------------------+ JavaThread::stack_reserved_zone_base()
| |\
| Normal Stack | -
| |/
P2 +------------------------+ Thread::stack_base()
The kernel managed guard page follows the HotSpot Guard pages which poses two
problems.
1) SIGSEGV raised before hitting the HotSpot Guard Pages (executing code on
stack?)
2) The inability to change the protection on the kernel guard pages so that the
thread that hit it can be allowed to temporarily use that space so it can
unwind safely.
Please see test program for this case in this comment:
https://github.com/battleblow/openjdk-jdk11u/issues/51#issuecomment-520602973
I encourage you to look at this issue from the perspective of the issues in
libthr I outlined in comment #1 instead of from the JVM's needs. If the issues
in libthr are corrected, it is very likely that the JVM can use the same
approach as libthr to place guard pages at the end of the stack.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
