[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikkz23221ZSiat8N5tnE_bkHN=1EUNQTDdnC30L@mail.gmail.com>
Date: Wed, 2 Mar 2011 22:37:11 +0800
From: Changli Gao <xiaosuo@...il.com>
To: Patrick McHardy <kaber@...sh.net>
Cc: "Oleg A. Arkhangelsky" <sysoleg@...dex.ru>,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
Paul E McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
On Wed, Mar 2, 2011 at 7:37 PM, Patrick McHardy <kaber@...sh.net> wrote:
> Am 23.02.2011 18:07, schrieb "Oleg A. Arkhangelsky":
>> Hello,
>>
>> Got this panic yesterday:
>> http://www.progtech.ru/~oleg/crash.txt
>>
>> The offending instruction is:
>> cmpb 54(%edx), %cl # <variable>.tuple.dst.protonum,
>>
>> and here is the assembler code of net/ipv4/netfilter/nf_nat_core.c:
>> http://www.progtech.ru/~oleg/nf_nat_core.s
>>
>> Quick investigation lead me to conclusion that the problem is in
>> return of same_src function:
>>
>> return (t->dst.protonum == tuple->dst.protonum &&
>> t->src.u3.ip == tuple->src.u3.ip &&
>> t->src.u.all == tuple->src.u.all);
>>
>> So either t or tuple pointer is bad, but I don't understand how
>> this can be.
>
t should be NULL here, as offsetof(struct nf_conn, dst.protonum) == 0x36.
We should free the nf_ct_extend with call_rcu(), since nat ext is
referenced in the rcu read context.
717 void nf_conntrack_free(struct nf_conn *ct)
718 {
719 struct net *net = nf_ct_net(ct);
720
721 nf_ct_ext_destroy(ct);
722 atomic_dec(&net->ct.count);
723 nf_ct_ext_free(ct);
if (ct->ext)
call_rcu(&ct->ext->rcu, __nf_ct_ext_free_rcu);
724 kmem_cache_free(net->ct.nf_conntrack_cachep, ct);
725 }
726 EXPORT_SYMBOL_GPL(nf_conntrack_free);
--
Regards,
Changli Gao(xiaosuo@...il.com)
--
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