[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2915109D-9F6F-4D25-A759-3D99716BEF4C@dilger.ca>
Date: Thu, 28 Jun 2018 16:20:48 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: "Theodore Y. Ts'o" <tytso@....edu>
Cc: Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsck: do not allow initialized blocks pass i_size
On Jun 28, 2018, at 4:12 PM, Theodore Y. Ts'o <tytso@....edu> wrote:
>
> 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.
That's true for stock ext4, but as I mentioned in my other email, Lustre
will allocate up to the PAGE_SIZE boundary because the RDMA will overwrite
the whole page regardless of where i_size is, which results in blocks
being allocated beyond i_size for PAGE_SIZE > blocksize.
While that is not a typical configuration (we always format with 4KB
blocksize, and typically run x86 servers), there are a few sites that
have SPARC servers, so this patch is to accommodate them.
Cheers, Andreas
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
Powered by blists - more mailing lists