From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 677334F98 for ; Tue, 18 Sep 2018 11:43:13 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 16C0B21FEB; Tue, 18 Sep 2018 05:43:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 18 Sep 2018 05:43:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=+wQZ6jyu352WqGG5qFK1sd/JAb 0G3Uhj9SIAnDJA3Nw=; b=MLCsV07iZWUbsZTIMKNY5zcz53iTtZZNgDXgyZh/El 6Cek2mVYhI+IpXXpL8I1hz9KaiEUjfzuGDFHZoxfViZIaNGHXl0XbbofHZmEcer4 mzT6f6UBfGkOvlIbeTQgDC7ldmAGKZIAJXat/DiMCAa+EAH2jhD2qnZ8CP5qONLv g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+wQZ6j yu352WqGG5qFK1sd/JAb0G3Uhj9SIAnDJA3Nw=; b=Yl5gK8QQG25tfXt5zDXL7r tMIYo6iz6KlwaTrurrFhyocJsw+lb8LODM44/XX4O/mJklJ+NQPRguzI8hJrlytx mC0AGdPel+5K+E1JDjmKxwetE+oLhwX8SaWYJvkCSp9P3mCqTWsb/2tn0wLlWB2g NNIq8ZD8xEaMqBCNOQxEJ9bmbxq6QaAbQd7iiLW0Hlrlwh5H6gfpaKQvs+wj0YX+ HDNDoHEDlCCnDiLM6RFVsIvFouKsSSUj+bDNyQ3MBn/vZwFf/Y/ZUAGGJmjtoF3U Z+1o9JfXvCS0JBq2Rn3mt1WhieOQfBJ4ld9eltCnhXmU1D9VCZLCZtdRPZLZxKbQ == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id EA9A7E47C2; Tue, 18 Sep 2018 05:43:11 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org, Stephen Hemminger , Stephen Hemminger Date: Tue, 18 Sep 2018 11:43:10 +0200 Message-ID: <1622402.chDL49Ktjv@xps> In-Reply-To: <578857d9-e544-f1ce-bad2-a79fa6d78f94@intel.com> References: <20180725182019.31518-1-stephen@networkplumber.org> <20180725182019.31518-4-stephen@networkplumber.org> <578857d9-e544-f1ce-bad2-a79fa6d78f94@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 3/4] eal: don't crash if alarm set fails 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: Tue, 18 Sep 2018 09:43:13 -0000 26/07/2018 11:41, Burakov, Anatoly: > On 25-Jul-18 7:20 PM, Stephen Hemminger wrote: > > There is no need to call rte_exit and crash the application here; > > better to let the application handle the error itself. > > > > Remove the gratuitous profanity which would be visible if > > the rte_exit was still there. > > > > Signed-off-by: Stephen Hemminger > > --- > > --- a/lib/librte_eal/common/eal_common_proc.c > > +++ b/lib/librte_eal/common/eal_common_proc.c > > @@ -841,14 +841,12 @@ mp_request_async(const char *dst, struct rte_mp_msg *req, > > > > param->user_reply.nb_sent++; > > > > - if (rte_eal_alarm_set(ts->tv_sec * 1000000 + ts->tv_nsec / 1000, > > - async_reply_handle, pending_req) < 0) { > > + ret = rte_eal_alarm_set(ts->tv_sec * 1000000 + ts->tv_nsec / 1000, > > + async_reply_handle, pending_req); > > + if (ret < 0) > > RTE_LOG(ERR, EAL, "Fail to set alarm for request %s:%s\n", > > dst, req->name); > > - rte_panic("Fix the above shit to properly free all memory\n"); > > Profanity aside, i think the message was trying to tell me something - > namely, that if alarm_set fails, we're risking to leak this memory if > reply from the peer never comes, and we're risking leaving the > application hanging because the timeout never triggers. I'm not sure if > leaving this "to the user" is the right choice, because there is no way > for the user to free IPC-internal memory if it leaks. > > So i think the proper way to handle this would've been to set the alarm > first, then, if it fails, don't sent the message in the first place. What should be done here? OK to remove rte_panic for now?