[Bug dynamic-link/31076] Extra struct vm_area_struct with ---p created when PAGE_SIZE < max-page-size

["i at maskray dot me" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31076

--- Comment #19 from Fangrui Song <i at maskray dot me> ---
(In reply to Florian Weimer from comment #18)
> (In reply to Kalesh Singh from comment #15)
> > AIUI if the runtime-page-size equals the max-page-size, the holes are also
> > mapped in as part of the segment mapping and share the same permissions.
> > Does this mean that on such systems, any protection it offers becomes void?
> 
> That's my understanding. The current behavior gives programmers the *option*
> to avoid mapping extra code on small-page systems, while maintaining
> compatibility with large-page systems. The proposed change to over-map to
> the next load-segment, to fill the gap, would take away that option.

Can you elaborate what the option (and "functionality" below) is? Since
22930c9bf21ea15d0da1477a379029e2de259b69 (1996) rtld just calls `mprotect` (one
extra `struct vm_area_struct` instance, see `sudo grep vm_area_struct
/proc/slabinfo`), and the user has no option to control this behavior.

> Unmapping (to create a gap) has compatibility implications.

I wonder the implications are. If they are related to l_contiguous not
accounted for correctly, the user needs to be fixed.

> Just to clarify, I'm opposed to a glibc change here mainly because it's not
> necessary to enable the desired behavior (fewer VMAs), and it removes
> functionality that people might find useful.

See my question above.

> The link editor merely needs to over-map in the generated LOAD segments, then
> there won't be any gaps for the loader to process.

I have thought about this but I feel that a linker change would be intrusive
and unsightly: "I've also pondered whether this falls under the purview of
linkers." in comment 17.

-- 
You are receiving this mail because:
You are on the CC list for the bug.