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: <50A29161.4060506@redhat.com>
Date:	Tue, 13 Nov 2012 12:28:49 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	linux-ext4@...r.kernel.org
Subject: Re: Weird filesystem corruption from wayland / radeon / chromium

On 11/2/12 1:55 PM, Tim Landscheidt wrote:
> Eric Sandeen <sandeen@...hat.com> wrote:
> 
>> [...]
>>> 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).
> 
>> So it's the same inode every time.
> 
>> What does
> 
>> # debugfs -R "dump_extents <274258>" /dev/dm-4
> 
>> show? (or whatever the appropriate device node path is)
> 
> See attachment.

Level Entries       Logical          Physical Length Flags
 0/ 1   1/  2     0 -  3665 1114157             3666
 1/ 1   1/ 59     0 -   132  510721 -  510853    133 
 1/ 1   2/ 59   133 -   139  511415 -  511421      7 
...
 1/ 1  58/ 59  3039 -  3664  573440 -  574065    626 
 1/ 1  59/ 59  3665 -  4092  574066 -  574493    428 
 0/ 1   2/  2  3666 -  9217  395702             5552
 1/ 1   1/307  4093 -  4093  574494 -  574494      1 
 1/ 1   2/307  4094 -  4095  395758 -  395759      2 
...

Ok, so the first top-level record says it covers logical 0->3665,
but the last extent actually goes from 3665->4092.

Then the next top level extent says it covers 3666->9217,
but that overlaps w/ the last real extent just prior, and
the first allocated extent under it actually starts at 4093.

so,
a) how'd it get into this state, and
b) why doesn't fsck care ...

Looking into that . . .

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ