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 72077A0573; Thu, 5 Mar 2020 12:27:54 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C2AC42BB8; Thu, 5 Mar 2020 12:27:53 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 33CA5FEB for ; Thu, 5 Mar 2020 12:27:51 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2020 03:27:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,517,1574150400"; d="scan'208";a="240787594" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga003.jf.intel.com with ESMTP; 05 Mar 2020 03:27:50 -0800 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 5 Mar 2020 03:27:50 -0800 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 5 Mar 2020 03:27:49 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 5 Mar 2020 03:27:49 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lkhD4JX6qo8Ffqb9dJ5McXNiuOJZSt0I3xZLOYcIMjkUPF0vUL3WTo7Fc58jaiaM2ZqtoNX2PHzgImvnyCZpAX2hSHeCus3F++ittYLiRQBE+iDbaeQ1s8ECVgWBQ9E9OF7BuIFRPm5MbdOixk/lWj8JEbdVJSpjJN6XRmS1Bx7JDNxBV7AoCCuDk2VOzO8MsH/LB6zRnraOCsOJAUZmJT4qggxDDmfpMPh16+ziQEqG6L16uNUIhP+ADnYYPdLZseWQts0ox5K17S/h/rcoftsNKtWZ5Db6DIPBStCva2xGpYKxcR8AeT2aW+Pmo3CssQ1wyEE3EL74bxHzdxxS/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=78fa9uiUS1D+zyEMRWiZilMOP6N3C9uHX1nand3TLI0=; b=EQVo6UveYGNyyrdLQcjzwzgPNtYIa5MDHEStkRJXj1OWaXZbsj+26m328tTfrwQH7cNtrOsY7WbJ/R8JjbC+H+bHKQ0o/e8HvdF2stB3nPUqdYp1qhbsj4l3LNE+gMoUIC5xQAd4VXCCaCa62J1Fa3E8FpnGcN/uyDhOuGEvTIUhszxnZlsuN2zCB0Fa/MHfgBXc361BNq2CkghRKO96SHwjjF5CmKDCBz2wdS1WcZlUjb5b3X+MhcJ4v5kfJEUhucRAUnuiQTa37cJ85oBTV50bp+4/a+DlRsH76pFJllprO8JOaw7WS1g9RCAZuBPPl4DnNHMjPNlKpJBeChzCfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=78fa9uiUS1D+zyEMRWiZilMOP6N3C9uHX1nand3TLI0=; b=AGim5pDD7ZQAS6YUCaZcXA611x//hgWvit0YZN5iXkTZlg46TT5X8pikljchS3QAMPnNvkg85qCZ8Y/wl/kZY9v8CAr6iql+FWBplr5bKL0TWS9FCxdfgOE2BFY9bOHupIIhxe9buUwogCBrBA2jBnEggXncKD4Z2RBtj0iRm1U= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (2603:10b6:805:5d::19) by SN6PR11MB2942.namprd11.prod.outlook.com (2603:10b6:805:cb::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Thu, 5 Mar 2020 11:27:37 +0000 Received: from SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::395e:eb75:6ab7:2ba5]) by SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::395e:eb75:6ab7:2ba5%3]) with mapi id 15.20.2772.019; Thu, 5 Mar 2020 11:27:37 +0000 From: "Ananyev, Konstantin" To: "Richardson, Bruce" , ZY Qiu CC: Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , "dev@dpdk.org" , ZY Qiu Thread-Topic: [dpdk-dev] [PATCH v2] rte_ethdev: safer memory access by calling Rx callback Thread-Index: AQHV8s9RNmSH6PK9K0OOauo0HKO4Gag524rw Date: Thu, 5 Mar 2020 11:27:37 +0000 Message-ID: References: <20200304140543.31612-1-tgw_team@tencent.com> <20200304173349.26459-1-tgw_team@tencent.com> <20200305091952.GA289@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20200305091952.GA289@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGE2YjU3MjUtNDZkZS00ZDJmLWFjODEtMWYyNGNhYzcyMzcyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUXJ3U3IrblRHNU12TVpPTVc0b1FlNThTSlRqdDFtY1J0aGp1ZmdJNDZiUlhsamY5S3pBamhHK2wxUEwrN3ZFeSJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06a54cf1-dc5a-4d06-95b2-08d7c0f83571 x-ms-traffictypediagnostic: SN6PR11MB2942: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(376002)(366004)(346002)(39860400002)(199004)(189003)(33656002)(9686003)(7696005)(55016002)(76116006)(71200400001)(52536014)(5660300002)(66446008)(6506007)(66476007)(66556008)(64756008)(8676002)(54906003)(478600001)(316002)(110136005)(2906002)(4326008)(66946007)(8936002)(86362001)(81166006)(186003)(81156014)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB2942; H:SN6PR11MB2558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Dn5bWTDdcqYph23JgJi8cH1aZylC5UPpEY5KItkU/We7ZhdNzAZetrICX1e9JnqDAh/Ysc61kZUT+/YpPe8hceRArZqFqF6DeRbvlsHf/1bCYQopOclg+9Y5J2P6WjM5MlExKvZfaTMYXXYSKa4AhB+D67qjut5nbhVV+Pqrhuc94c1KPGz2TSDVVk2/Bvb2X/CwJA44uHMgo+ZRk7s4OVbQ0Jxy7PyynDNuRpWGvH0X/G+vwfuQ0NTKYuEAMQyY/05UV+TY2MgSGttjwFrromq+hh/AXnWT38RVdRp+KE6as1pNcdaxvmRqhQ8dxV4z1lMcqqXIpPGSqH0X4GMIslh7WF6P02cW8CH8QjX3OYbeUvUxQqhovtDxZxSVVPQRPcAhZs7u3Yn4F9UCaBVK+esH8PuOvmI6rvv9DsO1vm/QEEk0+Hnag+QJ1f9ZgMv8 x-ms-exchange-antispam-messagedata: KDIFMK3mCi5c3+h9vZskWXhPXCGHbf+RvLgTeJRSX1W88g/P9+W7onlgN2stFTJDgnrrFasvxZ7Aa8txdf+wNAMBH3pjj7ZKoYusOlMHErQgeNBBrkU9W5BiG21Rx6ksK+zFFEiwMcc4DmTGHkvBTQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06a54cf1-dc5a-4d06-95b2-08d7c0f83571 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 11:27:37.5664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: t1TGse7BxXPn3Iy25Hke+q1N/4N/0DmDFptM5RKohkJqIGK2muRpHilNah8NRfZb4d1p36J5EIbxc1D5mp8kMHjfQ+JhGMchnaXmLc/bFR0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2942 X-OriginatorOrg: intel.com 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" >=20 > 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_eth= dev.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 queu= e_id, > > rx_pkts, nb_pkts); > > > > #ifdef RTE_ETHDEV_RXTX_CALLBACKS > > - if (unlikely(dev->post_rx_burst_cbs[queue_id] !=3D NULL)) { > > - struct rte_eth_rxtx_callback *cb =3D > > - dev->post_rx_burst_cbs[queue_id]; > > - > > + struct rte_eth_rxtx_callback *cb =3D dev->post_rx_burst_cbs[queue_id]= ; > > + if (unlikely(cb !=3D NULL)) { > > do { > > nb_rx =3D 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 che= ck > 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 attack= er > can modify the function pointers in our code, is it not already "game ove= r" > for keeping the running program safe? >=20 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.