From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932201AbdJWNMf (ORCPT ); Mon, 23 Oct 2017 09:12:35 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:47246 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932141AbdJWNMe (ORCPT ); Mon, 23 Oct 2017 09:12:34 -0400 Date: Mon, 23 Oct 2017 15:12:24 +0200 From: Peter Zijlstra To: Elena Reshetova Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, keescook@chromium.org, tglx@linutronix.de, mingo@redhat.com, ishkamiel@gmail.com Subject: Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t Message-ID: <20171023131224.GC3165@worktop.lehotels.local> References: <1508756984-18980-1-git-send-email-elena.reshetova@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1508756984-18980-1-git-send-email-elena.reshetova@intel.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 23, 2017 at 02:09:44PM +0300, Elena Reshetova wrote: > Currently arch. independent implementation of refcount_t in > lib/refcount.c provides weak memory ordering guarantees > compare to its analog atomic_t implementations. > While it should not be a problem for most of the actual > cases of refcounters, it is more understandable for everyone > (and more error-prone for future users) to provide exactly > same memory ordering guarantees as atomics. > > If speed is of a concern, then either more efficient arch. > dependent refcount_t implementation should be used or if there > are enough users in the future we might need to provide both > strict and relaxed refcount_t APIs. > > Suggested-by: Kees Cook NAK