[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180628221219.GC8521@thunk.org>
Date: Thu, 28 Jun 2018 18:12:19 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsck: do not allow initialized blocks pass i_size
On Thu, Jun 28, 2018 at 01:55:49PM -0600, Andreas Dilger wrote:
> On Jun 28, 2018, at 7:59 AM, Lukas Czerner <lczerner@...hat.com> wrote:
> >
> > We do not allow initialized blocks to exist past i_size as this could
> > lead to stale data exposure.
>
> I don't think this is any more dangerous than uninitialized bytes beyond
> i_size in the same block, or as a hole in the middle of the file exposing
> stale data. That is to say, there is some risk, but not any worse. The
> converse is true also - extendiy,ng i_size to the end of the allocated blocks
> will not only expose that data, but in some cases make applications think
> the file is corrupted because there are now NULs at the end of the file.
I believe what Lukas is referring to is the fact that historically,
ext2, ext3, and ext4 in the nodelalloc case used i_size as the
interlock to make sure we don't end up exposing stale data. With the
advent of punch hole functionality, life gets interesting so we have
one set of mechanisms for interlocking between buffered and direct I/O
for truncate, and different one for punch hole.
So the kernel should never create intialized blocks past i_size. I've
done some quick checks, and this appears to be correct.
- Ted
Powered by blists - more mailing lists