[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADVatmPOFLH2fe8VON1ohra+QOzaAZE+tT-uiKZhfceFwobjTQ@mail.gmail.com>
Date: Fri, 21 Dec 2018 12:59:32 +0000
From: Sudip Mukherjee <sudipm.mukherjee@...il.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Stable <stable@...r.kernel.org>,
Will Deacon <will.deacon@....com>,
Thomas Gleixner <tglx@...utronix.de>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
andrea.parri@...rulasolutions.com, longman@...hat.com,
Ingo Molnar <mingo@...nel.org>, Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.14 29/72] locking/qspinlock, x86: Provide liveness guarantee
On Thu, Dec 20, 2018 at 11:05 PM Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
>
> On 2018-12-20 18:49:41 [+0000], Sudip Mukherjee wrote:
> > On Thu, Dec 20, 2018 at 04:40:30PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Dec 20, 2018 at 12:14:00PM +0000, Sudip Mukherjee wrote:
> > > > Hi Greg,
> > > >
> > > > On Thu, Dec 20, 2018 at 9:28 AM Greg Kroah-Hartman
> > > > <gregkh@...uxfoundation.org> wrote:
> > > > >
> > > > > 4.14-stable review patch. If anyone has any objections, please let me know.
> > > > >
> > > > > ------------------
> > > > >
> > > > > commit 7aa54be2976550f17c11a1c3e3630002dea39303 upstream.
> > > >
> > > > Another upstream commit fixes this.
> > > > b987ffc18fb3 ("x86/qspinlock: Fix compile error")
> > >
> > > Maybe, but that commit doesn't apply to any of these stable trees :(
> > >
> > > Care to provide a backport?
> >
> > Attached now.
>
> Are you sure that it fails to compile without that patch? I have here
> Debian's gcc version 8.2.0 which probably isn't affected and I can
> compile kernel/locking/ in v4.19 + 4.14.
>
> I'm asking because in my backport the GEN_BINARY_RMWcc macro is used
> like in all the other functions which use it - unlike like in the
> original commit where the macro is used directly in the if condition. So
> it might not be affected by the problem.
ofcourse.. and I overlooked that part. Sorry.
The original problem was using the "goto" inside if() and with your
backported patch the problem should not exist.
Greg, please do not add it to your queue.
--
Regards
Sudip
Powered by blists - more mailing lists