Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762888AbYCFOvt (ORCPT ); Thu, 6 Mar 2008 09:51:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753746AbYCFOvh (ORCPT ); Thu, 6 Mar 2008 09:51:37 -0500 Received: from viefep31-int.chello.at ([62.179.121.49]:52574 "EHLO viefep31-int.chello.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752345AbYCFOvf (ORCPT ); Thu, 6 Mar 2008 09:51:35 -0500 Message-ID: <47D004DB.4010105@trash.net> Date: Thu, 06 Mar 2008 15:51:07 +0100 From: Patrick McHardy User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Pekka J Enberg CC: Netfilter Development Mailinglist , clameter@sgi.com, joe@perches.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] netfilter: replace horrible hack with ksize() References: <47CFF9B7.5060803@trash.net> <47D0014D.1060901@trash.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1868 Lines: 43 Pekka J Enberg wrote: > On Thu, 6 Mar 2008, Patrick McHardy wrote: >> It decides to reallocate when the remaining space isn't enough >> to hold the new data. NF_CT_EXT_MIN_SIZE is used to make sure it >> doesn't allocate anything smaller than the minimum slab size and >> hopefully avoid reallocations in the future. Unless I'm >> misunderstanding what ksize() does, the easiest way to get >> rid of this would be to replace NF_CT_EXT_MIN_SIZE by ksize(0). > > I think you are misunderstanding ksize() (see mm/slub.c::ksize() for > example). The ksize() description in mm/slab.c matches exactly what netfilter wants to do: * kmalloc may internally round up allocations and return more memory * than requested. ksize() can be used to determine the actual amount of * memory allocated. The caller may use this additional memory, even though * a smaller amount of memory was initially specified with the kmalloc call. > Furthermore, I think your current reallocation code is broken > too as explained in a previous mail and my patch fixes that to behave as > krealloc() does. I don't think there is anything broken with that code. The initial allocation size is calculated as max(size, min slab size) and is stored as ext->alloc_size. When adding the first extension, it allocates ext->alloc_size of memory and stores both the real amount of space used (ext->len) and the actual size (ext->real_len). When adding further extensions, it calculates the new total amount of space needed (newlen). If that is larger than the real amount of memory allocated (real_len), it reallocates. What am I missing here? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/