RFR: 8263476: Use reserved memory for stack guard pages [v3]
    Thomas Stuefe 
    stuefe at openjdk.org
       
    Fri Aug  8 15:23:26 UTC 2025
    
    
  
On Wed, 6 Aug 2025 11:40:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
> > Apart from being hard to understand, it also opens a time window where the stack guard pages are unmapped;
> 
> Could you elaborate which part is hard to understand? I think the newly added diagram illustrates the stack-frame clearly.
Why we first unmap the stack area to then re-map it again, leading to the potential race I mentioned.
> 
> > but in this time window someone else may have mapped pages in there.
> 
> Since Linux main-thread dynamically reserves memory for stack, it's always possible that address-ranges smaller than stack-top (including stack-guard-pages) are already reserved by others.
Sorry, you lost me. What is stack_top in your description? Lowest or highest address? 
Are you saying that parts of the stack, including what is supposed to carry the stack guard, can be reserved by others? That cannot be true, otherwise we would destroy their mappings. Since we do an unconditional munmap, I assume the underlying pages are guaranteed to belong to this stack.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3168286572
    
    
More information about the hotspot-runtime-dev
mailing list