linux.git/fs/btrfs, branch v3.13

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs

2013-12-12T23:25:10+00:00

Pull btrfs fixes from Chris Mason:
 "This is a small collection of fixes.  It was rebased this morning, but
  I was just fixing signed-off-by tags with the wrong email"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: fix access_ok() check in btrfs_ioctl_send()
  Btrfs: make sure we cleanup all reloc roots if error happens
  Btrfs: skip building backref tree for uuid and quota tree when doing balance relocation
  Btrfs: fix an oops when doing balance relocation
  Btrfs: don't miss skinny extent items on delayed ref head contention
  btrfs: call mnt_drop_write after interrupted subvol deletion
  Btrfs: don't clear the default compression type

Btrfs: fix access_ok() check in btrfs_ioctl_send()

2013-12-12T15:13:02+00:00

The closing parenthesis is in the wrong place.  We want to check
"sizeof(*arg->clone_sources) * arg->clone_sources_count" instead of
"sizeof(*arg->clone_sources * arg->clone_sources_count)".

Signed-off-by: Dan Carpenter 
Reviewed-by: Jie Liu 
Signed-off-by: Chris Mason 
cc: stable@vger.kernel.org

Btrfs: make sure we cleanup all reloc roots if error happens

2013-12-12T15:12:51+00:00

I hit an oops when merging reloc roots fails, the reason is that
new reloc roots may be added and we should make sure we cleanup
all reloc roots.

Signed-off-by: Wang Shilong 
Signed-off-by: Chris Mason

Btrfs: skip building backref tree for uuid and quota tree when doing balance relocation

2013-12-12T15:12:36+00:00

Quota tree and UUID Tree is only cowed, they can not be snapshoted.

Signed-off-by: Wang Shilong 
Signed-off-by: Chris Mason

Btrfs: fix an oops when doing balance relocation

2013-12-12T15:12:20+00:00

I hit an oops when inserting reloc root into @reloc_root_tree(it can be
easily triggered when forcing cow for relocation root)

[  866.494539]  [] btrfs_init_reloc_root+0x79/0xb0 [btrfs]
[  866.495321]  [] record_root_in_trans+0xb0/0x110 [btrfs]
[  866.496109]  [] btrfs_record_root_in_trans+0x48/0x80 [btrfs]
[  866.496908]  [] select_reloc_root+0xa8/0x210 [btrfs]
[  866.497703]  [] do_relocation+0x16a/0x540 [btrfs]

This is because reloc root inserted into @reloc_root_tree is not within one
transaction,reloc root may be cowed and root block bytenr will be reused then
oops happens.We should update reloc root in @reloc_root_tree when cow reloc
root node, fix it.

Signed-off-by: Wang Shilong 
Reviewed-by: Miao Xie 
Signed-off-by: Chris Mason

Btrfs: don't miss skinny extent items on delayed ref head contention

2013-12-12T15:11:58+00:00

Currently extent-tree.c:btrfs_lookup_extent_info() can miss the lookup
of skinny extent items. This can happen when the execution flow is the
following:

* We do an extent tree lookup and fail to find a skinny extent item;

* As a result, we attempt to see if a non-skinny extent item exists,
  either by looking at previous item in the leaf or by doing another
  full extent tree search;

* We have a transaction and then we check for a matching delayed ref
  head in the transaction's delayed refs rbtree;

* We find such delayed ref head and then we try to lock it with a
  call to mutex_trylock();

* The lock was contended so we jump to the label "again", which repeats
  the extent tree search but for a non-skinny extent item, because we set
  previously metadata variable to 0 and the search key to look for a
  non-skinny extent-item;

* After the jump (and after releasing the transaction's delayed refs
  lock), a skinny extent item might have been added to the extent tree
  but we will miss it because metadata is set to 0 and the search key
  is set for a non-skinny extent-item.

The fix here is to not reset metadata to 0 and to jump to the initial search
key setup if the delayed ref head is contended, instead of jumping directly
to the extent tree search label ("again").

This issue was found while investigating the issue reported at Bugzilla 64961.

David Sterba suspected this function was missing extent items, and that
this could be caused by the last change to this function, which was made
in the following patch:

    [PATCH] Btrfs: optimize btrfs_lookup_extent_info()
    (commit 74be9510876a66ad9826613ac8a526d26f9e7f01)

But in fact this issue already existed before, because after failing to find
a skinny extent item, the code set the search key for a non-skinny extent
item, and on contention of a matching delayed ref head it would not search
the extent tree for a skinny extent item anymore.

Signed-off-by: Filipe David Borba Manana 
Reviewed-by: Liu Bo 
Signed-off-by: Chris Mason

btrfs: call mnt_drop_write after interrupted subvol deletion

2013-12-12T15:11:38+00:00

If btrfs_ioctl_snap_destroy blocks on the mutex and the process is
killed, mnt_write count is unbalanced and leads to unmountable
filesystem.

CC: stable@vger.kernel.org
Signed-off-by: David Sterba 
Signed-off-by: Chris Mason

Btrfs: don't clear the default compression type

2013-12-12T15:11:19+00:00

We met a oops caused by the wrong compression type:
[  556.512356] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  556.512370] IP: [] __list_del_entry+0x1/0x98
[SNIP]
[  556.512490]  [] ? list_del+0xd/0x2b
[  556.512539]  [] find_workspace+0x97/0x175 [btrfs]
[  556.512546]  [] ? _raw_spin_lock+0xe/0x10
[  556.512576]  [] btrfs_compress_pages+0x2d/0xa2 [btrfs]
[  556.512601]  [] compress_file_range.constprop.54+0x1f2/0x4e8 [btrfs]
[  556.512627]  [] async_cow_start+0x32/0x4d [btrfs]
[  556.512655]  [] worker_loop+0x144/0x4c3 [btrfs]
[  556.512661]  [] ? finish_task_switch+0x80/0xb8
[  556.512689]  [] ? btrfs_queue_worker+0x244/0x244 [btrfs]
[  556.512695]  [] kthread+0x8d/0x95
[  556.512699]  [] ? bit_waitqueue+0x34/0x7d
[  556.512704]  [] ? __kthread_parkme+0x65/0x65
[  556.512709]  [] ret_from_fork+0x7c/0xb0
[  556.512713]  [] ? __kthread_parkme+0x65/0x65

Steps to reproduce:
 # mkfs.btrfs -f 
 # mount -o nodatacow  
 # touch /
 # chattr =c /
 # dd if=/dev/zero of=/ bs=1M count=10

It is because we cleared the default compression type when setting the
nodatacow. In fact, we needn't do it because we have used COMPRESS flag to
indicate if we need compressed the file data or not, needn't use the
variant -- compress_type -- in btrfs_info to do the same thing, and just
use it to hold the default compression type. Or we would get a wrong compress
type for a file whose own compress flag is set but the compress flag of its
filesystem is not set.

Reported-by: Tsutomu Itoh 
Signed-off-by: Miao Xie 
Reviewed-by: Liu Bo 
Signed-off-by: Chris Mason

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

2013-12-05T23:33:27+00:00

Pull block layer fixes from Jens Axboe:
 "A small collection of fixes for the current series. It contains:

   - A fix for a use-after-free of a request in blk-mq.  From Ming Lei

   - A fix for a blk-mq bug that could attempt to dereference a NULL rq
     if allocation failed

   - Two xen-blkfront small fixes

   - Cleanup of submit_bio_wait() type uses in the kernel, unifying
     that.  From Kent

   - A fix for 32-bit blkg_rwstat reading.  I apologize for this one
     looking mangled in the shortlog, it's entirely my fault for missing
     an empty line between the description and body of the text"

* 'for-linus' of git://git.kernel.dk/linux-block:
  blk-mq: fix use-after-free of request
  blk-mq: fix dereference of rq->mq_ctx if allocation fails
  block: xen-blkfront: Fix possible NULL ptr dereference
  xen-blkfront: Silence pfn maybe-uninitialized warning
  block: submit_bio_wait() conversions
  Update of blkg_stat and blkg_rwstat may happen in bh context

block: submit_bio_wait() conversions

2013-11-24T23:33:41+00:00

It was being open coded in a few places.

Signed-off-by: Kent Overstreet 
Cc: Jens Axboe 
Cc: Joern Engel 
Cc: Prasad Joshi 
Cc: Neil Brown 
Cc: Chris Mason 
Acked-by: NeilBrown 
Signed-off-by: Jens Axboe