From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18994 invoked from network); 4 Oct 2021 15:28:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Oct 2021 15:28:33 -0000 Received: (qmail 30094 invoked by uid 550); 4 Oct 2021 15:28:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29912 invoked from network); 4 Oct 2021 15:28:30 -0000 Date: Mon, 4 Oct 2021 11:28:16 -0400 From: Rich Felker To: Jack Bond-Preston Cc: musl@lists.openwall.com Message-ID: <20211004152816.GC2559@brightrain.aerifal.cx> References: <36151c4f-872f-7f84-0402-8491234ea62a@arm.com> <20210930162455.GF4428@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Mallocng algorithm high-level overview On Mon, Oct 04, 2021 at 03:24:28PM +0100, Jack Bond-Preston wrote: > Thanks for the reply Rich, it has been a great help. > > I have a couple more specific questions, sorry: > - Am I correct in saying IB represents the size (in bytes) of the > in-band metadata between slots? > - Is it assumed that sizeof(struct group) == sizeof(UNIT) throughout the > code (the struct is defined such that this is true)? UNIT must be large enough to: - Meet any alignment requirement (be divisible by alignof(max_align_t). - Hold IB bytes of in-band metadata between slots - Fit a group header in UNIT-IB (pad[] in group header must be >= IB) With UNIT==16 this leaves 7 bytes free in the group header on 32-bit archs and 3 bytes free on 64-bit archs. > If the size of the > in-band metadata were to increase (due to additional/larger metadata) > such that UNIT < sizeof(struct group) (due to the size of the group > struct needing to increase to accommodate the larger in-band metadata), > I assume some code would have to be changed to instead use the size of > the new group struct where appropriate (e.g. when allocating some new > group). The fit of small sizeclass groups inside slots of larger ones is dependent on group header fitting in UNIT. While in theory the header could be made larger without hard breakage (assuming cleanup to ensure consistent usage of sizeof(struct group) where appropriate), such a change would break the math that makes things fit together efficiently. In terms of design, group header and in-band metadata ~should not~ be expanded because they are attack surface and are designed to be minimal for their purpose. The active_idx was only added to reduce the physical memory cost/pressure of allocating N slots as a group, due to divisibility properties of the needed sizeclass, when only 1 or 2 slots are wanted. It's not attack surface; clobbering it will just lead to premature use of slots intended to be inactive. > I noticed there are a lot of expressions containing x + > UNIT/UNIT + x, are these generally to ensure allocations etc. include > enough space for the contents of the group struct, or are there other > reasons for these (e.g. some kind of 1-UNIT buffer between slots)? The only space "between" slots is IB. Where UNIT is added it's normally to account for a group header (lines 152, 206, 210, 234, 241, 256, 260, 261, 271, 309). Commit d8715a10b32de699080f820c607db027f0b268b2 in the draft repo documented this somewhat. Rich