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

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

2015-02-07T19:04:48+00:00

Pull btrfs fix from Chris Mason:
 "Forrest Liu tracked down a missing blk_finish_plug in the btrfs
  logging code.  This isn't a new bug, and it's hard to hit.  But, it's
  safe enough for inclusion now, and in my for-linus branch"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: add missing blk_finish_plug in btrfs_sync_log()

Btrfs: add missing blk_finish_plug in btrfs_sync_log()

2015-02-05T02:02:37+00:00

Add missing blk_finish_plug in btrfs_sync_log()

Signed-off-by: Forrest Liu 
Reviewed-by: David Sterba 
Signed-off-by: Chris Mason

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

2015-01-30T22:25:52+00:00

Pull btrfs fix from Chris Mason:
 "We have one more fix for btrfs in my for-linus branch - this was a bug
  in the new raid5/6 scrubbing support"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  btrfs: fix raid56 scrub failed in xfstests btrfs/072

btrfs: fix raid56 scrub failed in xfstests btrfs/072

2015-01-27T23:26:16+00:00

The xfstests btrfs/072 reports uncorrectable read errors in dmesg,
because scrub forgets to use commit_root for parity scrub routine
and scrub attempts to scrub those extents items whose contents are
not fully on disk.

To fix it, we just add the @search_commit_root flag back.

Signed-off-by: Gui Hecheng 
Signed-off-by: Qu Wenruo 
Reviewed-by: Miao Xie 
Signed-off-by: Chris Mason

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

2015-01-24T02:31:27+00:00

Pull btrfs fixes from Chris Mason:
 "We have a few fixes in my for-linus branch.

  Qu Wenruo's batch fix a regression between some our merge window pull
  and the inode_cache feature.  The rest are smaller bugs"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  btrfs: Don't call btrfs_start_transaction() on frozen fs to avoid deadlock.
  btrfs: Fix the bug that fs_info->pending_changes is never cleared.
  btrfs: fix state->private cast on 32 bit machines
  Btrfs: fix race deleting block group from space_info->ro_bgs list
  Btrfs: fix incorrect freeing in scrub_stripe
  btrfs: sync ioctl, handle errors after transaction start

btrfs: Don't call btrfs_start_transaction() on frozen fs to avoid deadlock.

2015-01-21T01:20:21+00:00

Commit 6b5fe46dfa52 (btrfs: do commit in sync_fs if there are pending
changes) will call btrfs_start_transaction() in sync_fs(), to handle
some operations needed to be done in next transaction.

However this can cause deadlock if the filesystem is frozen, with the
following sys_r+w output:
[  143.255932] Call Trace:
[  143.255936]  [] schedule+0x29/0x70
[  143.255939]  [] __sb_start_write+0xb3/0x100
[  143.255971]  [] start_transaction+0x2e6/0x5a0
[btrfs]
[  143.255992]  [] btrfs_start_transaction+0x1b/0x20
[btrfs]
[  143.256003]  [] btrfs_sync_fs+0xca/0xd0 [btrfs]
[  143.256007]  [] sync_fs_one_sb+0x20/0x30
[  143.256011]  [] iterate_supers+0xe1/0xf0
[  143.256014]  [] sys_sync+0x55/0x90
[  143.256017]  [] system_call_fastpath+0x12/0x17
[  143.256111] Call Trace:
[  143.256114]  [] schedule+0x29/0x70
[  143.256119]  [] rwsem_down_write_failed+0x1c5/0x2d0
[  143.256123]  [] call_rwsem_down_write_failed+0x13/0x20
[  143.256131]  [] thaw_super+0x28/0xc0
[  143.256135]  [] do_vfs_ioctl+0x3f5/0x540
[  143.256187]  [] SyS_ioctl+0x91/0xb0
[  143.256213]  [] system_call_fastpath+0x12/0x17

The reason is like the following:
(Holding s_umount)
VFS sync_fs staff:
|- btrfs_sync_fs()
   |- btrfs_start_transaction()
      |- sb_start_intwrite()
      (Waiting thaw_fs to unfreeze)
					VFS thaw_fs staff:
					thaw_fs()
					(Waiting sync_fs to release
					 s_umount)

So deadlock happens.
This can be easily triggered by fstest/generic/068 with inode_cache
mount option.

The fix is to check if the fs is frozen, if the fs is frozen, just
return and waiting for the next transaction.

Cc: David Sterba 
Reported-by: Gui Hecheng 
Signed-off-by: Qu Wenruo 
[enhanced comment, changed to SB_FREEZE_WRITE]
Signed-off-by: David Sterba 
Signed-off-by: Chris Mason

btrfs: Fix the bug that fs_info->pending_changes is never cleared.

2015-01-21T01:19:40+00:00

Fs_info->pending_changes is never cleared since the original code uses
cmpxchg(&fs_info->pending_changes, 0, 0), which will only clear it if
pending_changes is already 0.

This will cause a lot of problem when mount it with inode_cache mount
option.
If the btrfs is mounted as inode_cache, pending_changes will always be
1, even when the fs is frozen.

Signed-off-by: Qu Wenruo 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Chris Mason

btrfs: fix state->private cast on 32 bit machines

2015-01-19T21:06:06+00:00

Suppress the following warning displayed on building 32bit (i686) kernel.

===============================================================================
...
   CC [M]  fs/btrfs/extent_io.o
fs/btrfs/extent_io.c: In function ‘btrfs_free_io_failure_record’:
fs/btrfs/extent_io.c:2193:13: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
    failrec = (struct io_failure_record *)state->private;
...
===============================================================================

Signed-off-by: Satoru Takeuchi 
Reported-by: Chris Murphy 
Signed-off-by: Chris Mason

Btrfs: fix race deleting block group from space_info->ro_bgs list

2015-01-19T21:05:45+00:00

When removing a block group we were deleting it from its space_info's
ro_bgs list without the correct protection - the space info's spinlock.
Fix this by doing the list delete while holding the spinlock of the
corresponding space info, which is the correct lock for any operation
on that list.

This issue was introduced in the 3.19 kernel by the following change:

    Btrfs: move read only block groups onto their own list V2
    commit 633c0aad4c0243a506a3e8590551085ad78af82d

I ran into a kernel crash while a task was running statfs, which iterates
the space_info->ro_bgs list while holding the space info's spinlock,
and another task was deleting it from the same list, without holding that
spinlock, as part of the block group remove operation (while running the
function btrfs_remove_block_group). This happened often when running the
stress test xfstests/generic/038 I recently made.

Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason

Btrfs: fix incorrect freeing in scrub_stripe

2015-01-19T21:05:44+00:00

The address that should be freed is not 'ppath' but 'path'.

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