From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kerin Millar Subject: Re: scheduling while atomic followed by oops upon conntrackd -c execution Date: Thu, 08 Mar 2012 11:29:58 +0000 Message-ID: References: <4F50E30B.6000704@gmail.com> <20120303133002.GA18802@1984> <20120304110151.GA22404@1984> <20120306111427.GA448@1984> <20120306172318.GA2282@1984> <20120308013348.GA9402@1984> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: netfilter-devel@vger.kernel.org Return-path: Received: from plane.gmane.org ([80.91.229.3]:51334 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751502Ab2CHLaT (ORCPT ); Thu, 8 Mar 2012 06:30:19 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S5bY2-00089s-TI for netfilter-devel@vger.kernel.org; Thu, 08 Mar 2012 12:30:18 +0100 Received: from host90-152-1-244.ipv4.regusnet.com ([90.152.1.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2012 12:30:18 +0100 Received: from kerframil by host90-152-1-244.ipv4.regusnet.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2012 12:30:18 +0100 In-Reply-To: <20120308013348.GA9402@1984> Sender: netfilter-devel-owner@vger.kernel.org List-ID: On 08/03/2012 01:33, Pablo Neira Ayuso wrote: > Moreover, I need to know if there was some traffic circulating > through the backup or no traffic at all. Sorry, I didn't address this point in my previous email. The backup does indeed handle some traffic. Both systems run BIND and, as such, the backup is also our secondary public-facing nameserver. The load generated by this is not significant though. At any given moment, the number of state entries hovers at between 100-150 and almost all of these are from UDP entries on account of DNS queries. The rest can be accounted for by ntpd (about 4 active entries for upstream ntp servers), ssh (1 connection only), ICMP echo-request handling and a few other sundries. In my test case, I am running conntrackd -c under circumstances where conntrackd on the master is still pushing events across. But, I have also simulated a realistic failover scenario on at least two occasions by shutting down the master (at which point, conntrackd terminates and is obviously no longer pushing events to the backup). Regardless, the backup still crashes upon conntrackd -c. In summary: * Both nodes are handling DNS traffic (but it's packet forwarding which really generates a heavy load) * conntrackd -c has been run under circumstances where conntrack daemon is and isn't continuing to receive traffic from other node. It crashes anyway. Cheers, --Kerin