From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941305AbcKOHmx (ORCPT ); Tue, 15 Nov 2016 02:42:53 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33797 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752777AbcKOHmu (ORCPT ); Tue, 15 Nov 2016 02:42:50 -0500 Date: Tue, 15 Nov 2016 08:42:45 +0100 From: Ingo Molnar To: Greg KH Cc: Peter Zijlstra , keescook@chromium.org, will.deacon@arm.com, elena.reshetova@intel.com, arnd@arndb.de, tglx@linutronix.de, hpa@zytor.com, dave@progbits.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 0/7] kref improvements Message-ID: <20161115074245.GB7016@gmail.com> References: <20161114173946.501528675@infradead.org> <20161115072742.GA28248@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161115072742.GA28248@kroah.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Greg KH wrote: > On Mon, Nov 14, 2016 at 06:39:46PM +0100, Peter Zijlstra wrote: > > This series unfscks kref and then implements it in terms of refcount_t. > > > > x86_64-allyesconfig compile tested and boot tested with my regular config. > > > > refcount_t is as per the previous thread, it BUGs on over-/underflow and > > saturates at UINT_MAX, such that if we ever overflow, we'll never free again. > > > > > > Thanks so much for doing these, at the very least, I want to take the > kref-abuse-fixes now as those users shouldn't be doing those foolish > things. Any objection for me taking some of them through my tree now? Very nice series indeed! We normally route atomics related patches through tip:locking/core (there's also tip:atomic/core), but this is a special case I think, given how broadly it interacts with driver code. So both would work I think: we could concentrate these and only these patches into tip:atomic/core into an append-only tree, or you can carry them in the driver tree - whichever variant you prefer! Thanks, Ingo