[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49A404C7.1010900@trash.net>
Date: Tue, 24 Feb 2009 15:31:35 +0100
From: Patrick McHardy <kaber@...sh.net>
To: Eric Dumazet <dada1@...mosbay.com>
CC: Stephen Hemminger <shemminger@...tta.com>,
David Miller <davem@...emloft.net>,
Rick Jones <rick.jones2@...com>, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org
Subject: Re: [PATCH] iptables: xt_hashlimit fix
Eric Dumazet wrote:
> Damned this broke xt_hashlimit, version=0
>
> ...
> So, it appears some modules are using pointers to themselves, what a hack :(
Indeed. This is unfortunately necessary in some cases to make sure
that modules using global state actually use global state instead
of the per-CPU copies.
> We probably need an audit of other modules.
>
> (net/netfilter/xt_statistic.c, net/netfilter/xt_quota.c,
> net/netfilter/xt_limit.c ...)
This seems fine in case of hashlimit since it the match data
is read-only. In case of statistic and quota I think we still
need it I think.
> Unfortunatly I wont have time to do this in following days, any volunteer ?
>
> Thank you
>
> [PATCH] netfilter: xt_hashlimit fix
>
> Commit 784544739a25c30637397ace5489eeb6e15d7d49
> (netfilter: iptables: lock free counters) broke xt_hashlimit netfilter module :
>
> This module was storing a pointer inside its xt_hashlimit_info, and this pointer
> is not relocated when we temporarly switch tables (iptables -L).
>
> This hack is not not needed at all (probably a leftover from
> ancient time), as each cpu should and can access to its own copy.
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists