All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Timo Teräs" <timo.teras@iki.fi>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Justin P.Mattock" <justinmattock@gmail.com>,
	"John W.Linville" <linville@tuxdriver.com>,
	netdev@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	davem@davemloft.net
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
Date: Wed, 23 Jun 2010 21:10:14 +0300	[thread overview]
Message-ID: <4C224E06.40806@iki.fi> (raw)
In-Reply-To: <1277314167.2469.1144.camel@edumazet-laptop>

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 <timo.teras@iki.fi>
>> 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 <timo.teras@iki.fi>
>>      Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> :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

  reply	other threads:[~2010-06-23 18:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-22 23:16 BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 Justin Mattock
2010-06-22 23:16 ` Justin Mattock
2010-06-23 14:16 ` John W. Linville
2010-06-23 14:41   ` Justin P. Mattock
2010-06-23 17:00   ` Justin P. Mattock
2010-06-23 17:29     ` Eric Dumazet
2010-06-23 18:10       ` Timo Teräs [this message]
2010-06-23 18:20         ` Justin P. Mattock
2010-06-23 20:34           ` Timo Teräs
2010-06-23 21:44             ` Justin P. Mattock
2010-06-24  5:45               ` [PATCH] xfrm: check bundle policy existance before dereferencing it Timo Teräs
2010-06-24  5:45                 ` Timo Teräs
2010-06-24 21:35                 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C224E06.40806@iki.fi \
    --to=timo.teras@iki.fi \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=justinmattock@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.