Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751919AbdF1L7B (ORCPT ); Wed, 28 Jun 2017 07:59:01 -0400 Received: from mga02.intel.com ([134.134.136.20]:52143 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751619AbdF1L6o (ORCPT ); Wed, 28 Jun 2017 07:58:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,275,1496127600"; d="scan'208";a="104605918" From: "Reshetova, Elena" To: Kees Cook , Jens Axboe CC: James Bottomley , LKML , "linux-block@vger.kernel.org" , "linux-scsi@vger.kernel.org" , Linux Btrfs , Peter Zijlstra , Greg KH , "fujita.tomonori@lab.ntt.co.jp" , Ingo Molnar , Chris Mason , Josef Bacik , David Sterba Subject: RE: [PATCH 0/5] v3 block subsystem refcounter conversions Thread-Topic: [PATCH 0/5] v3 block subsystem refcounter conversions Thread-Index: AQHS7zouicR0MeOIOk68HrNLBF/eC6I4ot6AgACTIoCAAPbS8A== Date: Wed, 28 Jun 2017 11:58:37 +0000 Message-ID: <2236FBA76BA1254E88B949DDB74E612B6FF1DA36@IRSMSX102.ger.corp.intel.com> References: <1498563601-10949-1-git-send-email-elena.reshetova@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v5SBx7Pi005865 Content-Length: 1127 Lines: 32 > Subject: Re: [PATCH 0/5] v3 block subsystem refcounter conversions > > On Tue, Jun 27, 2017 at 6:26 AM, Jens Axboe wrote: > > On 06/27/2017 05:39 AM, Elena Reshetova wrote: > >> Changes in v3: > >> No changes in patches apart from trivial rebases, but now by > >> default refcount_t = atomic_t and uses all atomic standard operations > >> unless CONFIG_REFCOUNT_FULL is enabled. This is a compromize for the > >> systems that are critical on performance and cannot accept even > >> slight delay on the refcounter operations. > > > > Is that true in 4.12-rc, or is that true in a later release once > > Linus has pulled those changes in? If the latter, please resend > > this when those changes are in, thanks. > > It's in -next currently ("locking/refcount: Create unchecked atomic_t > implementation") I would really like to start discussion on the these patches asap since it normally takes some adjustments etc. before they can be merged and we want many changes to go into next release round and not to miss the merge window. Best Regards, Elena. > > -Kees > > -- > Kees Cook > Pixel Security