public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <lkml@rtr.ca>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	marcel@holtmann.org, Greg KH <gregkh@suse.de>,
	Andrew Morton <akpm@osdl.org>,
	linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] [BUG] usb/core/hub.c loops forever on resume from ram due to bluetooth
Date: Thu, 03 May 2007 09:44:35 -0400	[thread overview]
Message-ID: <4639E743.2080504@rtr.ca> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0705030932290.3548-100000@iolanthe.rowland.org>

Alan Stern wrote:
> On Wed, 2 May 2007, Mark Lord wrote:
> 
>> Alan Stern wrote:
>>> A better approach would be to find out why your system gets into that loop 
>>> and fix the underlying cause.
>> Not better, just parallel.
>>
>> That loop should not be unbounded, as this example proves.
>> But it also shouldn't get stuck there regardless.
>>
>> Two fixes needed.
> 
> If the code never gets stuck in a loop, then there's no need to check 
> whether the loop is unbounded!  :-)

Yes, except here we know it does actually get stuck in a loop,
and having unbounded loops in device-driver code is a known baddy.

One cannot predict perfectly exactly how devices will fail,
but one can program defensively against them with simple precautions
like limiting list traversals and the like.  :)

Sure, Marcel may eventually look at the bluetooth code and fix it
to not get confused, but some other USB device may then show up
in the future with similar issues.  The messages are still there
so we'll know about any future failure, but it won't just silently
crash the machine on resume this way.

Remember, resume is a very tough operation to debug at the best
of times, so adding some harmless robustness to the more troublesome
drives is a very Good Thing(tm) here.

Cheers

  reply	other threads:[~2007-05-03 13:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-01 23:28 [BUG] usb/core/hub.c loops forever on resume from ram due to bluetooth Mark Lord
2007-05-02 19:59 ` [linux-usb-devel] " Alan Stern
2007-05-02 21:39   ` Mark Lord
2007-05-03 13:33     ` Alan Stern
2007-05-03 13:44       ` Mark Lord [this message]
2007-05-03 14:46         ` Alan Stern
2007-05-08 13:53 ` Mark Lord
2007-05-13  9:27   ` Greg KH
2007-05-14 23:48     ` Mark Lord
2007-05-22 23:53       ` patch usb-hub.c-loops-forever-on-resume-from-ram-due-to-bluetooth.patch added to gregkh-2.6 tree 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=4639E743.2080504@rtr.ca \
    --to=lkml@rtr.ca \
    --cc=akpm@osdl.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=marcel@holtmann.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