Messages in this thread | | | From | OGAWA Hirofumi <> | Subject | Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1 | Date | Mon, 16 Jul 2018 00:26:03 +0900 |
| |
Anatoly Trosinenko <anatoly.trosinenko@gmail.com> writes:
>> This patch returns better error (-EIO) for me. > > This works for me likewise.
Thanks for testing.
>> (But note, the corrupted FS image doesn't guarantee POSIX behavior.) > > Oops, I was just doing some testing and thought that correct behavior > for crafted FS is to return arbitrary valid error code (like -EIO) or > some arbitrary data, say, not larger than FS (not disclosing the > kernel memory, of course). Please excuse me if I was wrong. If fixing > this would slow down some hot code path, then I am not insisting on > returning valid errno. :) > > Meanwhile, how should be considered such discrepancies with man pages > for invalid FS images: should it be considered low priority bug, > not-a-bug or feature request (diagnostics)?
To handle the corrupted image _perfectly_, finally we will have to have online fsck or similar.
For example, if the data block was shared between the regular file and directory, user can mmap the directory data via (corrupted) regular file.
Then locking of directory handler doesn't work, and handler has to have directory data as volatile data (and validate data for each memory load). And to verify this invalid shared data blocks, we will have to read all inodes (i.e. almost fsck).
So, I may change the code if data verification is easy and lightweight like in this case. But like said above, it will not be guaranteed.
Thanks. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
| |