Re: gcc-6.3.x miscompiling code for IP27?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Joshua,

On Mon, Jan 23, 2017 at 01:00:52PM -0500, Joshua Kinard wrote:
> On 01/22/2017 21:24, Joshua Kinard wrote:
> > On 01/22/2017 20:03, Joshua Kinard wrote:
> >> On 01/22/2017 18:28, Joshua Kinard wrote:
> >>> I think I've run into a really odd gcc-6.3.x miscompile bug here on IP27.
> >>> But I'm not sure.  I've reproduced the issue on 4.9.5, 4.8.17, and now
> >>> 4.7.10 (which I KNOW should boot).  If I recompile the same 4.7.10 kernel
> >>> with gcc-5.4.0, though, it boots as expected.  The fault appears to be in
> >>> the assembly for _raw_spin_lock_irq.
> 
> [snip]
> 
> > I am not sure what to call this.  This is definitely not happening with a
> > gcc-5.4.x-built kernel, so it's a code-generation issue of some kind:
> 
> With some help from the gcc mailing list, the "sd" instructions emitted at the
> beginning of every function is from the -fstack-check flag.  It enables
> stack-probing to ensure there is sufficient space on the stack, else it'll
> trigger a SEGV.  My guess is for IP27, at this early point in boot, the memory
> system isn't up and running yet, due to IP27's somewhat-unique nature.  Thus,
> this stack-probe will fail and trigger the NULL deref in _raw_spin_lock_irq().
> 
> The workaround I am going to go with is to add -fno-stack-check to IP27's
> arch/mips/sgi-ip27/Platform file to disable stack-checking.  As far as I can
> tell, this solves the issue on IP27 by not emitted these instructions anymore
> (verified w/ objdump).  Not sure where this flag is getting set from.  Could be
> set in my distro's toolchain somewhere.  But since at least IP30 is not
> affected, I am going to assume it's specific to IP27 for now.

Interesting. It definitely looks like an option we should not be using
in the kernel, regardless of platform, since kernel stacks are
relatively small, put in unmapped virtual memory and don't grow when
overflowed. At least until we get mapped stacks (which has its own set
of hurdles) its more likely to just corrupt other kernel memory and
cause seemingly random crashes like this one.

Cheers
James

> 
> I'll send a patch in later this week...
> 
> -- 
> Joshua Kinard
> Gentoo/MIPS
> kumba@xxxxxxxxxx
> 6144R/F5C6C943 2015-04-27
> 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
> 
> "The past tempts us, the present confuses us, the future frightens us.  And our
> lives slip away, moment by moment, lost in that vast, terrible in-between."
> 
> --Emperor Turhan, Centauri Republic
> 

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux