Btrfs: send, don't BUG_ON() when an empty symlink is found
authorFilipe Manana <fdmanana@suse.com>
Thu, 31 Dec 2015 18:07:59 +0000 (18:07 +0000)
committerFilipe Manana <fdmanana@suse.com>
Thu, 31 Dec 2015 18:08:20 +0000 (18:08 +0000)
commita879719b8c90e15c9e7fa7266d5e3c0ca962f9df
treeda6ef5e494c911f1985612a52554511fc68229b4
parent2bc0bb5fe71dee6fdaf81ff81f6e739ff9f7ff19
Btrfs: send, don't BUG_ON() when an empty symlink is found

When a symlink is successfully created it always has an inline extent
containing the source path. However if an error happens when creating
the symlink, we can leave in the subvolume's tree a symlink inode without
any such inline extent item - this happens if after btrfs_symlink() calls
btrfs_end_transaction() and before it calls the inode eviction handler
(through the final iput() call), the transaction gets committed and a
crash happens before the eviction handler gets called, or if a snapshot
of the subvolume is made before the eviction handler gets called. Sadly
we can't just avoid this by making btrfs_symlink() call
btrfs_end_transaction() after it calls the eviction handler, because the
later can commit the current transaction before it removes any items from
the subvolume tree (if it encounters ENOSPC errors while reserving space
for removing all the items).

So make send fail more gracefully, with an -EIO error, and print a
message to dmesg/syslog informing that there's an empty symlink inode,
so that the user can delete the empty symlink or do something else
about it.

Reported-by: Stephen R. van den Berg <srb@cuci.nl>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
fs/btrfs/send.c