linux-ext4 - [Bug 200739] New: I/O error on read-ahead inode blocks does not get detected or reported

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-next>] [day] [month] [year] [list]

Message-ID: <bug-200739-13602@https.bugzilla.kernel.org/>
Date:   Sun, 05 Aug 2018 22:31:02 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200739] New: I/O error on read-ahead inode blocks does not get
 detected or reported

https://bugzilla.kernel.org/show_bug.cgi?id=200739

            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
          Assignee: fs_ext4@...nel-bugs.osdl.org
          Reporter: shehbazjaffer007@...il.com
        Regression: No

Created attachment 277693
  --> https://bugzilla.kernel.org/attachment.cgi?id=277693&action=edit
device mapper code

Hello!

Background
==========

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.

Issue
=====
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
'/mnt/DZAORDJFHRPGQGRPG7VBLAWNXR61S/BFIE2JB9Q353PQBK/OT8YSP69Q9NI93P8J6UK1WK0DFWSNQ599FHC5DIA0BWW7YIDC6W/U/FULLFILE':
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
QEMU.
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 printAllBlocks.sh 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 injectError.sh [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.

Thanks!

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