[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.63.1209201212480.1775@stinky-local.trash.net>
Date: Thu, 20 Sep 2012 12:31:37 +0200 (MEST)
From: Patrick McHardy <kaber@...sh.net>
To: Pablo Neira Ayuso <pablo@...monks.org>
cc: Jesper Dangaard Brouer <brouer@...hat.com>,
Florian Westphal <fw@...len.de>,
netfilter-devel <netfilter-devel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>, yongjun_wei@...ndmicro.com.cn
Subject: Re: Oops with latest (netfilter) nf-next tree, when unloading
iptable_nat
>> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
>> index dcb2791..0f241be 100644
>> --- a/net/netfilter/nf_conntrack_core.c
>> +++ b/net/netfilter/nf_conntrack_core.c
>> @@ -1224,6 +1224,8 @@ get_next_corpse(struct net *net, int (*iter)(struct nf_conn *i, void *data),
>> spin_lock_bh(&nf_conntrack_lock);
>> for (; *bucket < net->ct.htable_size; (*bucket)++) {
>> hlist_nulls_for_each_entry(h, n, &net->ct.hash[*bucket], hnnode) {
>> + if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
>> + continue;
>
> I think this will make the deletion of entries via `conntrack -F'
> slowier as we'll have to iterate over more entries (we won't delete
> entries for the reply tuple).
Slightly maybe, but I doubt it makes much of a difference.
> I think I prefer Florian's patch, it's fairly small and it does not
> change the current nf_ct_iterate behaviour or adding some
> nf_nat_iterate cleanup.
I don't think I've received it. Could you forward it to me please?
--
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