public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: Daniel Mack <zonque@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Sarbojit Ganguly <unixman.linuxboy@gmail.com>,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.de>
Subject: Re: Kernel Oops while disconnecting USB peripheral (always)
Date: Sat, 28 Jul 2012 15:25:07 +0200	[thread overview]
Message-ID: <87mx2kvwzw.fsf@nemi.mork.no> (raw)
In-Reply-To: <5013E074.20007@gmail.com> (Daniel Mack's message of "Sat, 28 Jul 2012 14:52:04 +0200")

Daniel Mack <zonque@gmail.com> writes:
> On 28.07.2012 14:27, Bjørn Mork wrote:
>
>> The reason is this change:
>> 
>>  0998d0631 device-core: Ensure drvdata = NULL when no driver is bound
>> 
>> 
>> It will make bugs like this suddenly 100% reproducible.  But the bugs
>> *are* in the drivers, and may have been there for a long time.  The
>> drivers have been accessing drvdata after unbinding.  They just didn't
>> crash prior to that commit.

I just realized that I might have been concluding too quickly here, as
usual.. 

The crashes referred to in this thread were not NULL pointer
dereferences, which makes it less likely that this change is the
cause. Could of course still be related somehow, but not directly.


>> But the commit is correct, and a very much needed improvement if my
>> assumptions are correct.  The drivers need fixing and this just makes it
>> evident.
>
> Hmm, interesting. Thanks for sharing this. I personally never saw this
> bug kicking in, but if I understand your findings correctly, we would
> need something like the following patch for snd-usb and the storage driver?
>
> Sarbojit, could you give this a test and see whether your kernel still
> crashes in any of the two drivers?
>
>
> Thanks,
> Daniel
>
>
>
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index d5b5c33..0e8caaa 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -555,7 +555,7 @@ static void snd_usb_audio_disconnect(struct
> usb_device *dev,
>         struct snd_card *card;
>         struct list_head *p;
>
> -       if (chip == (void *)-1L)
> +       if (chip == (void *)-1L || chip == NULL)
>                 return;

I may be wrong, but I don't think you need this is disconnect.  The
driver will not be unbound until after disconnect returns.

But IMHO, the usage of (void *)-1L as invalid drvdata marker in that
driver should be replaced with NULL.  suspend/resume may also be unsafe
for example.


>         card = chip->card;
> @@ -610,6 +610,7 @@ static void usb_audio_disconnect(struct
> usb_interface *intf)
>  {
>         snd_usb_audio_disconnect(interface_to_usbdev(intf),
>                                  usb_get_intfdata(intf));
> +       usb_set_intfdata(intf, NULL);


This can't harm, but is not necessary given that it now will be taken
care of by the driver core.


>  }
>
>  #ifdef CONFIG_PM
> diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
> index d012fe4..36862ee 100644
> --- a/drivers/usb/storage/usb.c
> +++ b/drivers/usb/storage/usb.c
> @@ -1025,9 +1025,14 @@ void usb_stor_disconnect(struct usb_interface *intf)
>  {
>         struct us_data *us = usb_get_intfdata(intf);
>
> +       if (!us)
> +               return;
> +
>         US_DEBUGP("storage_disconnect() called\n");
>         quiesce_and_remove_host(us);
>         release_everything(us);
> +
> +       usb_set_intfdata(intf, NULL);
>  }
>  EXPORT_SYMBOL_GPL(usb_stor_disconnect);


I don't really think you need those changes for the same reasons I gave
above.

Sorry if my comment just confused the search for this bug.  bisecting it
is probably the easiest way to locate it after all.



Bjørn

  reply	other threads:[~2012-07-28 13:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23  3:42 Kernel Oops while disconnecting USB peripheral (always) Sarbojit Ganguly
2012-07-23  5:50 ` Daniel Mack
2012-07-23  6:03   ` Sarbojit Ganguly
2012-07-23 14:47     ` Alan Stern
2012-07-23 14:54       ` Daniel Mack
2012-07-23 15:05         ` Sarbojit Ganguly
2012-07-28 12:27         ` Bjørn Mork
2012-07-28 12:52           ` Daniel Mack
2012-07-28 13:25             ` Bjørn Mork [this message]
2012-07-28 13:30               ` Daniel Mack
2012-07-28 16:19             ` Alan Stern
2012-08-08  3:22               ` Sarbojit Ganguly
2012-07-23 15:04       ` Sarbojit Ganguly
2012-07-23 15:07         ` Daniel Mack
2012-07-28 11:13         ` Daniel Mack

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=87mx2kvwzw.fsf@nemi.mork.no \
    --to=bjorn@mork.no \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tiwai@suse.de \
    --cc=unixman.linuxboy@gmail.com \
    --cc=zonque@gmail.com \
    /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