linux-kernel - Re: 2.6.29 regression: ATA bus errors on resume

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]

Date:	Wed, 27 May 2009 16:01:42 +0200
From:	Niel Lambrechts <niel.lambrechts@...il.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"linux.kernel" <linux-kernel@...r.kernel.org>,
	Theodore Tso <tytso@....edu>
Subject: Re: 2.6.29 regression: ATA bus errors on resume

On 05/27/2009 02:07 AM, Tejun Heo wrote:
> The above is the offending failure and all three failfast bits are
> set.  This corresponds to the following ATA exception.
>
>   ata1.00: cmd 60/08:18:6f:88:6f/01:00:0e:00:00/40 tag 3 ncq 135168 in
> 	  res 50/00:40:d1:71:b8/00:00:09:00:00/40 Emask 0x10 (ATA bus error)
>
> It's 33 page long read command.  Looking at the code the only way all
> three fastfail bits can be set seems to be if the request is readahead
> - the first part of block/blk-core.c::init_request_from_bio().  Now,
> the failure of a readahead request isn't supposed to cause any
> problem.  If it fails, well, it fails and things should go on as if
> nothing happened.
>
> Can you please try the attached patch?  It takes suspend/resume cycle
> out of the equation and simply induces artificial failure to readahead
> requests.  It's currently set to fail every 40th readahead.  Feel free
> to adjust the frequency as you see fit.  catting files into /dev/null
> would trigger readahead to kick in.  Can you reproduce filesystem
> failure with this alone?
>    

No corruption, I tried cat on an entire directory of mp3s, then also 
started X, but there the messages debug output got fairly drastic so I 
didn't care to continue for an entire day.

It did trigger the "XXX ...failing readahead" message nearly 300 times, 
and I also did a s2disk and resume cycle in there - so I hope this is 
enough for us to conclude that it is not the cause.

Regards,
Niel





View attachment "messages.2.6.30-rc7-pae.readahead-1.txt" of type "text/plain" (61444 bytes)