Date: Thu, 5 Jan 2012 11:37:23 +0100 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: Attila Nagy <bra@fsn.hu> Cc: stable@freebsd.org Subject: Re: Enabling IPSec panics stable/9 (runs OK on stable/8) Message-ID: <20120105103723.GA33970@zeninc.net> In-Reply-To: <4F057980.7080307@fsn.hu> References: <4F044A0B.3020108@fsn.hu> <20120104145155.GA31550@zeninc.net> <4F046D95.3070106@fsn.hu> <20120104163131.GA31787@zeninc.net> <4F057980.7080307@fsn.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 05, 2012 at 11:20:48AM +0100, Attila Nagy wrote:
> On 01/04/12 17:31, VANHULLEBUS Yvan wrote:
[....]
> >Could you check that you are running a correct debug kernel ?
> The kernel config is GENERIC, plus some, so it contains DEBUG=-g
> makeoptions.
Ok.
[....]
> (kgdb) frame 7
> #7 0xffffffff809bf779 in ipsec_process_done (m=0xfffffe001977a600,
> isr=0xfffffe019eb96480) at
> /data/usr/src/sys/netipsec/ipsec_output.c:170
> 170 switch (saidx->dst.sa.sa_family) {
> (kgdb) p saidx
> No symbol "saidx" in current context.
>
> BTW in the same frame:
> (kgdb) p tdbi
> $1 = (struct tdb_ident *) 0xfffffe017ce5e418
> (kgdb) p mtag
> $2 = (struct m_tag *) 0xfffffe017ce5e400
> (kgdb) p isr
> $3 = (struct ipsecrequest *) 0xfffffe019eb96480
Strange..... may be related to some kind of code optimization....
As the line juste before is:
saidx = &sav->sah->saidx;
Could you show the value of &sav->sah->saidx ?
And also check if kgdb can print sav->sah->saidx (without the &) ?
> >>Strange.... I'll review changes in IPsec stack which have been done in
> >>STABLE/9 and not backported to STABLE/8.....
> >>
> >> Oh, sorry, not quite an up-to-date 8-STABLE, it's from Sat May 21
> >> 22:05:26 CEST 2011 (csup'd some hours earlier).
> >> Should I check with a more recent version? Does that help?
> >> Thanks for helping.
> >
> >Yes, this may help if you try with a most recent 8-STABLE: I don't
> >remember exactly what, but I'm quite sure there have been some IPsec
> >related commits on stable/8 between that date and now !
> I will try it.
Ok.
To help you having a quick workaround, do you really need ESP+AH ?
Most of the time, people who configure ESP+AH just needs in fact ESP
with optional data authentication.
And the crash occurs in some part of the code which deals with
encapsulation in encapsulation.
This also may explains why I never saw that crash......
Yvan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120105103723.GA33970>