Thanks for explanation! Best regards, Anatoly
вс, 15 июл. 2018 г. в 18:26, OGAWA Hirofumi <hirof...@mail.parknet.co.jp>: > > Anatoly Trosinenko <anatoly.trosine...@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 <hirof...@mail.parknet.co.jp>