From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id AA04E1B058 for ; Wed, 11 Jul 2018 04:15:18 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 19:15:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,336,1526367600"; d="scan'208";a="56709255" Received: from jguo15x-mobl3.ccr.corp.intel.com (HELO [10.67.68.71]) ([10.67.68.71]) by orsmga006.jf.intel.com with ESMTP; 10 Jul 2018 19:15:14 -0700 To: Stephen Hemminger References: <1498711073-42917-1-git-send-email-jia.guo@intel.com> <1530268248-7328-1-git-send-email-jia.guo@intel.com> <1530268248-7328-4-git-send-email-jia.guo@intel.com> <20180710145531.7fbd3366@xeon-e3> Cc: bruce.richardson@intel.com, ferruh.yigit@intel.com, konstantin.ananyev@intel.com, gaetan.rivet@6wind.com, jingjing.wu@intel.com, thomas@monjalon.net, motih@mellanox.com, matan@mellanox.com, harry.van.haaren@intel.com, qi.z.zhang@intel.com, shaopeng.he@intel.com, bernard.iremonger@intel.com, jblunck@infradead.org, shreyansh.jain@nxp.com, dev@dpdk.org, helin.zhang@intel.com From: Jeff Guo Message-ID: <1810f1ed-06bb-8dad-3d38-db2128f351fb@intel.com> Date: Wed, 11 Jul 2018 10:15:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20180710145531.7fbd3366@xeon-e3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH V4 3/9] bus: introduce sigbus handler 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: Wed, 11 Jul 2018 02:15:19 -0000 On 7/11/2018 5:55 AM, Stephen Hemminger wrote: > On Fri, 29 Jun 2018 18:30:42 +0800 > Jeff Guo wrote: > >> When device be hotplug, if data path still read/write device, the sigbus >> error will occur, this error need to be handled. So a handler need to be >> here to capture the signal and handle it correspondingly. >> >> To handle sigbus error is a bus-specific behavior, this patch introduces >> a bus ops so that each kind of bus can implement its own logic. >> >> Signed-off-by: Jeff Guo >> --- >> v4->v3: >> split patches to be small and clear. >> --- >> lib/librte_eal/common/include/rte_bus.h | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/lib/librte_eal/common/include/rte_bus.h b/lib/librte_eal/common/include/rte_bus.h >> index 3642aeb..231bd3d 100644 >> --- a/lib/librte_eal/common/include/rte_bus.h >> +++ b/lib/librte_eal/common/include/rte_bus.h >> @@ -181,6 +181,20 @@ typedef int (*rte_bus_parse_t)(const char *name, void *addr); >> typedef int (*rte_bus_hotplug_handler_t)(struct rte_device *dev); >> >> /** >> + * Implementation a specific sigbus handler, which is responsible >> + * for handle the sigbus error which is original memory error, or specific >> + * memory error that caused of hot unplug. >> + * @param failure_addr >> + * Pointer of the fault address of the sigbus error. >> + * >> + * @return >> + * 0 for success handle the sigbus. >> + * 1 for no handle the sigbus. >> + * -1 for failed to handle the sigbus >> + */ >> +typedef int (*rte_bus_sigbus_handler_t)(const void *failure_addr); >> + >> +/** >> * Bus scan policies >> */ >> enum rte_bus_scan_mode { >> @@ -226,6 +240,8 @@ struct rte_bus { >> rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */ >> rte_bus_hotplug_handler_t hotplug_handler; >> /**< handle hot plug on bus */ >> + rte_bus_sigbus_handler_t sigbus_handler; /**< handle sigbus error */ >> + >> }; >> >> /** > One issue with handling sigbus is that you are going to trap program errors > as well as hotplug. How can you distinguish between removed device and a > buggy userspace program (or worse comprimised program)? That is a problem which i have been considerate in this mechanism and do it in other patch, the way is that first check if the error domain is belong to the mmio device resource or not, if it is will do new sigbus handler for hotplug, if not will mean that it is buggy user space program, will use generic sigbus handler to handler it.