Received: by 10.213.65.68 with SMTP id h4csp3191270imn; Mon, 2 Apr 2018 23:57:40 -0700 (PDT) X-Google-Smtp-Source: AIpwx48vquF5GARyPnMPDDbGNYomWcp7DBYyP9esE5h7E1fMdWPLO8jPd/VrxHwovXfeXtPyp2sT X-Received: by 10.98.186.2 with SMTP id k2mr2779887pff.139.1522738660003; Mon, 02 Apr 2018 23:57:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522738659; cv=none; d=google.com; s=arc-20160816; b=bH8KlQhR0QXfg20abifq26IXZ5UPRHbKYX//ohh34jn5o5Byo9boRWT+wRstE+OzEu NXSS60C1FRZeq8mOtppwAumtOFleFMEkX1PV+gc4NoBNu4TSjE8HT4+neLKXhriI02lh STV1HumDTDJDVZFqdLBYM8MQFpM2LZQMDGftNEO1Qt+jyF8POvzPQnr91VUEUBKSxohO xAq5evFpqmcS9O3OyXfE5hYGP3BsDFa3aX7AKRmBj1OpGd0hvmHMs7YuHN6UMpOqwZTr Z4zdUB2iPh3bdO98/H4YmiG6A1FMOPzc/TIYi8i4dKvEBLHmO64Jm6JEzk9fjoGhvEpz zFQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=F4gC03n7iRuRwxt2I1fO8iGhk0TWK5PlLft9tj/cf2c=; b=yjBdoXyR7czS8jHoJ/DluxQgt4sGKwg/6MfzkMhBBFFiGto9R2inWdVgWYDzZHsZXL EiVZVFV86rAAJWVRqR+E1Mo76KttKGWHmi/Yi0eexhvOQdJ1bysxtSMWDme4pOeZ0dvw efi4Psun8+CJurtEYKTZhC+tbqtk7LacYaW2zL05B0Yk712gK/+CBV7KiVotVYxWrQC9 zapOgXNudr/unc4+F3JLpkjcAiKqLzvyGw0bgiWplt87NlCJXrmbpRbFsxbrK+1tf+QW JuiV+8DsVZNYUrrmDCqf5KHsGWccmphsNVnxIKYDk3qP8IyTELJLEFi6o2OwOS2X/g1S 8sSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 32-v6si2231367pla.348.2018.04.02.23.57.25; Mon, 02 Apr 2018 23:57:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752788AbeDCG4W (ORCPT + 99 others); Tue, 3 Apr 2018 02:56:22 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46994 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413AbeDCG4V (ORCPT ); Tue, 3 Apr 2018 02:56:21 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 47991F02; Tue, 3 Apr 2018 06:56:20 +0000 (UTC) Date: Tue, 3 Apr 2018 08:56:18 +0200 From: Greg KH To: Shuah Khan Cc: valentina.manea.m@gmail.com, shuah@kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached Message-ID: <20180403065618.GA1093@kroah.com> References: <20180402205232.21659-1-shuahkh@osg.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180402205232.21659-1-shuahkh@osg.samsung.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 02, 2018 at 02:52:31PM -0600, Shuah Khan wrote: > vhci_hcd module can be removed even when devices are attached. Fix to > prevent module removal when devices are still attached. > > Signed-off-by: Shuah Khan > --- > drivers/usb/usbip/vhci_sysfs.c | 25 +++++++++++++++++++++---- > 1 file changed, 21 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c > index 48808388ec33..6a54b9aa92be 100644 > --- a/drivers/usb/usbip/vhci_sysfs.c > +++ b/drivers/usb/usbip/vhci_sysfs.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > #include "usbip_common.h" > #include "vhci.h" > @@ -252,6 +253,8 @@ static ssize_t detach_store(struct device *dev, struct device_attribute *attr, > if (ret < 0) > return -EINVAL; > > + module_put(THIS_MODULE); > + > usbip_dbg_vhci_sysfs("Leave\n"); > > return count; > @@ -302,7 +305,7 @@ static ssize_t attach_store(struct device *dev, struct device_attribute *attr, > struct vhci_hcd *vhci_hcd; > struct vhci_device *vdev; > struct vhci *vhci; > - int err; > + int err, ret; > unsigned long flags; > > /* > @@ -339,10 +342,18 @@ static ssize_t attach_store(struct device *dev, struct device_attribute *attr, > else > vdev = &vhci->vhci_hcd_hs->vdev[rhport]; > > + /* get module ref to avoid being removed with active attached devs */ > + if (!try_module_get(THIS_MODULE)) { > + ret = -EAGAIN; > + goto module_get_err; > + } That's really not a good idea, trying to grab your own module reference is considered racy and we stopped adding that code pattern to the kernel a long time ago. What's wrong if you remove the vhci module if devices are attached? You can do that today for any other USB host driver, this shouldn't be "special". Also, kernel modules are never automatically removed by the system, so someone has to do this by hand, so they knew what they were doing :) thanks, greg k-h