All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Eric Whitney <enwlinux@gmail.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] e2fsprogs: Don't report uninit extents past EOF invalid
Date: Mon, 12 Aug 2013 18:21:25 -0500	[thread overview]
Message-ID: <52096DF5.9090700@redhat.com> (raw)
In-Reply-To: <20130721202849.GB2331@wallace>

On 7/21/13 3:28 PM, Eric Whitney wrote:
> Commit d3f32c2db8 caused e2fsck misbehavior during xfstests runs.
> It reported that uninitialized extents created by fallocate() at
> the end of file with the FALLOC_FL_KEEP_SIZE flag were invalid.
> Because FALLOC_FL_KEEP_SIZE does not increase the file size when
> an extent is fallocated, an uninitialized extent can legally contain
> blocks past the end of file.
> 
> The information reported by ext2fs_extent_get() and used by the commit
> to determine legal extent ranges is limited by the value of i_size
> (determines end_blk in the root extent index), so block values greater
> than that containing i_size were reported as invalid.
> 
> To fix this, filter out possible invalid extent candidates if they are
> uninitialized and extend past the block containing the end of file.
> 
> Signed-off-by: Eric Whitney <enwlinux@gmail.com>
> ---
>  e2fsck/pass1.c      |    4 +++-
>  lib/ext2fs/ext2fs.h |    1 +
>  lib/ext2fs/extent.c |    1 +
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
> index ba6025b..b84b0d0 100644
> --- a/e2fsck/pass1.c
> +++ b/e2fsck/pass1.c
> @@ -1892,7 +1892,9 @@ static void scan_extent_node(e2fsck_t ctx, struct problem_context *pctx,
>  			problem = PR_1_EXTENT_BAD_START_BLK;
>  		else if (extent.e_lblk < start_block)
>  			problem = PR_1_OUT_OF_ORDER_EXTENTS;
> -		else if (end_block && last_lblk > end_block)
> +		else if ((end_block && last_lblk > end_block) &&
> +			 (!(extent.e_flags & EXT2_EXTENT_FLAGS_UNINIT &&
> +			    last_lblk > info.eof_blk - 1)))
>  			problem = PR_1_EXTENT_END_OUT_OF_BOUNDS;
>  		else if (is_leaf && extent.e_len == 0)
>  			problem = PR_1_EXTENT_LENGTH_ZERO;
> diff --git a/lib/ext2fs/ext2fs.h b/lib/ext2fs/ext2fs.h
> index 311ceda..85f2ac8 100644
> --- a/lib/ext2fs/ext2fs.h
> +++ b/lib/ext2fs/ext2fs.h
> @@ -409,6 +409,7 @@ struct ext2_extent_info {
>  	int		bytes_avail;
>  	blk64_t		max_lblk;
>  	blk64_t		max_pblk;
> +	blk64_t         eof_blk;
>  	__u32		max_len;
>  	__u32		max_uninit_len;
>  };

I just realized, this affects the ABI, doesn't it?  Hm.

As a hack-around, can probably just use ehandle->path[0].end_blk directly
in scan_extent_node and stash eof_blk locally?

-Eric

> diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
> index 65bb099..de54319 100644
> --- a/lib/ext2fs/extent.c
> +++ b/lib/ext2fs/extent.c
> @@ -1572,6 +1572,7 @@ errcode_t ext2fs_extent_get_info(ext2_extent_handle_t handle,
>  	info->max_depth = handle->max_depth;
>  	info->max_lblk = ((__u64) 1 << 32) - 1;
>  	info->max_pblk = ((__u64) 1 << 48) - 1;
> +	info->eof_blk = handle->path[0].end_blk;
>  	info->max_len = (1UL << 15);
>  	info->max_uninit_len = (1UL << 15) - 1;
>  
> 


  parent reply	other threads:[~2013-08-12 23:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-21 20:28 [PATCH] e2fsprogs: Don't report uninit extents past EOF invalid Eric Whitney
2013-07-23 21:35 ` Eric Sandeen
2013-08-12 23:21 ` Eric Sandeen [this message]
2013-08-12 23:28   ` Eric Sandeen
2013-08-12 23:35     ` Eric Sandeen
2013-08-13 16:31       ` Eric Whitney
2013-08-14  2:49         ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52096DF5.9090700@redhat.com \
    --to=sandeen@redhat.com \
    --cc=enwlinux@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.