From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00042.outbound.protection.outlook.com [40.107.0.42]) by dpdk.org (Postfix) with ESMTP id 61BBB10A3 for ; Mon, 29 Oct 2018 19:54:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=99SdILAuE06MjJI2jjmxbB+pt+yJbh69KE6/H13jcms=; b=KdWIPkTMwYQxHSlWFCqDjD8tUgbcVIf2Rw4EDSt2FEfqBaY6sKTfHe1MYtumfTdthpXRhSmSIovM1v7S5BCSzIZ0SUTW2Fp++FRJxZxYolx6bnP2KItHdIKGEVZbNq3Prh9H3xeIRKc8L7wYXtKqJJu59aof/Sc6yJ42zh73oQQ= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4010.eurprd05.prod.outlook.com (52.134.66.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.26; Mon, 29 Oct 2018 18:54:34 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::f8a1:fcab:94f0:97cc]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::f8a1:fcab:94f0:97cc%4]) with mapi id 15.20.1273.027; Mon, 29 Oct 2018 18:54:34 +0000 From: Yongseok Koh To: Alejandro Lucero CC: "lei.a.yao@intel.com" , Thomas Monjalon , dev , "Xu, Qian Q" , "xueqin.lin@intel.com" , "Burakov, Anatoly" , Ferruh Yigit Thread-Topic: [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask Thread-Index: AQHUXKl/tu1Uh92BykeDk/LirOnyNaU1SkEAgAC90YCAAAVSgIAADvgAgAADY4CAAAZagIAAAVgAgAAXRACAAAIagIAAEzoAgAAGTACAAAZQAIAACoWAgABNK4A= Date: Mon, 29 Oct 2018 18:54:34 +0000 Message-ID: <621BE501-6B10-4053-AC33-50ABE0231A44@mellanox.com> References: <1538743527-8285-1-git-send-email-alejandro.lucero@netronome.com> <2DBBFF226F7CF64BAFCA79B681719D954502B94F@shsmsx102.ccr.corp.intel.com> <3483377.PMXnpSGLS9@xps> In-Reply-To: <3483377.PMXnpSGLS9@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-originating-ip: [69.181.245.183] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0502MB4010; 6:PGij7UPYcO3nzF4jMvnVKiBqByow6mYqQ3S9jy5xrF4nXf6ZwIIhlcPUY6Hc28cGN7xHI+0bVWbPYnCJ1mZuHwSoQ0ObzbrOCLL2LgJSCnjHDWn8UufV1g9O24X6tz+GGy5ETLhJCZTCy7ue4mjS72wmVAGGt4ktB7nHVRwAYKREaa9GBBN7KXWokwQGzjAXiCe1Tl3pyIH6rAlH5ud2p/2hwS528hCk5lBFVz+2JYGlJPCk4RgwqCBJ4ms0ZYh9Rbw0nvnlVO1As80BdnHQzfbPZiMnQ6p9jGVmjh7h2lOZV9chAbxT8SV5TQp0eXVBsOJPw4FjhuvlezAKZ9Ne9yJj3/ZAEorXVWPRLfyhKhqdeizdcoijjv6a7LLpP5OsvujKL7Tg6HacFQ59FSEm9iWzzWEVsZPJx2rHRVf12/miL4IHPqdnULM5r2LIDAdVChGvmK8W80l9vCKyAfeqFA==; 5:8S+Cw0eMvQxoAm/5C8ceiMyrvCRZjCUTRnG+Lk+DzXLdgL4xuV1CzmSysDsuGTOJv3ZUNB9w8D2+MKn63Ptm/XDawgoVheDA/f9S96hYx4J1Qv/jk8DUqzFrCt+2V2MiEr8s0y6bG2hS3H4nT/XOzs1YNyeqleOCvHMDykF9Hq8=; 7:b4M2qOrwrV6L503I260n+FqU8zm2DGOI1zlonSTvQDdqRjSR20ni+jCNSzz21uVLHMnG49C9anPLMu3uEPlibtLbDBs8IOMv96rJ6Jn48RucMKxwZZKRl8rFKitkTPQMMCZe6WdgV55sk9H/lvtjfw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 64801769-b7b0-4a9b-f938-08d63dcff7d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0502MB4010; x-ms-traffictypediagnostic: DB3PR0502MB4010: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DB3PR0502MB4010; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB4010; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(136003)(376002)(39860400002)(189003)(52314003)(199004)(52084003)(102836004)(316002)(8936002)(33656002)(99286004)(478600001)(14454004)(8676002)(6506007)(105586002)(81156014)(81166006)(256004)(229853002)(25786009)(53546011)(4326008)(6512007)(26005)(2616005)(5024004)(14444005)(6916009)(106356001)(66066001)(76176011)(54906003)(86362001)(7736002)(5250100002)(6436002)(446003)(11346002)(305945005)(53936002)(68736007)(476003)(39060400002)(6246003)(486006)(5660300001)(97736004)(82746002)(93886005)(186003)(2900100001)(3846002)(6116002)(83716004)(71190400001)(6486002)(2906002)(71200400001)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4010; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: N7OO5S4H9PdXLcpGvXtF+rbnGdreeTJe0Vpz0IzICI31nzeob6RNKQaNuQ/xV9IS/k4XPqNAPmmzY7s5NW8FeTA/+oyYwgvSSHR3xaViSG5hJKX2AKZADD+PAsIEPhwLvQWKpLXQs9Ap8hyVfKQzA+nnKYkDgspDKKF7Et0BXQDXm1s5m4jize1yk1bzWo5zVSK1zJWvGoSk/uaWR8Y2jOgX6P2v22Kg/ylHnbZVaG7wTlzTh9RAsCGZBWF5QqDXHYq9REiMPKxzuUFF9ddlrn9Ngcshkfaaqpso93KFyQWfpziW2P8fwO4FVtPmqnnFLI+x6bdOgSFmlFJqnOjw1C0SG5TL6JMBYCLDQUsfojQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64801769-b7b0-4a9b-f938-08d63dcff7d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 18:54:34.3625 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4010 Subject: Re: [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask 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: , X-List-Received-Date: Mon, 29 Oct 2018 18:54:36 -0000 > On Oct 29, 2018, at 7:18 AM, Thomas Monjalon wrote: >=20 > 29/10/2018 14:40, Alejandro Lucero: >> On Mon, Oct 29, 2018 at 1:18 PM Yao, Lei A wrote: >>> *From:* Alejandro Lucero [mailto:alejandro.lucero@netronome.com] >>> On Mon, Oct 29, 2018 at 11:46 AM Thomas Monjalon >>> wrote: >>>=20 >>> 29/10/2018 12:39, Alejandro Lucero: >>>> I got a patch that solves a bug when calling rte_eal_dma_mask using th= e >>>> mask instead of the maskbits. However, this does not solves the >>> deadlock. >>>=20 >>> The deadlock is a bigger concern I think. >>>=20 >>> I think once the call to rte_eal_check_dma_mask uses the maskbits inste= ad >>> of the mask, calling rte_memseg_walk_thread_unsafe avoids the deadlock. >>>=20 >>> Yao, can you try with the attached patch? >>>=20 >>> Hi, Lucero >>>=20 >>> This patch can fix the issue at my side. Thanks a lot >>> for you quick action. >>=20 >> Great! >>=20 >> I will send an official patch with the changes. >=20 > Please, do not forget my other request to better comment functions. Alejandro, This patchset has been merged to stable/17.11 per your request for the last= release. You must send a fix to stable/17.11 as well, if you think there's a same is= sue there. Thanks, Yongseok >> I have to say that I tested the patchset, but I think it was where >> legacy_mem was still there and therefore dynamic memory allocation code = not >> used during memory initialization. >>=20 >> There is something that concerns me though. Using >> rte_memseg_walk_thread_unsafe could be a problem under some situations >> although those situations being unlikely. >>=20 >> Usually, calling rte_eal_check_dma_mask happens during initialization. T= hen >> it is safe to use the unsafe function for walking memsegs, but with devi= ce >> hotplug and dynamic memory allocation, there exists a potential race >> condition when the primary process is allocating more memory and >> concurrently a device is hotplugged and a secondary process does the dev= ice >> initialization. By now, this is just a problem with the NFP, and the >> potential race condition window really unlikely, but I will work on this >> asap. >=20 > Yes, this is what concerns me. > You can add a comment explaining the unsafe which is not handled. >=20 >=20 >>>> Interestingly, the problem looks like a compiler one. Calling >>>> rte_memseg_walk does not return when calling inside rt_eal_dma_mask, >>> but if >>>> you modify the call like this: >>>>=20 >>>> - if (rte_memseg_walk(check_iova, &mask)) >>>> + if (!rte_memseg_walk(check_iova, &mask)) >>>>=20 >>>> it works, although the value returned to the invoker changes, of cours= e. >>>> But the point here is it should be the same behaviour when calling >>>> rte_memseg_walk than before and it is not. >>>=20 >>> Anyway, the coding style requires to save the return value in a variabl= e, >>> instead of nesting the call in an "if" condition. >>> And the "if" check should be explicitly !=3D 0 because it is not a real >>> boolean. >>>=20 >>> PS: please do not top post and avoid HTML emails, thanks >>>=20 >>>=20 >>=20 >=20 >=20 >=20 >=20 >=20