From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933384AbcKOND1 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 15 Nov 2016 08:03:27 -0500
Received: from mail-wm0-f65.google.com ([74.125.82.65]:35402 "EHLO
        mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752357AbcKONDT (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 15 Nov 2016 08:03:19 -0500
Date: Tue, 15 Nov 2016 14:03:15 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: gregkh@linuxfoundation.org, keescook@chromium.org, will.deacon@arm.com,
        elena.reshetova@intel.com, arnd@arndb.de, tglx@linutronix.de,
        hpa@zytor.com, dave@progbits.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
Message-ID: <20161115130315.GA12957@gmail.com>
References: <20161114173946.501528675@infradead.org>
 <20161114174446.832175072@infradead.org>
 <20161115084009.GB15734@gmail.com>
 <20161115094744.GG3142@twins.programming.kicks-ass.net>
 <20161115100359.GA7757@gmail.com>
 <20161115104608.GH3142@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161115104608.GH3142@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Nov 15, 2016 at 11:03:59AM +0100, Ingo Molnar wrote:
> > > Should I also make a CONFIG knob that implements refcount_t with the
> > > 'normal' atomic_t primitives?
> > 
> > I'd suggest doing the saturation/safe-wrap semantics only for now (i.e. the 
> > current patch, split into two perhaps), and reconsider if there's any complaints?
> > 
> > > And possibly another knob to toggle the BUG()s into WARN()s. With the
> > > full saturation semantics WARN() is a lot safer and will not corrupt
> > > kernel state as much.
> > 
> > I'd suggest changing it to a WARN() straight away, no extra knobs.
> 
> OK, a little like so then? Note that the overflow tests went away
> because increments guarantee we saturate before we overflow.

Looks good to me!

Thanks,

	Ingo