mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ajay Kaher <ajay.kaher@samsung.com>
To: "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: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
Date: Wed, 01 Feb 2017 07:24:44 +0000	[thread overview]
Message-ID: <20170201072444epcms5p34768dd535eb6a99e3367befb375e663e@epcms5p3> (raw)
In-Reply-To: <20170131052146epcms5p79112e0ba47847b8b0d33aee7b66590c9@epcms5p7>

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

 
>> At boot time, probe function of multiple connected devices
>> (proprietary devices) execute simultaneously.
>
>What exactly do you mean here?  How can probe happen "simultaneously"?
>The USB core prevents this, right?

I have observed two scenarios to call probe function:

Scenario #1: Driver inserted and attaching USB Device:
Yes, you are right, two probes at same time is not happening
in this scenario.

Scenario #2: USB Device attached and inserting Driver:
In this case probe has been called in context of insmod,
refer following code flow:
init -> usb_register_driver -> driver_register -> bus_add_driver ->
driver_attach -> bus_for_each_dev -> __driver_attach ->
driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev

I have observed the crash in Scenario #2, as two probes executes at
same time in this scenario. And init_usb_class_mutex lock require to
prevent race condition.

>> And because of the following code path race condition happens:
>> probe->usb_register_dev->init_usb_class
>
>Why is this just showing up now, and hasn't been an issue for the decade
>or so this code has been around?  What changed?
>
>> Tested with these changes, and problem has been solved.
>
>What changes?

Tested with my patch (i.e. locking with init_usb_class_mutex).

thanks,

ajay kaher


 
--------- Original Message ---------
Sender : gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>
Date   : 2017-01-31 12:31 (GMT+5:30)
Title  : Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
 
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
 
A: No.
Q: Should I include quotations after my reply?
 
 
http://daringfireball.net/2007/07/on_top
 
On Tue, Jan 31, 2017 at 05:21:46AM +0000, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.
 
What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?
 
And what do you mean exactly by "(proprietary devices)"?
 
> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class
 
Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?
 
> Tested with these changes, and problem has been solved.
 
What changes?
 
thanks,
 
greg k-h
 
 
Thanks and Regards,
Ajay Kaher

  parent reply	other threads:[~2017-02-01  8:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170130082525epcms5p5e2459e715ebb80cef1574946e3f6ffbf@epcms5p5>
     [not found] ` <20170130082525epcms5p5e2459e715ebb80cef1574946e3f6ffbf@epcms5p5>
2017-01-30  9:06   ` gregkh
2017-01-31  5:21   ` Ajay Kaher
2017-01-31  7:00     ` gregkh
2017-02-01  7:24     ` Ajay Kaher [this message]
2017-02-01  9:00       ` gregkh
2017-02-02 12:36       ` Ajay Kaher
2017-02-14 15:39         ` Alan Stern

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=20170201072444epcms5p34768dd535eb6a99e3367befb375e663e@epcms5p3 \
    --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 \
    /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

all inboxes | Powered by JetHome®