All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Justin P. Mattock" <justinmattock@gmail.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: netdev@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	davem@davemloft.net, timo.teras@iki.fi
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
Date: Wed, 23 Jun 2010 10:00:58 -0700	[thread overview]
Message-ID: <4C223DCA.5090704@gmail.com> (raw)
In-Reply-To: <20100623141622.GC15205@tuxdriver.com>

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



Justin P. Mattock

  parent reply	other threads:[~2010-06-23 17:08 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 [this message]
2010-06-23 17:29     ` Eric Dumazet
2010-06-23 18:10       ` Timo Teräs
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=4C223DCA.5090704@gmail.com \
    --to=justinmattock@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=timo.teras@iki.fi \
    /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.