From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 2/2] btrfs-progs: fix lowmem check's handling of holes
Date: Thu, 30 Jan 2020 15:47:36 -0500 [thread overview]
Message-ID: <20200130204736.49224-3-josef@toxicpanda.com> (raw)
In-Reply-To: <20200130204736.49224-1-josef@toxicpanda.com>
Lowmem check had the opposite problem of normal check, it caught gaps
that started at 0, but would still fail with my fixes in place. This is
because lowmem check doesn't take into account the isize of the inode.
Address this by making sure we do not complain about gaps that are after
isize. This makes lowmem pass with my fixes applied, and still fail
without my fixes.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
check/mode-lowmem.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
index 2f76d634..fd503aa6 100644
--- a/check/mode-lowmem.c
+++ b/check/mode-lowmem.c
@@ -2029,7 +2029,8 @@ static int check_file_extent_inline(struct btrfs_root *root,
* Return 0 if no error occurred.
*/
static int check_file_extent(struct btrfs_root *root, struct btrfs_path *path,
- unsigned int nodatasum, u64 *size, u64 *end)
+ unsigned int nodatasum, u64 isize, u64 *size,
+ u64 *end)
{
struct btrfs_file_extent_item *fi;
struct btrfs_key fkey;
@@ -2152,7 +2153,7 @@ static int check_file_extent(struct btrfs_root *root, struct btrfs_path *path,
}
/* Check EXTENT_DATA hole */
- if (!no_holes && *end != fkey.offset) {
+ if (!no_holes && (fkey.offset < isize) && (*end != fkey.offset)) {
if (repair)
ret = punch_extent_hole(root, path, fkey.objectid,
*end, fkey.offset - *end);
@@ -2165,7 +2166,8 @@ static int check_file_extent(struct btrfs_root *root, struct btrfs_path *path,
}
}
- *end = fkey.offset + extent_num_bytes;
+ if (fkey.offset + extent_num_bytes < isize)
+ *end = fkey.offset + extent_num_bytes;
if (!is_hole)
*size += extent_num_bytes;
@@ -2726,7 +2728,7 @@ static int check_inode_item(struct btrfs_root *root, struct btrfs_path *path)
root->objectid, inode_id, key.objectid,
key.offset);
}
- ret = check_file_extent(root, path, nodatasum,
+ ret = check_file_extent(root, path, nodatasum, isize,
&extent_size, &extent_end);
err |= ret;
break;
--
2.24.1
next prev parent reply other threads:[~2020-01-30 20:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 20:47 [PATCH 0/2] Fix btrfs check handling of missing file extents Josef Bacik
2020-01-30 20:47 ` [PATCH 1/2] btrfs-progs: fix check to catch gaps at the start of the file Josef Bacik
2020-03-05 15:38 ` David Sterba
2020-01-30 20:47 ` Josef Bacik [this message]
2020-03-04 13:53 ` [PATCH 0/2] Fix btrfs check handling of missing file extents David Sterba
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=20200130204736.49224-3-josef@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox