Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1593919

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

From Ajay Kaher <ajay.kaher@samsung.com>
Newsgroups linux.kernel
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 2017-03-07 07:10 +0100
Message-ID <tigtP-3ay-1@gated-at.bofh.it> (permalink)
References <tgYIF-3UX-3@gated-at.bofh.it> <tigtP-3ay-3@gated-at.bofh.it> <tgYIF-3UX-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

 
 
 
> 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;

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

FW: RE: 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 <ajay.kaher@samsung.com> - 2017-03-01 13:40 +0100
  Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling  of Race Condition when two USB class drivers try to call init_usb_class  simultaneously Alan Stern <stern@rowland.harvard.edu> - 2017-03-01 16:30 +0100
    FW: RE: Re: FW: RE: 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 <ajay.kaher@samsung.com> - 2017-03-02 09:40 +0100
      FW: FW: RE: Re: FW: RE: 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 <ajay.kaher@samsung.com> - 2017-03-03 16:30 +0100
        Re: FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix:  Proper handling of Race Condition when two USB class drivers try to call  init_usb_class simultaneously Alan Stern <stern@rowland.harvard.edu> - 2017-03-03 18:00 +0100
          Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race  Condition when two USB class drivers try to call init_usb_class simultaneously Ajay Kaher <ajay.kaher@samsung.com> - 2017-03-07 07:10 +0100
            Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race  Condition when two USB class drivers try to call init_usb_class simultaneously Alan Stern <stern@rowland.harvard.edu> - 2017-03-07 20:10 +0100
              Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race  Condition when two USB class drivers try to call init_usb_class  simultaneously "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2017-03-09 13:30 +0100
              Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race  Condition when two USB class drivers try to call init_usb_class simultaneously Ajay Kaher <ajay.kaher@samsung.com> - 2017-03-09 13:30 +0100
            Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race  Condition when two USB class drivers try to call init_usb_class  simultaneously "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2017-03-08 19:10 +0100

csiph-web