From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752870AbbJNJoF (ORCPT ); Wed, 14 Oct 2015 05:44:05 -0400 Received: from ozlabs.org ([103.22.144.67]:42145 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751048AbbJNJoB (ORCPT ); Wed, 14 Oct 2015 05:44:01 -0400 Message-ID: <1444815838.1843.5.camel@ellerman.id.au> Subject: Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier From: Michael Ellerman To: Peter Zijlstra Cc: Boqun Feng , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Ingo Molnar , Benjamin Herrenschmidt , Paul Mackerras , Thomas Gleixner , Will Deacon , "Paul E. McKenney" , Waiman Long , Davidlohr Bueso , stable@vger.kernel.org Date: Wed, 14 Oct 2015 20:43:58 +1100 In-Reply-To: <20151014093307.GC3816@twins.programming.kicks-ass.net> References: <1444659246-24769-1-git-send-email-boqun.feng@gmail.com> <1444660220-25559-1-git-send-email-boqun.feng@gmail.com> <1444781400.12197.4.camel@ellerman.id.au> <20151014005134.GE23991@fixme-laptop.cn.ibm.com> <20151014080613.GP17308@twins.programming.kicks-ass.net> <20151014092653.GA29432@fixme-laptop.cn.ibm.com> <20151014093307.GC3816@twins.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-10-14 at 11:33 +0200, Peter Zijlstra wrote: > On Wed, Oct 14, 2015 at 05:26:53PM +0800, Boqun Feng wrote: > > Michael and Peter, rest of this patchset depends on commits which are > > currently in the locking/core branch of the tip, so I would like it as a > > whole queued there. Besides, I will keep this patch Cc'ed to stable in > > future versions, that works for you both? > > From my POV having the Cc stable in there is fine if Michael actually > wants them to go there. GregKH will vacuum them up once they hit Linus' > tree and we don't need to think about it anymore. Yeah that's fine by me. Here's an Ack if you want one: Acked-by: Michael Ellerman > Alternatively, Michael could put the patch in a separate branch and we > could both merge that. > > Or even, seeing how its a single patch and git mostly does the right > thing, we could just merge it independently in both trees and let git > sort it out at merge time. That probably would work, but I don't think it's necessary. My tree doesn't get much (or any) more testing than linux-next, so as long as locking/core is in linux-next then it will be tested just fine that way. cheers