From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 31A963858C31; Wed, 6 Dec 2023 11:57:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31A963858C31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1701863835; bh=ko2Wz71LyQ6Zb2BRNI1PM7I4c/9+lUGvmRMiW947DMo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ijYYuwNJJFQENrAvAODqydXysxniyCd975iDmNEmGd9GurXnKkZJBoYVZkvcq7B9S HgaJdrm2/shOPnfirvsbw1o7on+vqqn7N2CiTm6oqLqUcLU2Syo2vyuliSMyRNLED5 Vgeex5O/xOSjLk5+u9SPSSFQYsF2vY9bWW3r0+fI= From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/31076] Extra struct vm_area_struct with ---p created when PAGE_SIZE < max-page-size Date: Wed, 06 Dec 2023 11:57:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31076 --- Comment #18 from Florian Weimer --- (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 voi= d? That's my understanding. The current behavior gives programmers the *option= * to avoid mapping extra code on small-page systems, while maintaining compatibi= lity with large-page systems. The proposed change to over-map to the next load-segment, to fill the gap, would take away that option. Unmapping (to create a gap) has compatibility implications. 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. The link editor merely needs to over-map in the generated LOAD segments, then there won't be any gaps for t= he loader to process. --=20 You are receiving this mail because: You are on the CC list for the bug.=