summaryrefslogtreecommitdiffstats
path: root/fs/exec.c
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fb.com>2016-08-24 11:57:52 -0400
committerDavid Sterba <dsterba@suse.com>2016-09-01 17:16:47 +0200
commit3dc09ec895f098cedd789a620c90ff1bf7f779a1 (patch)
treeaf37d47db0078fb39b35982f79e2fa80a2b8b891 /fs/exec.c
parent28a235931b56d4e7bdd51f6733daf95f2b269da8 (diff)
downloadop-kernel-dev-3dc09ec895f098cedd789a620c90ff1bf7f779a1.zip
op-kernel-dev-3dc09ec895f098cedd789a620c90ff1bf7f779a1.tar.gz
Btrfs: kill invalid ASSERT() in process_all_refs()
Suppose you have the following tree in snap1 on a file system mounted with -o inode_cache so that inode numbers are recycled └── [ 258] a └── [ 257] b and then you remove b, rename a to c, and then re-create b in c so you have the following tree └── [ 258] c └── [ 257] b and then you try to do an incremental send you will hit ASSERT(pending_move == 0); in process_all_refs(). This is because we assume that any recycling of inodes will not have a pending change in our path, which isn't the case. This is the case for the DELETE side, since we want to remove the old file using the old path, but on the create side we could have a pending move and need to do the normal pending rename dance. So remove this ASSERT() and put a comment about why we ignore pending_move. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/exec.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud