linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: peter@hurleysoftware.com (Peter Hurley)
To: linux-arm-kernel@lists.infradead.org
Subject: RCU bug with v3.17-rc3 ?
Date: Tue, 14 Oct 2014 06:27:52 -0400	[thread overview]
Message-ID: <543CFAA8.90608@hurleysoftware.com> (raw)
In-Reply-To: <20141014020640.GB25433@kroah.com>

On 10/13/2014 10:06 PM, Greg KH wrote:
> On Mon, Oct 13, 2014 at 12:43:07PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 13, 2014 at 09:11:34AM +0000, David Laight wrote:
>>> From: Nathan Lynch
>>>> On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
>>>>>
>>>>> Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
>>>>> it seems that this has been known about for some time.)
>>>>
>>>> Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x < 3
>>>> are affected, as well as 4.9.0.
>>>>
>>>>> We can blacklist these GCC versions quite easily.  We already have GCC
>>>>> 3.3 blacklisted, and it's trivial to add others.  I would want to include
>>>>> some proper details about the bug, just like the other existing entries
>>>>> we already have in asm-offsets.c, where we name the functions that the
>>>>> compiler is known to break where appropriate.
>>>>
>>>> Before blacklisting anything, it's worth considering that simple version
>>>> checks would break existing pre-4.8.3 compilers that have been patched
>>>> for PR58854.  It looks like Yocto and Buildroot issued releases with
>>>> patched 4.8.2 compilers well before the (fixed) 4.8.3 release.  I think
>>>> the most we can reasonably do without breaking some correctly-behaving
>>>> toolchains is to emit a warning.
>>>
>>> Is it possible to compile a small code fragment and check the generated
>>> code for the bug?
>>> Possibly predicated on the broken version number to avoid false positives.
>>
>> I don't see how - it looks like it requires an interrupt to occur at an
>> opportune moment to provoke the function to fail.  The alternative would
>> be to parse the assembly generated by the compiler to determine how it
>> is dealing with the stack.
>>
>> I think the only viable solution here is that:
>>
>> 1. We blacklist the bad compiler versions outright in the kernel.
> 
> Yes, please do this, it's what we have done for other buggy compiler
> versions, no need to do something different here.
> 
>> Remember, it's the distro's choice to fix these buggy compilers, so the
>> onus is on _them_ to deal with the mess they've created by doing so.
> 
> I totally agree.
> 
> Is someone going to send this patch, or do I have to write it myself?

I did on Friday (arm: Blacklist gcc 4.8.[012] ...) but Russell said he
was doing it himself.

Regards,
Peter Hurley

  reply	other threads:[~2014-10-14 10:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140904184021.GA13421@saruman.home>
     [not found] ` <20140904191642.GJ5001@linux.vnet.ibm.com>
     [not found]   ` <20140904192535.GJ13421@saruman.home>
     [not found]     ` <20140904200403.GL13421@saruman.home>
     [not found]       ` <20140905213216.GD5001@linux.vnet.ibm.com>
2014-10-08 17:13         ` RCU bug with v3.17-rc3 ? Felipe Balbi
2014-10-08 17:57           ` Felipe Balbi
2014-10-08 21:29             ` Felipe Balbi
2014-10-09 16:01               ` Johannes Weiner
2014-10-09 16:26                 ` Felipe Balbi
2014-10-09 20:35                   ` Felipe Balbi
2014-10-09 20:41                   ` Rabin Vincent
2014-10-09 20:46                     ` Felipe Balbi
2014-10-09 21:07                       ` Felipe Balbi
2014-10-10 13:57                         ` Felipe Balbi
2014-10-10 16:25                           ` Russell King - ARM Linux
2014-10-11  1:44                             ` Nathan Lynch
2014-10-11  2:40                               ` Peter Hurley
2014-10-11  3:54                               ` Peter Chen
2014-10-11 14:16                                 ` Russell King - ARM Linux
2014-10-11 14:51                                   ` Otavio Salvador
2014-10-11 18:15                                     ` Peter Hurley
2014-10-11 14:14                               ` Russell King - ARM Linux
2014-10-11 19:27                               ` Nathan Lynch
2014-10-13  9:11                               ` David Laight
2014-10-13 11:43                                 ` Russell King - ARM Linux
2014-10-14  2:06                                   ` Greg KH
2014-10-14 10:27                                     ` Peter Hurley [this message]
2014-10-15 21:23                                     ` Russell King - ARM Linux
2014-10-15 21:25                                       ` Russell King - ARM Linux
2014-10-19  9:54                                         ` Russell King - ARM Linux
2014-10-19 15:28                                           ` Felipe Balbi
2014-10-19 20:48                                             ` Olof Johansson
2014-10-09 21:47                     ` Aaro Koskinen
2014-10-10 16:18                       ` Russell King - ARM Linux
2014-10-10 20:52                         ` Aaro Koskinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=543CFAA8.90608@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).