From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id B008A1B579; Wed, 27 Jun 2018 14:25:40 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2018 05:25:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,278,1526367600"; d="scan'208";a="67726146" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga001.fm.intel.com with ESMTP; 27 Jun 2018 05:25:33 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 27 Jun 2018 05:25:32 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 27 Jun 2018 05:25:32 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.51]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.116]) with mapi id 14.03.0319.002; Wed, 27 Jun 2018 20:25:30 +0800 From: "Zhang, Qi Z" To: "Burakov, Anatoly" , "dev@dpdk.org" CC: "stable@dpdk.org" Thread-Topic: [PATCH] ipc: fix locking while sending messages Thread-Index: AQHUDft7m4uoLw+40ku3zVcHPj6LOaR0B6mw Date: Wed, 27 Jun 2018 12:25:30 +0000 Message-ID: <039ED4275CED7440929022BC67E706115323F36E@SHSMSX103.ccr.corp.intel.com> References: <164824cc66c16755416bb8d3d6911385f52f8c1e.1530092380.git.anatoly.burakov@intel.com> In-Reply-To: <164824cc66c16755416bb8d3d6911385f52f8c1e.1530092380.git.anatoly.burakov@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmZiNmQ4NDktMjEzMS00NmQ4LTg4MDUtYjIxMGY3ODQwNGFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTk9hZDJtaWJYdlFjR2MzTktmNzBXcE94OStjWjVkMDVVdkx1aHNoRE51SFc4TnpJWWNaYkpWbWNFQWRIcE41bCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-stable] [PATCH] ipc: fix locking while sending messages X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 12:25:41 -0000 > -----Original Message----- > From: Burakov, Anatoly > Sent: Wednesday, June 27, 2018 5:44 PM > To: dev@dpdk.org > Cc: Zhang, Qi Z ; stable@dpdk.org > Subject: [PATCH] ipc: fix locking while sending messages >=20 > Previously, we were putting an exclusive lock to prevent secondary proces= ses > spinning up while we are sending our messages. However, using exclusive > locks had an effect of disallowing multiple simultaenous unrelated > messages/requests being sent, which was not the intention behind locking. >=20 > Fix it to put a shared lock on the directory. That way, we still prevent > secondary process initializations while sending data over IPC, but allow > multiple unrelated transmissions to proceed. >=20 > Fixes: 89f1fe7e6d95 ("eal: lock IPC directory on init and send") > Cc: stable@dpdk.org >=20 > Signed-off-by: Anatoly Burakov Tested-by: Qi Zhang Thanks for the quick fix! Qi > --- >=20 > Notes: > This patch is needed for multiprocess hotplug support [1], to avoid c= ases > where multiple requests deadlock while in progress. >=20 > [1] http://patches.dpdk.org/project/dpdk/list/?series=3D252 >=20 > lib/librte_eal/common/eal_common_proc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >=20 > diff --git a/lib/librte_eal/common/eal_common_proc.c > b/lib/librte_eal/common/eal_common_proc.c > index 707d8ab30..f010ef59e 100644 > --- a/lib/librte_eal/common/eal_common_proc.c > +++ b/lib/librte_eal/common/eal_common_proc.c > @@ -786,7 +786,7 @@ mp_send(struct rte_mp_msg *msg, const char *peer, > int type) >=20 > dir_fd =3D dirfd(mp_dir); > /* lock the directory to prevent processes spinning up while we send */ > - if (flock(dir_fd, LOCK_EX)) { > + if (flock(dir_fd, LOCK_SH)) { > RTE_LOG(ERR, EAL, "Unable to lock directory %s\n", > mp_dir_path); > rte_errno =3D errno; > @@ -1020,7 +1020,7 @@ rte_mp_request_sync(struct rte_mp_msg *req, > struct rte_mp_reply *reply, >=20 > dir_fd =3D dirfd(mp_dir); > /* lock the directory to prevent processes spinning up while we send */ > - if (flock(dir_fd, LOCK_EX)) { > + if (flock(dir_fd, LOCK_SH)) { > RTE_LOG(ERR, EAL, "Unable to lock directory %s\n", > mp_dir_path); > closedir(mp_dir); > @@ -1146,7 +1146,7 @@ rte_mp_request_async(struct rte_mp_msg *req, > const struct timespec *ts, > dir_fd =3D dirfd(mp_dir); >=20 > /* lock the directory to prevent processes spinning up while we send */ > - if (flock(dir_fd, LOCK_EX)) { > + if (flock(dir_fd, LOCK_SH)) { > RTE_LOG(ERR, EAL, "Unable to lock directory %s\n", > mp_dir_path); > rte_errno =3D errno; > -- > 2.17.1