From mboxrd@z Thu Jan  1 00:00:00 1970
From: Patrick McHardy <kaber@trash.net>
Subject: Re: kernel stack  trace using conntrack
Date: Thu, 18 Feb 2010 11:34:54 +0100
Message-ID: <4B7D17CE.6010805@trash.net>
References: <7EF5DBE4C76A7B4DA655334E9F2BFD26CED7BC8D04@FRSPX100.fr01.awl.atosorigin.net>	 <1266313889.3045.1.camel@edumazet-laptop>	 <7EF5DBE4C76A7B4DA655334E9F2BFD26CED7BC8D54@FRSPX100.fr01.awl.atosorigin.net>	 <1266318928.3045.38.camel@edumazet-laptop>  <4B7A9E95.103@netfilter.org> <1266327917.3045.55.camel@edumazet-laptop> <7EF5DBE4C76A7B4DA655334E9F2BFD26CED7BC905D@FRSPX100.fr01.awl.atosorigin.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	"netfilter-devel@vger.kernel.org" <netfilter-devel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>
To: Ramblewski David <David.Ramblewski@atosorigin.com>
Return-path: <netfilter-devel-owner@vger.kernel.org>
Received: from stinky.trash.net ([213.144.137.162]:61918 "EHLO
	stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756174Ab0BRKe7 (ORCPT
	<rfc822;netfilter-devel@vger.kernel.org>);
	Thu, 18 Feb 2010 05:34:59 -0500
In-Reply-To: <7EF5DBE4C76A7B4DA655334E9F2BFD26CED7BC905D@FRSPX100.fr01.awl.atosorigin.net>
Sender: netfilter-devel-owner@vger.kernel.org
List-ID: <netfilter-devel.vger.kernel.org>

Ramblewski David wrote:
> Hi Eric,
> 
> The conntrack patch works successfully.
> 
>>> diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
>>> index 0ffe689..d2657aa 100644
>>> --- a/net/netfilter/nf_conntrack_netlink.c
>>> +++ b/net/netfilter/nf_conntrack_netlink.c
>>> @@ -923,7 +923,7 @@ ctnetlink_change_status(struct nf_conn *ct, const struct nlattr * const cda[])
>>>     unsigned int status = ntohl(nla_get_be32(cda[CTA_STATUS]));
>>>     d = ct->status ^ status;
>>>
>>> -   if (d & (IPS_EXPECTED|IPS_CONFIRMED|IPS_DYING))
>>> +   if (d & (IPS_EXPECTED|IPS_DYING))
>>>             /* unchangeable */
>>>             return -EBUSY;
>> I think that we should explicitly report if the user unsets
>> IPS_CONFIRMED. Please, don't change this.
>>
>> Apart from that, the patch seems fine to me. Thanks!
> 
> Problem is we now (I mean after my patch) enter
> ctnetlink_change_status() with ct->status being null (or at least,
> IPS_CONFIRMED not set)

Pablo, please let me know whether you want me to apply this.