kern/177876: [mips] kernel stack overflow panic on mips64, EdgeRouter Lite

[Warner Losh]

On Apr 22, 2013, at 11:59 AM, Juli Mallett wrote:

> On Mon, Apr 22, 2013 at 10:35 AM, Adrian Chadd <adrian at 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!

I was pretty sure that I booted it first... The changes weren't really due to the conflicting docs, but rather just flat out saving the wrong things in the n32/n64 case.

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

I can back it out, if need be. I can test it again later today, but I'm busy for the next two hours.

Warner