From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754075AbdDCQQT (ORCPT ); Mon, 3 Apr 2017 12:16:19 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:47420 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752556AbdDCQQR (ORCPT ); Mon, 3 Apr 2017 12:16:17 -0400 Date: Mon, 03 Apr 2017 09:16:12 -0700 (PDT) Message-Id: <20170403.091612.1886244463475403493.davem@davemloft.net> To: elena.reshetova@intel.com Cc: linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, x86@kernel.org, sparclinux@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, peterz@infradead.org, gregkh@linuxfoundation.org, tglx@linutronix.de, mingo@redhat.com, tony.luck@intel.com, hpa@zytor.com, ishkamiel@gmail.com, keescook@chromium.org, dwindsor@gmail.com Subject: Re: [PATCH 3/4] sparc: convert mdesc_handle.refcnt from atomic_t to refcount_t From: David Miller In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B41C87070@IRSMSX102.ger.corp.intel.com> References: <2236FBA76BA1254E88B949DDB74E612B41C86E2F@IRSMSX102.ger.corp.intel.com> <20170403.061252.1545979851987245996.davem@davemloft.net> <2236FBA76BA1254E88B949DDB74E612B41C87070@IRSMSX102.ger.corp.intel.com> X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 03 Apr 2017 08:34:59 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Reshetova, Elena" Date: Mon, 3 Apr 2017 16:06:44 +0000 >> From: "Reshetova, Elena" >> Date: Mon, 3 Apr 2017 07:28:01 +0000 >> >> > >> >> From: Elena Reshetova >> >> Date: Mon, 20 Feb 2017 13:06:20 +0200 >> >> >> >> > refcount_t type and corresponding API should be >> >> > used instead of atomic_t when the variable is used as >> >> > a reference counter. This allows to avoid accidental >> >> > refcounter overflows that might lead to use-after-free >> >> > situations. >> >> > >> >> > Signed-off-by: Elena Reshetova >> >> > Signed-off-by: Hans Liljestrand >> >> > Signed-off-by: Kees Cook >> >> > Signed-off-by: David Windsor >> >> >> >> Acked-by: David S. Miller >> > >> > Hi David, >> > >> > Would you be able to propagate this patch further or should I send >> > it (with your acked-by) once more to specific list/maintainer for >> > the inclusion? >> >> I'm generally not happy with the refcount_t and the added overhead it >> has compared to the existing atomic_t operations. >> >> I know it is going to make a difference for networking. >> >> I understand that this sparc case is a slow path, but I know that if >> we just apply all of these refcount_t conversions, there will be no >> work done to address the performance issues. > > I think we will have to address the performance problems in places where we can see it matters. > The problem is that so far noone told us how to measure in any reasonable way the overhead neither in networking, not in mm changes. > If this change is a slow path, why would it matter for *this particular patch*? I think not having a way to avoid the functional call makes the facility unusable as a core kernel facility. You can't just say "oh well, just convert the slow paths, we'll solve the fundamental performance issue later". Sorry, that is not how we do things.