From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751326AbdBTVbZ (ORCPT ); Mon, 20 Feb 2017 16:31:25 -0500 Received: from mail-ot0-f180.google.com ([74.125.82.180]:33140 "EHLO mail-ot0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751082AbdBTVbY (ORCPT ); Mon, 20 Feb 2017 16:31:24 -0500 MIME-Version: 1.0 In-Reply-To: <20170220095420.GA17198@gmail.com> References: <20170220095420.GA17198@gmail.com> From: Linus Torvalds Date: Mon, 20 Feb 2017 13:31:22 -0800 X-Google-Sender-Auth: VzY5esm4fOBgyKrklivpWocAnvo Message-ID: Subject: Re: [GIT PULL] locking changes for v4.11 To: Ingo Molnar Cc: Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner , "Paul E. McKenney" , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 20, 2017 at 1:54 AM, Ingo Molnar wrote: > > - Implement wraparound-safe refcount_t and kref_t types based on generic atomic > primitives (Peter Zijlstra) Ugh. This apparently never got the uninlining fixes? I've pulled it, but I still don't like the inlining. Particularly with CONFIG_DEBUG_REFCOUNT it generates obnnoxious code, but even without the debugging there's just no point in it. Being inlined also means that architectures cannot optimize it, which is sad. If you have a LL/SC model for atomics, then using atomic_cmpxchg_relaxed() for the refcounting is just too stupid for words. So I continue to think this code should (a) be in lib/refcount.c, with just the declarations in the header file (oh, keep the "set" and "read" functions inline by all means) (b) be marked __weak, so that architectures like ARM/PPC can decide to do their own improved implementations. But as mentioned, it's in my tree as-is now and going through the build test. Linus