linux-kernel - Re: Weird I/O errors with USB hard drive not remounting filesystem readonly

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: <20091123185449.GA11186@quack.suse.cz>
Date:	Mon, 23 Nov 2009 19:54:50 +0100
From:	Jan Kara <jack@...e.cz>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Jan Kara <jack@...e.cz>, tmhikaru@...il.com,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>, linux-scsi@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: Weird I/O errors with USB hard drive not remounting filesystem
 readonly

On Mon 23-11-09 13:20:26, Alan Stern wrote:
> On Mon, 23 Nov 2009, Jan Kara wrote:
> 
> > On Mon 23-11-09 10:06:03, Alan Stern wrote:
> > > On Mon, 23 Nov 2009, Jan Kara wrote:
> > > 
> > > >   Yeah, from what you write, it looks like USB enclosure is at fault (or it
> > > > could still be your USB controller but I doubt it).  It's still a bit
> > > > bothering that the error reported by the drive was not properly propagated
> > > > up to VFS. Either it's some block layer retry/ignore magic that I missed or
> > > > we ignore errors from block layer in some place.
> > > 
> > > Is there any interest in tracking this down?  It's not hard to find out
> > > what low-level errors are being reported and to generate them on demand
> > > with an emulated USB disk drive.
> >   Well, if you could provide me with the patch, I could try to track down
> > why the errors aren't propagated... It would be interesting because if it's
> > not some retry logic in block layer, it's a bug in VFS ;).
> 
> I can't provide a patch without first knowing what the errors are.  The 
> way to find out is to use usbmon.  See Documentation/usb/usbmon.txt for 
> instructions.
  Ah, OK. The problem manifests itself as an error in SATA communication
(which in fact somehow happens over USB, but I don't really know the
details of mass storage over USB) so debugging USB would become actual only
if we found out it's really some bug in an usb stack. But so far the most
probable is just an error somewhere between the USB controller in the
enclosure and the drive itself. BTW: Is the data transferred over USB
checksummed?

									Honza
--
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/