From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 14:10:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34D5187C for ; Thu, 28 Nov 2013 14:10:55 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id EB54D101B for ; Thu, 28 Nov 2013 14:10:53 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4DFB37300B; Thu, 28 Nov 2013 15:06:37 +0100 (CET) Date: Thu, 28 Nov 2013 15:06:37 +0100 From: Luigi Rizzo To: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <20131128140637.GA62346@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 14:10:55 -0000 On Thu, Nov 28, 2013 at 01:33:41PM +0000, jb wrote: > Luigi Rizzo iet.unipi.it> writes: > > > > > in porting some linux kernel code to FreeBSD we > > stumbled upon ksize(), which returns the > > actual size of a kmalloc() block. > > > > We could easily implement it as the first part > > of realloc(9) -- see kern/kern_malloc.c > > > > Would it make sense to add this to the malloc(9) API ? > > The userspace equivalent seems to be > > malloc_usable_size(3) which according to the > > manpage appeared in FreeBSD 7.0 > > Hi, > > The implementation of ksize() depends on (has non-standard behavior across) > architectures, memory allocators, page sizes, C libs, etc. > > It means, ksize() exports its implementation details to the caller, and this > disqualifies it, regardless whether in kernel or user spaces. > > This leads to dangerous and conflicting assertions: > > malloc_usable_size(3) on Linux: > NOTES > The value returned by malloc_usable_size() may be greater than the > requested size of the allocation because of alignment and minimum size > constraints. Although the excess bytes can be overwritten by the > application without ill effects, this is not good programming practice: > the number of excess bytes in an allocation depends on the underlying > implementation. > > The main use of this function is for debugging and introspection. This is the same exact text we have in the FreeBSD manpage, and exactly the behaviour of ksize() in the linux kernel (and exactly the semantics that our realloc(9) relies upon). While I personally prefer that applications call realloc() directly, there might be cases where the decision is best left to the application (or kernel code): e.g. say you would like to get some extra space, but would rather do without it than risk a malloc() failure or having to sleep for the allocation. And there is also a (minor) issue of portability of code. But I don't understand why you find ksize()/malloc_usable_size() dangerous. Of course the result depends on the underlying implementation, but this happens in a ton of places including compiler behaviour and system calls. The danger is when the programmer makes assumptions that do not match reality, but the purpose of this call seems to be exactly the opposite: avoid making assumptions. cheers luigi