Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932303AbdGSXVS (ORCPT ); Wed, 19 Jul 2017 19:21:18 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:33253 "EHLO mail-io0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754255AbdGSXU4 (ORCPT ); Wed, 19 Jul 2017 19:20:56 -0400 MIME-Version: 1.0 In-Reply-To: <20170719231134.GF14395@linux-80c1.suse> References: <1499417992-3238-1-git-send-email-elena.reshetova@intel.com> <1499417992-3238-2-git-send-email-elena.reshetova@intel.com> <87bmottgo4.fsf@xmission.com> <20170719153546.37567fbf77861653172fa263@linux-foundation.org> <20170719225427.GD14395@linux-80c1.suse> <20170719155833.641a283467bf6b89a7d2e56b@linux-foundation.org> <20170719231134.GF14395@linux-80c1.suse> From: Kees Cook Date: Wed, 19 Jul 2017 16:20:54 -0700 X-Google-Sender-Auth: 4aoXADaIMRlYC6c1wC4Fd22TqiY Message-ID: Subject: Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t To: Davidlohr Bueso Cc: Andrew Morton , "Eric W. Biederman" , Elena Reshetova , LKML , Peter Zijlstra , Greg KH , Ingo Molnar , Alexey Dobriyan , "Serge E. Hallyn" , arozansk@redhat.com, Hans Liljestrand , David Windsor 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: 1774 Lines: 60 On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso wrote: > On Wed, 19 Jul 2017, Andrew Morton wrote: > >> On Wed, 19 Jul 2017 15:54:27 -0700 Davidlohr Bueso >> wrote: >> >>> On Wed, 19 Jul 2017, Andrew Morton wrote: >>> >>> >I do rather dislike these conversions from the point of view of >>> >performance overhead and general code bloat. But I seem to have lost >>> >that struggle and I don't think any of these are fastpath(?). >>> >>> Well, since we now have fd25d19 (locking/refcount: Create unchecked >>> atomic_t >>> implementation), performance is supposed to be ok. >> >> >> Sure, things are OK for people who disable the feature. FWIW, it's off by default. >> >> But for people who want to enable the feature we really should minimize >> the cost by avoiding blindly converting sites which simply don't need >> it: simple, safe, old, well-tested code. Why go and slow down such >> code? Need to apply some common sense here... These are the very code paths we'd want to make sure are well protected since people may never expect them to misbehave when some "small change" goes in. > Fair points. > >>> It would be lovely to have >>> some actual numbers nonetheless. >> >> Very much so. > > May I suggest using mmtests with the following config file: > > https://github.com/gormanm/mmtests/blob/7e070a810bc0af92e592e5121d0ea75fada51aeb/configs/config-global-dhp__workload-ipc-scale-short > > It will run two of Manfred's ipcscale sem benchmarks. I'll see if I can figure out how to use this for testing the fast refcount protection: https://lkml.org/lkml/2017/7/18/1223 Then we could see: before conversion after conversion with CONFIG_REFCOUNT_FULL with fast refcount protection -Kees -- Kees Cook Pixel Security