On 6/10/19 12:38 PM, Yu-cheng Yu wrote: >>> When an application starts, its highest stack address is determined. >>> It uses that as the maximum the bitmap needs to cover. >> Huh, I didn't think we ran code from the stack. ;) >> >> Especially given the way that we implemented the new 5-level-paging >> address space, I don't think that expecting code to be below the stack >> is a good universal expectation. > Yes, you make a good point. However, allowing the application manage the bitmap > is the most efficient and flexible. If the loader finds a legacy lib is beyond > the bitmap can cover, it can deal with the problem by moving the lib to a lower > address; or re-allocate the bitmap. How could the loader reallocate the bitmap and coordinate with other users of the bitmap? > If the loader cannot allocate a big bitmap to cover all 5-level > address space (the bitmap will be large), it can put all legacy lib's > at lower address. We cannot do these easily in the kernel. This is actually an argument to do it in the kernel. The kernel can always allocate the virtual space however it wants, no matter how large. If we hide the bitmap behind a kernel API then we can put it at high 5-level user addresses because we also don't have to worry about the high bits confusing userspace.
