From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E6D373858D35 for ; Fri, 2 Dec 2022 04:43:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6D373858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669956190; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=uWyvhQvJYZvPb4VAgywYqFqPBVmhnTXWcAOH4745kwM=; b=c9GYP3LkO1uVONhu7fcHOL96WS1OjwPCAwOXr0dvYCmgyiKJM0QNr355u+VYiRzRwCQvPY zdC+fXFUeCGCqPwEc004cu4k6KXx+b9+LoSU9Xqyb8/4z4w+GqyGCDeq6/Wogprf1mnjcq owTtPdlHtVzFoeV/AuVe3BCILazusCw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-470-TH5-aHGxOfuUYbdeC7_dbw-1; Thu, 01 Dec 2022 23:43:09 -0500 X-MC-Unique: TH5-aHGxOfuUYbdeC7_dbw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 29B36886065; Fri, 2 Dec 2022 04:43:09 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 15DF8202279C; Fri, 2 Dec 2022 04:43:09 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 2B24gvY5997634; Thu, 1 Dec 2022 23:42:57 -0500 From: DJ Delorie To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org Subject: Re: [RFC] Supporting malloc_usable_size In-Reply-To: <20221124213258.305192-1-siddhesh@gotplt.org> Date: Thu, 01 Dec 2022 23:42:57 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Siddhesh Poyarekar writes: > At that time, I thought this use was to avoid reallocating[1] when You can't do an optimal realloc if you don't know what the usable size is, but once you know the optimal size, calling realloc() should be a valid way of telling the compiler what you're doing. We just need to ensure that our realloc() does the sane thing in such cases and I see no problem with users doing it. > that maybe providing a fast path for cases where the new > size was within the current chunk size was the solution to the problem > systemd was trying to solve with malloc_usable_size. I think a fast path check would be good for performance anyway, but let's not call it a solution, because it won't change the functionality, just the speed. > it is used as a way to query sizes of objects and hence eliminating > the need to pass their corresponding sizes. Since malloc_usable_size is nonstandard and intended for debugging, this is a bad programming practice (as noted in the man page). As such, I see no need to spend effort on it, either to block it or to optimize it. Caveat programmer. As long as the function returns the correct value, I have no desire to worry about it further ;-) > I have an idea to support this abuse and at the same time, satisfy the > compiler by giving it a hint of the new size. That's a lot of work to avoid a call to realloc(). And if they're calling into libc to get a record size, they already don't care about optimal performance. > The larger consequence of this patch though is that we further support > the usage of malloc_usable_size for cases beyond diagnostics. Do we > want to do that? To what extend do we support it *at all*, other than "it returns the right number at the time it was called" ? > If we do, should we also then make clear what kind of usage we support > as a library, say, in the manual? Our man page already says "The main use of this function is for debugging and introspection". The BSD manual says "The malloc_usable_size() function is not a mechanism for in-place realloc(); rather it is provided solely as a tool for introspection purposes." So clarifying the manual to be more in line with BSD is probably OK but anything further than that is IMHO an API change. We may want to add a caveat that the returned value is only valid until the next call to any malloc family function, though, although I don't see any way our code could make the usable size of an allocated chunk *smaller*. I don't think we've ever guaranteed that the heap metadata is constant. Maybe as a lark we could make 1% of the calls return an obviously wrong value? ;-)