linux-ext4 - Re: More inline data oddities

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: <20170503131550.GA14305@gmail.com>
Date:   Wed, 3 May 2017 21:15:51 +0800
From:   Zheng Liu <gnehzuil.liu@...il.com>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     George Spelvin <linux@...encehorizons.net>,
        Zheng Liu <wenqing.lz@...bao.com>, linux-ext4@...r.kernel.org,
        tytso@....edu
Subject: Re: More inline data oddities

Hello Andreas,

Thanks for letting me know this.

Hello George,

I have tried to create a ext4 file system with inline_data feature,
and try to create a directory hierarchy like you described in the
mail.  But unfortunately I couldn't reproduce your issue.  That would
be great if you could provide more details to me, such as the output
of the following command.

  $ debugfs ${DEV} -R 'stats'

>From this command I can know which features are enabled in your ext4
file system and that would help me to reproduce the problem.  Further,
could you please tell me your kernel version?

On Mon, May 01, 2017 at 04:00:02PM -0600, Andreas Dilger wrote:
> Add the original inline data author Zheng Liu <wenqing.lz@...bao.com>.
> 
> On May 1, 2017, at 11:40 AM, George Spelvin <linux@...encehorizons.net> wrote:
> > [255031.626936] EXT4-fs warning (device md3): ext4_dirent_csum_verify:352: inode #1461410: comm find: No space for directory leaf checksum. Please run e2fsck -D.
> > [255031.626940] EXT4-fs error (device md3): ext4_readdir:198: inode #1461410: comm find: path $PATH1: directory fails checksum at offset 0
> > [255035.720542] EXT4-fs warning (device md3): ext4_dirent_csum_verify:352: inode #1461314: comm find: No space for directory leaf checksum. Please run e2fsck -D.
> > [255035.720547] EXT4-fs error (device md3): ext4_readdir:198: inode #1461314: comm find: path $PATH2: directory fails checksum at offset 0

It seems that the space is full in inline data and the kernel could not
expand it to a new block.  From the following message I guess during
this process kernel tries to allocate a new block for this directory
and then an error is encountered that causes flags 0x10000000 could not
have a chance to be cleared.  So this inode has flag 0x10000000 and
blockcount is 8.

> > 
> > 
> > The inline data consists of two parts: 60 bytes in the block pointers which
> > hold the first four entries, and 72 bytes in an ea, which holds the fifth and
> > last entry.
> > 
> > debugfs on the directories reveals the following:
> > Inode: 1461410   Type: directory    Mode:  0755   Flags: 0x10000000
                                                      ^^^^^^^^^^^^^^^^^
                          It means that this directory contains inline data

> > Generation: 927521379    Version: 0x00000000:00000007
> > User:  1000   Group:    11   Project:     0   Size: 132
> > File ACL: 1496481792    Directory ACL: 0
> > Links: 3   Blockcount: 8
               ^^^^^^^^^^^^^
It seems that this directory is currupted because a directory with
inline data should be 0.  That is why e2fsck wants to fix this issue
in first round.

I will take a closer look at this problem later, and thanks for
reporting this.

Regards,
                                                - Zheng

> > Fragment:  Address: 0    Number: 0    Size: 0
> > ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > mtime: 0x55016b84:e7729ec8 -- Thu Mar 12 06:33:40 2015
> > crtime: 0x56c1c093:0d01b4b4 -- Mon Feb 15 07:12:03 2016
> > Size of extra inode fields: 32
> > Extended attributes:
> >  system.data (72)
> > Inode checksum: 0x456bd90c
> > Size of inline data: 132
> > 
> > Inode: 1461314   Type: directory    Mode:  0755   Flags: 0x10000000
> > Generation: 927521364    Version: 0x00000000:00000004
> > User:  1000   Group:    11   Project:     0   Size: 132
> > File ACL: 1496383488    Directory ACL: 0
> > Links: 3   Blockcount: 8
> > Fragment:  Address: 0    Number: 0    Size: 0
> > ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > mtime: 0x55016b84:1670325c -- Thu Mar 12 06:33:40 2015
> > crtime: 0x56c1c093:01161e74 -- Mon Feb 15 07:12:03 2016
> > Size of extra inode fields: 32
> > Extended attributes:
> >  system.data (72)
> > Inode checksum: 0x008d7abf
> > Size of inline data: 132
> > 
> > 
> > If I run e2fsck on that stat, it complains about two things:
> > 
> > Inode 1461314, i_blocks is 8, should be 0.  Fix<y>? yes
> > Inode 1461410, i_blocks is 8, should be 0.  Fix<y>? yes
> > i_file_acl for inode 1461314 ($PATH2) is 1496383488, should be zero.
> > Clear<y>? yes
> > i_file_acl for inode 1461410 ($PATH1) is 1496481792, should be zero.
> > Clear<y>? yes
> > 
> > I don't really understand how those two errors were created in the
> > first place.
> > 
> > However, after saying yes to those, the system.data ea is missing and the
> > final entries in each directory get dropped, leading to being dumped
> > in loat+found.
> > 
> > Here's the state after the first e2fsck run completes:
> > 
> > Inode: 1461410   Type: directory    Mode:  0755   Flags: 0x10000000
> > Generation: 927521379    Version: 0x00000000:00000007
> > User:  1000   Group:    11   Project:     0   Size: 132
> > File ACL: 0    Directory ACL: 0
> > Links: 3   Blockcount: 0
> > Fragment:  Address: 0    Number: 0    Size: 0
> > ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > mtime: 0x55016b84:e7729ec8 -- Thu Mar 12 06:33:40 2015
> > crtime: 0x56c1c093:0d01b4b4 -- Mon Feb 15 07:12:03 2016
> > Size of extra inode fields: 32
> > Inode checksum: 0xcd34b98c
> > Size of inline data: 60
> > 
> > Inode: 1461314   Type: directory    Mode:  0755   Flags: 0x10000000
> > Generation: 927521364    Version: 0x00000000:00000004
> > User:  1000   Group:    11   Project:     0   Size: 132
> > File ACL: 0    Directory ACL: 0
> > Links: 3   Blockcount: 0
> > Fragment:  Address: 0    Number: 0    Size: 0
> > ctime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > atime: 0x5902fa22:07728174 -- Fri Apr 28 04:15:30 2017
> > mtime: 0x55016b84:1670325c -- Thu Mar 12 06:33:40 2015
> > crtime: 0x56c1c093:01161e74 -- Mon Feb 15 07:12:03 2016
> > Size of extra inode fields: 32
> > Inode checksum: 0x042ed119
> > Size of inline data: 60
> > 
> > 
> > This then leads to a second run complaining about
> > 
> > Inode 1461314 has INLINE_DATA_FL flag but extended attribute not found.  Truncate<y>?
> > 
> > If I instead fix it by "ea_set -f /dev/null <1461314> system.data", I get the
> > directory back in a relatively unbroken state.  But why is system.data
> > being deleted in the first place?
> 
> 
> Cheers, Andreas
> 
> 
> 
> 
>