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.0908222002110.9952-100000@netrider.rowland.org>
Date:	Sat, 22 Aug 2009 20:17:32 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Rogério Brito <rbrito@....usp.br>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	<linux-usb@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	<bugzilla-daemon@...zilla.kernel.org>
Subject: Re: [Bugme-new] [Bug 14020] New: Stack trace when running smartctl
 on an USB disk

On Sat, 22 Aug 2009, [utf-8] Rogério Brito wrote:

> Hi, Alan.
> 
> On Aug 21 2009, Alan Stern wrote:
> > A usbmon trace showing what happens when you plug in the drive and
> > when you run smartctl would help.
> 
> The requested trace is attached to this message. Please let me know if
> you need more information.

The trace shows that something (presumably smartctl) sends a command
the drive doesn't understand.  The drive then violates the USB
mass-storage protocol, sending an invalid response.  The kernel waits
for a proper response but nothing more happens, so after 30 seconds the
command times out and is aborted and the drive is reset.  The command
then gets retried, and the same thing happens again.  The retries take
so long that the kernel complains about smartctl being blocked for more
than 120 seconds -- that's the reason for the stack dump.

So the problem has several causes.  One is that the drive is buggy (it
doesn't respond with an error code in the proper way when it receives a
command it doesn't understand).  Another is that smartctl is trying to
send commands in a form the drive can't handle.  Finally, there's the
problem about all the retries taking too long.

Perhaps you can blame the kernel for spending too much time on retries, 
but the other two are the fault of the drive and smartctl.

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