Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752399Ab0FWSKX (ORCPT ); Wed, 23 Jun 2010 14:10:23 -0400 Received: from mail-ww0-f46.google.com ([74.125.82.46]:64556 "EHLO mail-ww0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751366Ab0FWSKV (ORCPT ); Wed, 23 Jun 2010 14:10:21 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=BLHOU6/pMsuQ8L9JjN/tmF2OZXXyhrpzrU/Ou9++S4hYg1E0Jt2E0si+SV0mrp7+2m gnW8w1Nk5msoCTKro9xbjKcko7lHoGE4kX9ZZ1PUWYJcb60dUFfjW+S26dWtustXTItU C/j9bQOtAAJHuHcdMVaQLoCCL9LIbIFV6/SJ4= Message-ID: <4C224E06.40806@iki.fi> Date: Wed, 23 Jun 2010 21:10:14 +0300 From: =?UTF-8?B?VGltbyBUZXLDpHM=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eric Dumazet CC: "Justin P.Mattock" , "John W.Linville" , netdev@vger.kernel.org, Linux Kernel Mailing List , davem@davemloft.net Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 References: <20100623141622.GC15205@tuxdriver.com> <4C223DCA.5090704@gmail.com> <1277314167.2469.1144.camel@edumazet-laptop> In-Reply-To: <1277314167.2469.1144.camel@edumazet-laptop> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2206 Lines: 54 On 06/23/2010 08:29 PM, Eric Dumazet wrote: > Le mercredi 23 juin 2010 à 10:00 -0700, Justin P. Mattock a écrit : >> o.k. the bisect is pointing to the below results.. >> (I tried git revert xxx but this commit is too big >> so I'll(hopefully)manually revert it on the latest HEAD to >> see if this is the actual problem im experiencing) >> >> 80c802f3073e84c956846e921e8a0b02dfa3755f is the first bad commit >> commit 80c802f3073e84c956846e921e8a0b02dfa3755f >> Author: Timo Teräs >> Date: Wed Apr 7 00:30:05 2010 +0000 >> >> xfrm: cache bundles instead of policies for outgoing flows >> >> __xfrm_lookup() is called for each packet transmitted out of >> system. The xfrm_find_bundle() does a linear search which can >> kill system performance depending on how many bundles are >> required per policy. >> >> This modifies __xfrm_lookup() to store bundles directly in >> the flow cache. If we did not get a hit, we just create a new >> bundle instead of doing slow search. This means that we can now >> get multiple xfrm_dst's for same flow (on per-cpu basis). >> >> Signed-off-by: Timo Teras >> Signed-off-by: David S. Miller >> >> :040000 040000 d8e60f5fa4c1329f450d9c7cdf98b34e6a177f22 >> 9f576e68e5bf4ce357d7f0305aee5f410250dfe2 M include >> :040000 040000 f2876df688ee36907af7b4123eea96592faaed3e >> a3f6f6f94f0309106856cd99b38ec90b024eb016 M net > > Thanks a lot for bisecting Jutin, this is really appreciated. > > crash is in xfrm_bundle_ok() > > if (xdst->policy_genid != atomic_read(&xdst->pols[0]->genid)) > return 0; > > xdst->pols[0] contains a NULL pointer That does not really make sense, if we get this far; there's a valid xfrm_state with the bundle. This means that there existed a policy with it too. I'll take a deeper look at this tomorrow. Would it be possible to see your xfrm policies? - Timo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/