lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0705031042340.3548-100000@iolanthe.rowland.org>
Date:	Thu, 3 May 2007 10:46:15 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Mark Lord <lkml@....ca>
cc:	Linux Kernel <linux-kernel@...r.kernel.org>, <marcel@...tmann.org>,
	Greg KH <gregkh@...e.de>, Andrew Morton <akpm@...l.org>,
	<linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] [BUG] usb/core/hub.c loops forever on resume
 from ram due to bluetooth

On Thu, 3 May 2007, Mark Lord wrote:

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

I'd agree, except that the problem isn't in the bluetooth code.  And it
probably doesn't have anything in particular to do with the fact that this
is a bluetooth device; the TT code gets used with USB hubs only.  More
accurately, the code helps manage the TT embedded in a high-speed USB hub,
allowing the hub to communicate with a full- or low-speed USB device
plugged into it.

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

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ