Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To:     Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
Cc:     viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
        linux-kernel@vger.kernel.org
Subject: Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1
References: <CAE5jQCe4nX8m1f5jPL57GeU32CftNv+NvgNmZxufH85nun1o7w@mail.gmail.com>
        <878t6c7f8p.fsf@mail.parknet.co.jp>
        <20180715143043.GM30522@ZenIV.linux.org.uk>
        <CAE5jQCcs2x4myTHUhNmHPZvhMuPsrkzLmiqqeF5wzZ-Hf5druQ@mail.gmail.com>
Date:   Mon, 16 Jul 2018 00:26:03 +0900
In-Reply-To: <CAE5jQCcs2x4myTHUhNmHPZvhMuPsrkzLmiqqeF5wzZ-Hf5druQ@mail.gmail.com>
        (Anatoly Trosinenko's message of "Sun, 15 Jul 2018 18:08:23 +0300")
Message-ID: <87h8l0y0z8.fsf@mail.parknet.co.jp>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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>