From: Patrick McHardy <kaber@trash.net>
To: Pekka J Enberg <penberg@cs.helsinki.fi>
Cc: Netfilter Development Mailinglist
<netfilter-devel@vger.kernel.org>,
clameter@sgi.com, joe@perches.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH] netfilter: replace horrible hack with ksize()
Date: Thu, 06 Mar 2008 15:51:07 +0100 [thread overview]
Message-ID: <47D004DB.4010105@trash.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0803061640380.4820@sbz-30.cs.Helsinki.FI>
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?
next prev parent reply other threads:[~2008-03-06 14:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-05 21:20 [PATCH] netfilter: replace horrible hack with ksize() Pekka J Enberg
2008-03-05 21:56 ` Christoph Lameter
2008-03-05 21:57 ` Pekka Enberg
2008-03-05 22:19 ` David Miller
2008-03-06 14:03 ` Patrick McHardy
2008-03-06 14:14 ` Pekka J Enberg
2008-03-06 14:20 ` Pekka J Enberg
2008-03-06 14:35 ` Patrick McHardy
2008-03-06 14:41 ` Pekka J Enberg
2008-03-06 14:51 ` Patrick McHardy [this message]
2008-03-06 15:49 ` Pekka Enberg
2008-03-10 17:57 ` Patrick McHardy
2008-03-06 16:41 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47D004DB.4010105@trash.net \
--to=kaber@trash.net \
--cc=clameter@sgi.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.