Revert "[PATCH] Btrfs: make xattr replace operations atomic"

This reverts commit 55f2b0ed5a3e056e3a063276d10c762e9a568a0a.
[PATCH v2] Btrfs: make xattr replace operations atomic

Replacing a xattr consists of doing a lookup for its existing value, delete
the current value from the respective leaf, release the search path and then
finally insert the new value. This leaves a time window where readers (getxattr,
listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs,
so this has security implications.

This change also fixes 2 other existing issues which were:

*) Deleting the old xattr value without verifying first if the new xattr will
   fit in the existing leaf item (in case multiple xattrs are packed in the
   same item due to name hash collision);

*) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't
   exist but we have have an existing item that packs muliple xattrs with
   the same name hash as the input xattr. In this case we should return ENOSPC.

A test case for xfstests follows soon.

Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace
implementation.

Reported-by: Alexandre Oliva <oliva@gnu.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---

V2: Added missing btrfs_mark_buffer_dirty() call for the case where a replace
    happens for an item with no other xattrs and the new xattr value size is
    the same as the old xattr value size;
    Made btrfs_search_slot not release the path if it returns EOVERFLOW (from
    split_leaf), so that we can get the current size of the item when doing
    the replace and extend the leaf to a size smaller then what we passed to
    btrfs_search_slot if the xattr exists in the item (and the new extend size
    is new_size - old_size, excluding xattr's name and sizeof struct btrfs_dir_item).

 fs/btrfs/ctree.c    |   2 +-
 fs/btrfs/ctree.h    |   4 ++
 fs/btrfs/dir-item.c |  10 ++--
 fs/btrfs/xattr.c    | 145 ++++++++++++++++++++++++++++++----------------------
 4 files changed, 92 insertions(+), 69 deletions(-)