From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 29E2AA0573; Thu, 5 Mar 2020 16:42:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 81C872BA8; Thu, 5 Mar 2020 16:42:27 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 13199FEB for ; Thu, 5 Mar 2020 16:42:24 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2020 07:42:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,518,1574150400"; d="scan'208";a="439536031" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga005.fm.intel.com with ESMTP; 05 Mar 2020 07:42:21 -0800 Received: from sivswdev09.ir.intel.com (sivswdev09.ir.intel.com [10.237.217.48]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 025FgL3M030183; Thu, 5 Mar 2020 15:42:21 GMT Received: from sivswdev09.ir.intel.com (localhost [127.0.0.1]) by sivswdev09.ir.intel.com with ESMTP id 025FgKRT002205; Thu, 5 Mar 2020 15:42:20 GMT Received: (from lma25@localhost) by sivswdev09.ir.intel.com with LOCAL id 025FgIIZ002185; Thu, 5 Mar 2020 15:42:18 GMT Date: Thu, 5 Mar 2020 15:42:18 +0000 From: "Liang, Ma" To: "Ananyev, Konstantin" Cc: "Richardson, Bruce" , ZY Qiu , Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , "dev@dpdk.org" , ZY Qiu Message-ID: <20200305154218.GA1340@sivswdev09.ir.intel.com> References: <20200304140543.31612-1-tgw_team@tencent.com> <20200304173349.26459-1-tgw_team@tencent.com> <20200305091952.GA289@bricha3-MOBL.ger.corp.intel.com> <20200305144712.GA7829@sivswdev09.ir.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v2] rte_ethdev: safer memory access by calling Rx callback X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 05 Mar 07:19, Ananyev, Konstantin wrote: > > > On 05 Mar 11:27, Ananyev, Konstantin wrote: > > > > > > > > > > > > > > On Thu, Mar 05, 2020 at 01:33:49AM +0800, ZY Qiu wrote: > > > > > When compiling with -O0, > > > > > the compiler does not optimize two memory accesses into one. > > > > > Leads to accessing a null pointer when queue post Rx burst callback > > > > > removal while traffic is running. > > > > > See rte_eth_tx_burst function. > > > > > > > > > > Signed-off-by: ZY Qiu > > > > > --- > > > > > lib/librte_ethdev/rte_ethdev.h | 6 ++---- > > > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > > > > > index d1a593ad1..35eb580ff 100644 > > > > > --- a/lib/librte_ethdev/rte_ethdev.h > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h > > > > > @@ -4388,10 +4388,8 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id, > > > > > rx_pkts, nb_pkts); > > > > > > > > > > #ifdef RTE_ETHDEV_RXTX_CALLBACKS > > > > > -if (unlikely(dev->post_rx_burst_cbs[queue_id] != NULL)) { > > > > > -struct rte_eth_rxtx_callback *cb = > > > > > -dev->post_rx_burst_cbs[queue_id]; > > > > > - > > > > > +struct rte_eth_rxtx_callback *cb = dev->post_rx_burst_cbs[queue_id]; > > > > > +if (unlikely(cb != NULL)) { > > > > > do { > > > > > nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx, > > > > > nb_pkts, cb->param); > > > > > -- > > > > > 2.17.1 > > > > While I don't have an issue with this fix, can you explain as to why this is a > > > > problem that needs to be fixed? Normally TOCTOU issues are flagged and > > > > fixed for external resources e.g. files, that can be modified between check > > > > and use, but this is just referencing internal data in the program itself, > > > > so I'm wondering what the risk is? From a security viewpoint if an attacker > > > > can modify the function pointers in our code, is it not already "game over" > > > > for keeping the running program safe? > > > > > > > > > > Right now RX/TX cb functions are not protected by any sync mechanism. > > > So while dataplane thread can do RX/TX control threads supposed to > > > be able to add/remove callbacks. > > > I am agree with Stephen here, we probably need either (volatile *) > > > or compiler_barrier() here. > > > > > > > > For my opinion, > > the key question here is if the abstract layer code has to be thread safe or application > > developer look after thread safe of key data structure ? > > > > 1. Single thread case : > > Current code has no issue even compiler behavior is different with -O0 or O3. > > -O3 merge 2 loads into 1, -O0 still use 2 loads. > > > > 2. Multiple thread case: > > As Konstantin said, there is no sync primitive to protect cb pointer at all. > > Because of X86 64bit memory access is atomic, then, -O3 and -O0 will lead to totally different result. > > I don’t think that's a fix because a Fix cannot depend on specific Arch is strong memory order or weak memory order. > > > > Volatile or memory barrier may not fix this with a general style for multi-threads. > > Can you elaborate why? > From my perspective compiler_barrier seems enough here. I suspect rte_mb() here may not solve the problem for the weak memory order arch. > > > > > I will suggest add comment to clarify the scenario and let developer make decision. > > > > Regards >