[aarch64-port-dev ] RFR(xs): Aarch64: ReservedStackAccess may leave stack guard in inconsistent state

[dean.long at oracle.com]

Is there a bug ID for this?  It's not clear to me which repo(s) this is 
targeted
for.

The aarch64 part looks good.

The shared part could be simplified.  There are only 4 guard states, so 
checking
for != to 3 of them is the same as checking for == to the one that is 
allowed.
Also,

2576   assert(_stack_guard_state != stack_guard_unused, "must be using 
guard pages.");
2577   assert(_stack_guard_state != stack_guard_reserved_disabled, 
"already disabled");
2578   assert(_stack_guard_state != 
stack_guard_yellow_reserved_disabled, "loosing information");
2579
2580   // Simply return if called for a thread that does not use guard 
pages.
2581   if (_stack_guard_state == stack_guard_unused) return;
2582
2583   // Already disabled together with yellow pages.
2584   if (_stack_guard_state == stack_guard_yellow_reserved_disabled) 
return;

the if-returns don't seems very useful after the asserts.

dl

On 12/19/18 6:08 AM, Andrey Petushkov wrote:
> Hi All,
>
> Please review small fix for for the following problem: during execution of
> ReservedStackAccess annotated method it might happen that reserved pages
> are reguarded while yellow pages left unguarded. At the same time the state
> of stack guard is recorded as fully protected (stack_guard_enabled).
> Subsequent execution of ReservedStackAccess annotated method then may lead
> to VM crash instead of mere StackOverflowError.
> Reproduced with ReservedStackTestCompiler jtreg test on aarch32-jdk11 port
> codebase. The bug seem to be apparent and exists in aarch64-port as well,
> hence the review request.
> The actual fix is in aarch64-specific code but the shared code is changed
> as well to help to catch such bugs earlier in the future
>
> the link http://cr.openjdk.java.net/~apetushkov/ReservedStackAccess/
>
> Thanks,
> Andrey