linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ajay Kaher <ajay.kaher@samsung.com>
To: Alan Stern <stern@rowland.harvard.edu>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	AMAN DEEP <aman.deep@samsung.com>,
	HEMANSHU SRIVASTAVA <hemanshu.s@samsung.com>
Subject: Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
Date: Tue, 07 Mar 2017 04:35:37 +0000	[thread overview]
Message-ID: <20170307043537epcms5p7e4fcfc351c4f193e454c9ea2e271e562@epcms5p7> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1703031146540.1837-100000@iolanthe.rowland.org>

[-- Attachment #1: Type: text/plain, Size: 2850 bytes --]

 
 
 
> On Fri, 3 Mar 2017, Ajay Kaher wrote:
> 
> > > usb_class->kref is not accessible outside the file.c
> > > as usb_class is _static_ inside the file.c and
> > > pointer of usb_class->kref is not passed anywhere.
> > > 
> > > Hence as you wanted, there are no references of usb_class->kref
> > > other than taken by init_usb_class() and released by destroy_usb_class().
> > 
> > Verified the code again, I hope my last comments clarifed the things
> > which came in your mind and helps you to accept the patch :)
>  
> Your main point is that usb_class->kref is accessed from only two
> points, both of which are protected by the new mutex.  This means there
> is no reason for the value to be a struct kref at all.  You should
> change it to an int (and change its name).  Leaving it as a kref will
> make readers wonder why it needs to be updated atomically.

At many places in Linux kernel, instances of Kref have been used within
Mutex, SpinLock and don’t have any side effect.

Making to int and handle (i.e. get/put) it within file.c seems
not good as we have Kref. Instead, we can have non_atomic version of kref.
We can discuss about non_atomic kref in another thread, if you are interested.

> Also, why does destroy_usb_class() have that "if (usb_class) "test? 
> Isn't it true that usb_class can never be NULL there?

Removed in Patch v4.

thanks,
ajay kaher
 
  
Signed-off-by: Ajay Kaher
 
---

 drivers/usb/core/file.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..422ce7b 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);

 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)

 static void destroy_usb_class(void)
 {
-       if (usb_class)
-               kref_put(&usb_class->kref, release_usb_class);
+       mutex_lock(&init_usb_class_mutex);
+       kref_put(&usb_class->kref, release_usb_class);
+       mutex_unlock(&init_usb_class_mutex);
 }

 int usb_major_init(void)
@@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
        if (intf->minor >= 0)
                return -EADDRINUSE;

+       mutex_lock(&init_usb_class_mutex);
        retval = init_usb_class();
+       mutex_unlock(&init_usb_class_mutex);
+
        if (retval)
                return retval;

  parent reply	other threads:[~2017-03-07  6:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170220192040epcas3p37ded8ece49ed9385df80d3b813a953bc@epcas3p3.samsung.com>
2017-02-22 12:57 ` Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously Ajay Kaher
     [not found]   ` <CGME20170220192040epcas3p37ded8ece49ed9385df80d3b813a953bc@epcms5p3>
2017-03-01 11:12     ` FW: " Ajay Kaher
2017-03-01 15:15       ` Alan Stern
     [not found]         ` <CGME20170301151552epcas5p3ecf8f7dc55323b2ceaff8c8a9b9644c4@epcms5p1>
2017-03-02  7:49           ` FW: RE: " Ajay Kaher
     [not found]         ` <CGME20170301151552epcas5p3ecf8f7dc55323b2ceaff8c8a9b9644c4@epcms5p2>
2017-03-03 14:49           ` FW: " Ajay Kaher
2017-03-03 16:53             ` Alan Stern
     [not found]               ` <CGME20170303165352epcas5p2c408a284100b5053daf458a4ad4d9337@epcms5p7>
2017-03-07  4:35                 ` Ajay Kaher [this message]
2017-03-07 15:00                   ` Subject: [PATCH v4] " Alan Stern
     [not found]                     ` <CGME20170307150103epcas2p348320fdfbb176978d084d8f2b7b9a049@epcms5p7>
2017-03-09 11:34                       ` Ajay Kaher
2017-03-09 12:10                         ` gregkh
     [not found]                         ` <CGME20170307150103epcas2p348320fdfbb176978d084d8f2b7b9a049@epcms5p2>
2017-03-17 10:56                           ` [PATCH v4] USB: " Ajay Kaher
2017-03-23  7:18                             ` gregkh
2017-03-21 14:49                           ` FW: " Ajay Kaher
2017-03-08 18:05                   ` Subject: [PATCH v4] USB:Core: BugFix: " gregkh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170307043537epcms5p7e4fcfc351c4f193e454c9ea2e271e562@epcms5p7 \
    --to=ajay.kaher@samsung.com \
    --cc=aman.deep@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hemanshu.s@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).