Re: [PATCH 4.14 29/72] locking/qspinlock, x86: Provide liveness guarantee

From: Sudip Mukherjee
Date: Fri Dec 21 2018 - 08:00:12 EST


On Thu, Dec 20, 2018 at 11:05 PM Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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