From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 6B4681B061 for ; Tue, 10 Jul 2018 10:28:39 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 01:28:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,333,1526367600"; d="scan'208";a="53897425" Received: from jguo15x-mobl3.ccr.corp.intel.com (HELO [10.67.68.57]) ([10.67.68.57]) by fmsmga008.fm.intel.com with ESMTP; 10 Jul 2018 01:28:33 -0700 To: Stephen Hemminger References: <1498711073-42917-1-git-send-email-jia.guo@intel.com> <1531137666-10351-1-git-send-email-jia.guo@intel.com> <1531137666-10351-8-git-send-email-jia.guo@intel.com> <20180709154408.6cbb4c31@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, arybchenko@solarflare.com, wenzhuo.lu@intel.com, jblunck@infradead.org, shreyansh.jain@nxp.com, dev@dpdk.org, helin.zhang@intel.com From: Jeff Guo Message-ID: <4b88d79d-edcb-9c36-f364-b34808f6ef76@intel.com> Date: Tue, 10 Jul 2018 16:28:33 +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: <20180709154408.6cbb4c31@xeon-e3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v7 7/7] igb_uio: fix uio release issue when hot unplug 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, 10 Jul 2018 08:28:41 -0000 hi, stephen Thanks for your review. On 7/10/2018 6:44 AM, Stephen Hemminger wrote: > On Mon, 9 Jul 2018 20:01:06 +0800 > Jeff Guo wrote: > >> @@ -195,12 +205,22 @@ igbuio_pci_irqhandler(int irq, void *dev_id) >> { >> struct rte_uio_pci_dev *udev = (struct rte_uio_pci_dev *)dev_id; >> struct uio_info *info = &udev->info; >> + struct pci_dev *pdev = udev->pdev; >> >> /* Legacy mode need to mask in hardware */ >> if (udev->mode == RTE_INTR_MODE_LEGACY && >> !pci_check_and_mask_intx(udev->pdev)) >> return IRQ_NONE; >> >> + mutex_lock(&udev->lock); >> + /* check the uevent of the kobj */ >> + if ((&pdev->dev.kobj)->state_remove_uevent_sent == 1) { >> + dev_notice(&pdev->dev, "device:%s, sent remove uevent!\n", >> + (&pdev->dev.kobj)->name); >> + udev->state = RTE_UDEV_UNPLUG; >> + } >> + mutex_unlock(&udev->lock); > Did you run with lockdep? > I don't think you can safely acquire a mutex (would sleep) in IRQ context. I think lockdep could do me a favor about that, but i think only the uio remove function will check the unplug status, so i think i could let this check in the uio remove function, no need to let it in irq handler anymore, since like what you said acquire a mutex in IRQ context is no safe.