Date: Tue, 16 May 2006 23:59:10 -0700 (PDT)
Message-Id: <20060516.235910.71774114.davem@davemloft.net>
To: kaber@trash.net
Cc: sfrost@snowman.net, azez@ufomechanic.net, willy@w.ods.org,
       gcoady.lk@gmail.com, laforge@netfilter.org,
       netfilter-devel@lists.netfilter.org, linux-kernel@vger.kernel.org,
       marcelo@kvack.org
Subject: Re: [PATCH] fix mem-leak in netfilter
From: "David S. Miller" <davem@davemloft.net>
In-Reply-To: <446AC1FB.5070406@trash.net>
References: <20060515204142.GO7774@kenobi.snowman.net>
	<20060515210342.GP7774@kenobi.snowman.net>
	<446AC1FB.5070406@trash.net>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1064
Lines: 25

From: Patrick McHardy <kaber@trash.net>
Date: Wed, 17 May 2006 08:26:03 +0200

> Stephen Frost wrote:
> > Looking at this again...  The ttl isn't copied into 'ttl' unless the
> > check_set has TTL turned on.  This means that the overwritting was fine,
> > if you accept that you can only ever match on TTL, or never match on it.
> > That doesn't seem right to me.  The TTL in the table should always be
> > kept up-to-date and the only question is if the current rule requires it
> > for a match or not.
> 
> 
> OK, updated patch attached. The TTL is now always kept up-to-date.

Looks nice.

Is there any reasonable reason to allow ip_pkt_list_tot to ever be
larger than say 255?  If we can accept that limit, we can shrink
the recent_entry considerably by packing the index and nstamps
into a single word next to ttl.
-
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/