linux-ext4 - Re: Weird filesystem corruption from wayland / radeon / chromium

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:	Fri, 02 Nov 2012 15:50:15 +0000
From:	Tim Landscheidt <tim@...-landscheidt.de>
To:	linux-ext4@...r.kernel.org
Subject: Re: Weird filesystem corruption from wayland / radeon / chromium

(anonymous) wrote:

> FYI, after fsck'ing, I checked my filesystem against my backup, and didn't
> find anything that changed that shouldn't have changed.  Command I used
> was:

> rsync -imva --compare-dest=/ /media/4tb/bak/dancer-2012-09-04/ /media/4tb/bak/changes/

I ran (or rather run) into this issue as well.  Starting on
October 22nd, I saw on my Fedora 16 (3.6.2-1.fc16.i686) sys-
tem:

| Oct 22 13:56:44 passepartout kernel: [ 1395.772939] EXT4-fs error (device dm-4): ext4_ext_search_left:1238: inode #274258: comm flush-253:4: ix (3666) != EXT_FIRST_INDEX (0) (depth 0)!
| Oct 22 13:56:44 passepartout kernel: [ 1395.772951] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 3666 with max blocks 3 with error -5
| Oct 22 13:56:44 passepartout kernel: [ 1395.772955] EXT4-fs (dm-4): This should not happen!! Data will be lost
| Oct 22 13:56:44 passepartout kernel: [ 1395.772957]

and it continued intermittently.  Last message before "yes-
terday"'s shutdown was:

| Nov  2 04:14:09 passepartout kernel: [51109.016422] EXT4-fs error (device dm-4): ext4_ext_search_left:1304: inode #274258: comm flush-253:4: ix (3666) != EXT
| _FIRST_INDEX (0) (depth 0)!
| Nov  2 04:14:09 passepartout kernel: [51109.016428] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 3792 with max blocks 2
|  with error -5
| Nov  2 04:14:09 passepartout kernel: [51109.016431] EXT4-fs (dm-4): This should not happen!! Data will be lost
| Nov  2 04:14:09 passepartout kernel: [51109.016431]

Looking at today's boot.log, I see no error detected by
"File System Check", and the manual run of "e2fsck -f"
showed also no errors.

Shortly after starting Chrome, the messages reappeared
again:

| Nov  2 15:15:48 passepartout kernel: [ 1979.196296] EXT4-fs error (device dm-4): ext4_ext_search_left:1304: inode #274258: comm flush-253:4: ix (3666) != EXT_FIRST_INDEX (0) (depth 0)!
| Nov  2 15:15:48 passepartout kernel: [ 1979.196306] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 3672 with max blocks 2 with error -5
| Nov  2 15:15:48 passepartout kernel: [ 1979.196308] EXT4-fs (dm-4): This should not happen!! Data will be lost
| Nov  2 15:15:48 passepartout kernel: [ 1979.196308]

And indeed:

| [root@...separtout ~]# find ~tim -inum 274258
| /home/tim/.cache/google-chrome/Default/Cache/data_3
| [root@...separtout ~]#

So somehow Chromium/Chrome seems to be able to trigger ker-
nel messages indicating a file system error while no actual
file system errors seem to occur (very big assumption here
because I have no idea how to detect if "data_3" is cor-
rupted).

In my yum.log, I don't see any obvious package update prior
to October 22nd.  kernel was updated on October 23rd, Chrome
on October 12th (22.0.1229.94-161065.i386).

Any ideas?

TIA,
Tim

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