Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751098AbdCQHma (ORCPT ); Fri, 17 Mar 2017 03:42:30 -0400 Received: from mga09.intel.com ([134.134.136.24]:22891 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977AbdCQHm3 (ORCPT ); Fri, 17 Mar 2017 03:42:29 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,176,1486454400"; d="scan'208";a="77518361" From: "Reshetova, Elena" To: David Miller , "keescook@chromium.org" CC: "eric.dumazet@gmail.com" , "peterz@infradead.org" , "netdev@vger.kernel.org" , "bridge@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "kuznet@ms2.inr.ac.ru" , "jmorris@namei.org" , "kaber@trash.net" , "stephen@networkplumber.org" , "ishkamiel@gmail.com" , "dwindsor@gmail.com" Subject: RE: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Thread-Topic: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Thread-Index: AQHSnmowscbxA7tY7kibO+jdaWvt8qGXsFsAgAALC4CAABm8AIAA0YbA Date: Fri, 17 Mar 2017 07:42:24 +0000 Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C5A53B@IRSMSX102.ger.corp.intel.com> References: <1489678147-21404-8-git-send-email-elena.reshetova@intel.com> <1489683534.28631.231.camel@edumazet-glaptop3.roam.corp.google.com> <20170316.121032.405930218798336643.davem@davemloft.net> In-Reply-To: <20170316.121032.405930218798336643.davem@davemloft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" 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 quoted-printable to 8bit by mail.home.local id v2H7gZ5Z004632 Content-Length: 755 Lines: 20 > From: Kees Cook > Date: Thu, 16 Mar 2017 11:38:25 -0600 > > > I am, of course, biased, but I think the evidence of actual > > refcounting attacks outweighs the theoretical performance cost of > > these changes. > > This is not theoretical at all. > > We count the nanoseconds that every packet takes to get processed and > you are adding quite a bit. > > I understand your point of view, but this is knowingly going to add > performance regressions to the networking code. Should we then first measure the actual numbers to understand what we are talking here about? I would be glad to do it if you suggest what is the correct way to do measurements here to actually reflect the real life use cases. Best Regards, Elena.