linux-ext4 - [Bug 200753] write I/O error for inode structure leads to operation failure without any warning or error

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: <bug-200753-13602-haK5Pxkpqv@https.bugzilla.kernel.org/>
Date:   Tue, 07 Aug 2018 02:44:15 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200753] write I/O error for inode structure leads to operation
 failure without any warning or error

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

--- Comment #8 from Shehbaz (shehbazjaffer007@...il.com) ---
Hello Eric and Theodore,

I apologize for filing bug reports before describing what I am trying to do.
The purpose of my study is to determine how block-level read and write I/O
errors are handled by different file systems. In order to simulate this, I
created a device mapper target that intercepts all blocks that are read and
written by a file system. I use a combination of dumpe2fs, code documentation
and debugfs to determine different data structures on the file system.

For each run of a command, multiple blocks are accessed from the device. I
systematically return an I/O error from the device mapper instead of the actual
block, one block at a time and check how file system either detects or recovers
from this error. Specifically, for inode read operations (eg. access, chdir),
an I/O error during the read of an inode leads to an error message in user
space and an error message in kernel space. Also, the read operation fails. For
error during a write of an inode (which mostly happens when I unmount the
device, which is when all blocks are flushed to disk), I observe that if I
return an EIO error, this is not acknowledged by the file system in any way. I
do not see a log message that the EIO was detected by the file system while
flushing blocks to disk. e2fsck also does not report that a certain inode write
operation did not successfully get flushed to disk. The updated values in the
inode do not get reflected once I remount the file system and I see the older
file system image.

I would like to ask if such failed operations, due to the failure of the
underlying device should be detected and reported at the file system level? I
think since the file system would be responsible for persisting writes to disk,
if the disk returns back an I/O error during a write operation, this should be
reported to either the user or atleast logged as a warning or error message
notifying the user that the operation did not succeed as the disk never
recorded the updated write.

Once again, I apologize for submitting the bug reports without validating them.
I would like to understand your view of this problem and if this form of error
should be handled at the file system layer.

Thank you,

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