Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752941AbcKQTex (ORCPT ); Thu, 17 Nov 2016 14:34:53 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:37931 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752077AbcKQTew (ORCPT ); Thu, 17 Nov 2016 14:34:52 -0500 MIME-Version: 1.0 In-Reply-To: <20161117083458.GZ3142@twins.programming.kicks-ass.net> References: <20161114173946.501528675@infradead.org> <20161114174446.486581399@infradead.org> <20161115073322.GC28248@kroah.com> <20161115080314.GD3142@twins.programming.kicks-ass.net> <20161116100925.GM3142@twins.programming.kicks-ass.net> <20161117083458.GZ3142@twins.programming.kicks-ass.net> From: Kees Cook Date: Thu, 17 Nov 2016 11:34:49 -0800 X-Google-Sender-Auth: ZgZHaRpQLFIQrFAMdWyNRQjhX7U Message-ID: Subject: Re: [RFC][PATCH 2/7] kref: Add kref_read() To: Peter Zijlstra Cc: Greg KH , Will Deacon , "Reshetova, Elena" , Arnd Bergmann , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , David Windsor , LKML , Alexei Starovoitov , Daniel Borkmann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1445 Lines: 35 On Thu, Nov 17, 2016 at 12:34 AM, Peter Zijlstra wrote: > On Wed, Nov 16, 2016 at 10:58:38AM -0800, Kees Cook wrote: >> What I mean to say is that while the refcnt here should clearly be >> converted to kref or refcount_t, it looks like locked_vm should become >> a new stats_t. However, it seems weird for locked_vm to ever wrap >> either... > > No, its not a statistic. Also, I'm far from convinced stats_t is an > actually useful thing to have. It's useful because its introduction creates a type that can't be trivially used for refcounting (i.e. hard to make the mistake of using stats_t for refcounting), and replacing atomic_t statistic counters with stats_t reduces the effort required to do the initial (and on-going) audit for misuse of atomic_t as a refcounter. > refcount_t brought special semantics that clearly are different from > regular atomic_t, stats_t would not, so why would it need to exist. Your original suggestion about stats_t showed how its accessor API would be a very small subset of the regular atomic_t set. I think that reduction in accidental misuse has value. > Not to mention that you seem over eager to apply it, which doesn't > inspire confidence. I'd like to get to the point where auditing for mistakes in this area is tractable. :) If atomic_t is only used for non-stats and non-refcount, it's much much easier to examine and reason about. -Kees -- Kees Cook Nexus Security