From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755791AbcLOTKk (ORCPT ); Thu, 15 Dec 2016 14:10:40 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:51562 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755544AbcLOTKj (ORCPT ); Thu, 15 Dec 2016 14:10:39 -0500 Date: Thu, 15 Dec 2016 11:10:49 -0800 From: Greg KH To: "Jason A. Donenfeld" Cc: Christoph Hellwig , Thomas Hellstrom , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Daniel Vetter Subject: Re: [PATCH] kref: prefer atomic_inc_not_zero to atomic_add_unless Message-ID: <20161215191049.GB19707@kroah.com> References: <20161215185554.21931-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215185554.21931-1-Jason@zx2c4.com> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 15, 2016 at 07:55:54PM +0100, Jason A. Donenfeld wrote: > On most platforms, there exists this ifdef: > > #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0) > > This makes this patch functionally useless. However, on PPC, there is > actually an explicit definition of atomic_inc_not_zero with its own > assembly that is slightly more optimized than atomic_add_unless. So, > this patch changes kref to use atomic_inc_not_zero instead, for PPC and > any future platforms that might provide an explicit implementation. > > This also puts this usage of kref more in line with a verbatim reading > of the examples in Paul McKenney's paper [1] in the section titled "2.4 > Atomic Counting With Check and Release Memory Barrier", which uses > atomic_inc_not_zero. > > [1] http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2167.pdf > > Signed-off-by: Jason A. Donenfeld > Reviewed-by: Thomas Hellstrom > Reviewed-by: Christoph Hellwig > --- > Sorry to submit this again, but people keep reviewing it saying it's fine, > but then point to somebody else to actually merge this. At the end of the > chain of fingerpointing is usually Greg. "Just have Greg do it." At this > point I'm confused, but it's certainly been sufficiently reviewed and > accepted. So can one of you just respond saying "I'll take it!" Well, the crazies over in drm land were the ones that merged this new api, so they should be the ones responsible for it. But that was way back in 2012, odds are they don't remember it given the lunacy that is their subsystem... I'll take it after 4.10-rc1 is out, thanks. greg k-h