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

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

 



On 01/24/2017 10:45, James Hogan wrote:
> 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

Instead of making -fno-stack-check IP27-only, I can do a patch for the main
arch/mips/Makefile instead to turn it off globally.  It looks like this option
has been available in gcc as far back as at least 3.0.4, so would any kind of
compatibility/version check for gcc be needed?  I'm not sure what the oldest
gcc supported by the MIPS code currently is.

-- 
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




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

  Powered by Linux