From: Steffen Klassert <steffen.klassert@secunet•com>
To: Andre Valentin <avalentin@marcant•net>
Cc: <herbert@gondor•apana.org.au>, <davem@davemloft•net>,
<netdev@vger•kernel.org>
Subject: Re: Kernel Panic with vti Interfaces
Date: Thu, 26 Feb 2015 12:40:53 +0100 [thread overview]
Message-ID: <20150226114052.GB20631@secunet.com> (raw)
In-Reply-To: <54EC4C63.3050006@marcant.net>
Ccing netdev.
On Tue, Feb 24, 2015 at 11:03:15AM +0100, Andre Valentin wrote:
> Hi!
>
> I noticed kernel panics on my mips platform while using vti interfaces. After taking a deeper look,
> it seems that if the SA changes or the WAN interface changes I get this error. I could find the
> code where it crashes. But I'm not sure if my solution is right. Perhaps you could take a look.
>
> From: =?utf8?q?Andr=C3=A9=20Valentin?= <avalentin@marcant•net>
> Date: Tue, 24 Feb 2015 00:24:08 +0100
> Subject: [PATCH] kernel: fix xfrm tunnel checks if vti parent SA/device is in transition
>
> The outer_mode check results in the error if it is not checked for validity.
> Because I do not know how to handle this situation, I decided to return
> -EINVAL if outer_mode is null.
>
> ---
> .../618-net_fixup_xfrm_tunnel_check.patch | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
> create mode 100644 target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch
>
> diff --git a/target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch b/target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch
> new file mode 100644
> index 0000000..f79b1f7
> --- /dev/null
> +++ b/target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch
> @@ -0,0 +1,16 @@
> +--- a/include/net/xfrm.h 2015-02-11 08:01:12.000000000 +0100
> ++++ b/include/net/xfrm.h 2015-02-24 00:04:03.102709830 +0100
> +@@ -1805,8 +1805,12 @@ static inline int xfrm_tunnel_check(stru
> + tunnel = true;
> + break;
> + }
> +- if (tunnel && !(x->outer_mode->flags & XFRM_MODE_FLAG_TUNNEL))
> ++ if (tunnel && !x->outer_mode) {
> ++ printk(KERN_NOTICE "xfrm_tunnel_check: outer_mode is 0, returning -EINVAL\n");
> + return -EINVAL;
Returning -EINVAL here would just paper over the real bug.
We should never get a state without outer_mode from a lookup.
Using such a state will lead to a crash anyway, even without
using vti devices. Looks like you get an uninitialized state
with the lookup. When a xfrm_state is initialized, the outer
mode is added and after that inserted to the lookup tables.
It should never loose the outer_mode pointer.
I have never seen this, is the patch above the only locally
applied patch?
Is this reproducible?
next parent reply other threads:[~2015-02-26 11:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54EC4C63.3050006@marcant.net>
2015-02-26 11:40 ` Steffen Klassert [this message]
2015-02-26 23:58 ` Kernel Panic with vti Interfaces Andre Valentin
2015-02-27 10:35 ` Steffen Klassert
2015-02-28 21:21 ` Andre Valentin
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=20150226114052.GB20631@secunet.com \
--to=steffen.klassert@secunet$(echo .)com \
--cc=avalentin@marcant$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox