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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 05 Aug 2018 22:31:02 +0000
Subject: [Bug 200739] New: I/O error on read-ahead inode blocks does not get
 detected or reported

            Bug ID: 200739
           Summary: I/O error on read-ahead inode blocks does not get
                    detected or reported
           Product: File System
           Version: 2.5
    Kernel Version: 4.17.0-rc3+
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
        Regression: No

Created attachment 277693
device mapper code



I am checking how ext4 behaves in response to block level I/O injection errors.
I observe that ext4 file system reads multiple other inodes during an inode
block access. these inodes are read-ahead inodes and their count can be
modulated using the inode_readahead_blks parameter. For my experiments, I set
this parameter to 2, so 2 additional inodes were read for each primary inode
block access.

When I inject I/O error on the first inode being accessed, I am able to see an
I/O error message in both the user space - for example:

stat: cannot stat
Input/output error

and the kernel space, for example:

EXT4-fs error (device dm-1): __ext4_get_inode_loc:4626: inode #568: block 156:
comm stat: unable to read itable block

However, if the I/O error takes place on all the subsequent read-ahead inodes,
I observe no such error.

Steps to Reproduce

1. create a secondary ext2 file system with about 1.5GB space, preferably on
2. compile and run dm-io.c using Makefile attached. this is a device mapper
target that prints and optionally injects I/O error for a particular block.
3. run that would generate 2000 nested files and directories.
It then mounts ext4 as a dm-io target that runs a "stat" command on one of the
files. This also prints all blocks that were accessed in dmsg. We look for 3-4
consecutive blocks being read.

For example, on my setup, I get the following blocks:

140 READ
142 READ
141 READ
144 READ
146 READ
145 READ
157 READ
158 READ
156 READ

here, blocks 141,144,156 are primary inodes, and all other adjacent succeeding
blocks are read-ahead inodes.

4. run [errBlkNo] script that would rerun the stat command, but
this time it would inject I/O error when the erroBlkNo block number is returned
back to the file system. I set errBlkNo to any of the inode blocks read. For
each primary inode, I get an error. for all read ahead blocks, I do not get any
error, either in user space or kernel space, which should be reported. Hence, I
believe this is a bug.

Please find all related scripts attached for reference.


You are receiving this mail because:
You are watching the assignee of the bug.

Powered by blists - more mailing lists