From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH V4 5/9] bus: add helper to handle sigbus Date: Fri, 29 Jun 2018 14:52:00 +0200 Message-ID: <20180629125200.uefvrokdg5nqthrl@bidouze.vm.6wind.com> References: <1498711073-42917-1-git-send-email-jia.guo@intel.com> <1530268248-7328-1-git-send-email-jia.guo@intel.com> <1530268248-7328-6-git-send-email-jia.guo@intel.com> <2601191342CEEE43887BDE71AB977258C0C43A49@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258C0C43C71@irsmsx105.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "Guo, Jia" , "stephen@networkplumber.org" , "Richardson, Bruce" , "Yigit, Ferruh" , "Wu, Jingjing" , "thomas@monjalon.net" , "motih@mellanox.com" , "matan@mellanox.com" , "Van Haaren, Harry" , "Zhang, Qi Z" , "He, Shaopeng" , "Iremonger, Bernard" , "jblunck@infradead.org" , "shreyansh.jain@nxp.com" , "dev@dpdk.org" , "Zhang, Helin" To: "Ananyev, Konstantin" Return-path: Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by dpdk.org (Postfix) with ESMTP id 9E34A1B471 for ; Fri, 29 Jun 2018 14:52:18 +0200 (CEST) Received: by mail-wr0-f194.google.com with SMTP id l2-v6so8177866wro.7 for ; Fri, 29 Jun 2018 05:52:18 -0700 (PDT) Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB977258C0C43C71@irsmsx105.ger.corp.intel.com> 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 Fri, Jun 29, 2018 at 12:21:39PM +0000, Ananyev, Konstantin wrote: > > > > -----Original Message----- > > From: Guo, Jia > > Sent: Friday, June 29, 2018 12:23 PM > > To: Ananyev, Konstantin ; stephen@networkplumber.org; Richardson, Bruce > > ; Yigit, Ferruh ; gaetan.rivet@6wind.com; Wu, Jingjing > > ; thomas@monjalon.net; motih@mellanox.com; matan@mellanox.com; Van Haaren, Harry > > ; Zhang, Qi Z ; He, Shaopeng ; Iremonger, Bernard > > > > Cc: jblunck@infradead.org; shreyansh.jain@nxp.com; dev@dpdk.org; Zhang, Helin > > Subject: Re: [PATCH V4 5/9] bus: add helper to handle sigbus > > > > hi, konstantin > > > > > > On 6/29/2018 6:51 PM, Ananyev, Konstantin wrote: > > >> +int > > >> +rte_bus_sigbus_handler(const void *failure_addr) > > >> +{ > > >> + struct rte_bus *bus; > > >> + int old_errno = rte_errno; > > >> + int ret = 0; > > >> + > > >> + rte_errno = 0; > > >> + > > >> + bus = rte_bus_find(NULL, bus_handle_sigbus, failure_addr); > > >> + if (bus == NULL) { > > >> + RTE_LOG(ERR, EAL, "No bus can handle the sigbus error!"); > > >> + ret = -1; > > >> + } else if (rte_errno != 0) { > > >> + RTE_LOG(ERR, EAL, "Failed to handle the sigbus error!"); > > >> + ret = -1; > > >> + } > > >> + > > >> + /* if sigbus not be handled, return back old errno. */ > > >> + if (ret) > > >> + rte_errno = old_errno; > > > Hmm, not sure why we need to set/restore rte_errno here? > > > > restore old_errno just use to let caller know that the generic sigbus > > still not handler by bus hotplug handler, that involve find a bus > > handle but failed and can not find a hander, and can corresponding use > > the previous sigbus handler to process it. > > that is also unwser your question in other patch. do you think that make > > sense? > > Sorry, still don't understand the intention. > Suppose rte_bus_find() will return NULL, in that case you'll setup rte_errno > to what it was before calling that function. > If the returned bus is not NULL, but bus_find() set's an rte_errno, > you still would restore rte_ernno? > What is the prupose? > Why do you need to touch rte_errno at all in that function? > Konstantin > The way it is written here does not work, but the intention is to make sure that a previous error is still catched. Something like that: int old_errno = rte_errno; rte_errno = 0; rte_eal_call(); if (rte_errno) return -1; else { rte_errno = old_errno; return 0; } If someone calls the function while rte_errno is already set, then an earlier error would be hidden by setting rte_errno to 0 within the function. I'm not sure this is useful, but sometimes when using errno within a library call I'm bothered that I am masking previous issues. Should it be avoided? -- Gaëtan Rivet 6WIND