[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2eOo=9Pv4XmyX30_PYoRpp_f6rXQn+pk9z21wMvE84Ag@mail.gmail.com>
Date: Fri, 26 Oct 2018 09:36:30 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Paul Burton <paul.burton@...s.com>
Cc: Sasha Levin <sashal@...nel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
James Hogan <jhogan@...nel.org>,
Ralf Baechle <ralf@...ux-mips.org>,
"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>
Subject: Re: [PATCH AUTOSEL 4.14 33/46] MIPS: Workaround GCC
__builtin_unreachable reordering bug
On 10/25/18, Paul Burton <paul.burton@...s.com> wrote:
> On Thu, Oct 25, 2018 at 10:10:40AM -0400, Sasha Levin wrote:
>> From: Paul Burton <paul.burton@...s.com>
>> ---
>> arch/mips/Kconfig | 1 +
>> arch/mips/include/asm/compiler.h | 35 ++++++++++++++++++++++++++++++++
>> 2 files changed, 36 insertions(+)
>
> In principle I'm fine with backporting this - it does fix broken builds.
>
> It's only going to be of any use though if you also backport commit
> 04f264d3a8b0 ("compiler.h: Allow arch-specific asm/compiler.h"). I'd
> recommend backporting both or neither.
>
> In practice I think it's unlikely anyone will need a microMIPS kernel &
> be tied to the particular versions affected by the bug this patch fixed,
> so I don't think it's a problem to backport neither.
I think the current practice of the stable kernel these days is to take
both patches in this case: They fix an actual bug in the mainline kernel,
and it seems unlikely enough that they cause a regression if backported,
so putting them into 4.14 has more advantages than disadvantages.
Arnd
Powered by blists - more mailing lists