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 3DA0BA0573; Thu, 5 Mar 2020 15:47:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 78CB72BB8; Thu, 5 Mar 2020 15:47:23 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 45A38FEB for ; Thu, 5 Mar 2020 15:47:21 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2020 06:47:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,518,1574150400"; d="scan'208";a="387517029" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by orsmga004.jf.intel.com with ESMTP; 05 Mar 2020 06:47:17 -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 025ElHXN009366; Thu, 5 Mar 2020 14:47:17 GMT Received: from sivswdev09.ir.intel.com (localhost [127.0.0.1]) by sivswdev09.ir.intel.com with ESMTP id 025ElGL7021162; Thu, 5 Mar 2020 14:47:16 GMT Received: (from lma25@localhost) by sivswdev09.ir.intel.com with LOCAL id 025ElCOX021134; Thu, 5 Mar 2020 14:47:12 GMT Date: Thu, 5 Mar 2020 14:47:12 +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: <20200305144712.GA7829@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> 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 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. I will suggest add comment to clarify the scenario and let developer make decision. Regards