Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Apr 2013 10:59:11 -0700
From:      Juli Mallett <jmallett@FreeBSD.org>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Joe Holden <joe@rewt.org.uk>, "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org>
Subject:   Re: kern/177876: [mips] kernel stack overflow panic on mips64, EdgeRouter Lite
Message-ID:  <CACVs6=8XdAgccufabeoXEXCFGGVZ_EWJ8c-KdRz4xr9SvBxrrw@mail.gmail.com>
In-Reply-To: <CAJ-VmomKi%2BpmZ6GAjds-=RXRET=aW65dsmxe3H4m%2BfdbxoecGw@mail.gmail.com>
References:  <201304220300.r3M301iY093070@freefall.freebsd.org> <CAJ-Vmok7m9%2B3sky1swEP6ZTnZNLpkmwTC2tOqzGNaSFwY7WmFA@mail.gmail.com> <51753506.3070901@rewt.org.uk> <CAJ-VmomKi%2BpmZ6GAjds-=RXRET=aW65dsmxe3H4m%2BfdbxoecGw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 22, 2013 at 10:35 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> Do an svn log in sys/mips/ or sys/vm/ and look at the changes.
>
> I don't know how far you can go back before you don't have the
> edgerouter lite support, but maybe you can try going back to when Juli
> initially committed it, and then just work your way forward.
>
> I think Juli did the initial work, so she knows when it came in.
>
> juli - I don't suppose you could spin up FreeBSD-HEAD on the
> edgerouter lite and take a look? It's highly likely someone messed up
> since you did your port. :(

I can't quite imagine why EdgeRouter Lite (or Octeon more generally)
could be a special case here; I'd be more inclined to think it was
generally 64-bit MIPS that would be broken.  (A too-conservative
definition or something.)  Except I was pretty sure I'd run -CURRENT
more recently than those changes.

The only change that is suspect in mips/ since I made my changes is
Warner's change to include/regnum.h, which looks like there's the slim
possibility that it could screw up register saving in N64 builds.
That would mean that it wasn't tested with a 64-bit build, though,
which I'm sure Warner wouldn't be so sloppy as to do.

Joe, can you try reverting 249523 and seeing if that fixes things for
you?  It seems like this breaks the order of registers saved to the
PCB, which would break syscalls with more than 4 arguments, like mmap.
 Even just looking at how the macros expand in the N64 case makes it
pretty clear that this change was made clumsily, e.g. from
exception.S:

 SAVE_REG($12, 8, $29)
 SAVE_REG($13, 9, $29)
 SAVE_REG($14, 10, $29)
 SAVE_REG($15, 11, $29)
 SAVE_REG($8, 12, $29)
 SAVE_REG($9, 13, $29)
 SAVE_REG($10, 14, $29)
 SAVE_REG($11, 15, $29)

For this to not break syscalls, struct trapframe would need to be
updated, or the syscall handling code.  Joe, can you confirm that
backing out 249523 fixes things for you?  If it does, Adrian, would
you be willing to handle a backout?  I can't imagine finding the time
for a couple of days, and if this is really so badly, unnecessarily
broken, that should be fixed immediately.  I hope I'm wrong.  Nobody
should be making incomplete changes on the basis of a half-baked
reading of purportedly-conflicting documentation, and without testing.
 Yikes!

If, as I really, really hope, that change isn't the problem, it's not
clear to me that would be the culprit.

Thanks,
Juli.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=8XdAgccufabeoXEXCFGGVZ_EWJ8c-KdRz4xr9SvBxrrw>