linux.git/fs/btrfs/ordered-data.c, branch v4.0

Btrfs: fix fsync race leading to ordered extent memory leaks

2015-03-02T22:04:44+00:00

We can have multiple fsync operations against the same file during the
same transaction and they can collect the same ordered extents while they
don't complete (still accessible from the inode's ordered tree). If this
happens, those ordered extents will never get their reference counts
decremented to 0, leading to memory leaks and inode leaks (an iput for an
ordered extent's inode is scheduled only when the ordered extent's refcount
drops to 0). The following sequence diagram explains this race:

         CPU 1                                         CPU 2

btrfs_sync_file()

                                                 btrfs_sync_file()

  mutex_lock(inode->i_mutex)
  btrfs_log_inode()
    btrfs_get_logged_extents()
      --> collects ordered extent X
      --> increments ordered
          extent X's refcount
    btrfs_submit_logged_extents()
  mutex_unlock(inode->i_mutex)

                                                   mutex_lock(inode->i_mutex)
  btrfs_sync_log()
     btrfs_wait_logged_extents()
       --> list_del_init(&ordered->log_list)
                                                     btrfs_log_inode()
                                                       btrfs_get_logged_extents()
                                                         --> Adds ordered extent X
                                                             to logged_list because
                                                             at this point:
                                                             list_empty(&ordered->log_list)
                                                             && test_bit(BTRFS_ORDERED_LOGGED,
                                                                         &ordered->flags) == 0
                                                         --> Increments ordered extent
                                                             X's refcount
       --> check if ordered extent's io is
           finished or not, start it if
           necessary and wait for it to finish
       --> sets bit BTRFS_ORDERED_LOGGED
           on ordered extent X's flags
           and adds it to trans->ordered
  btrfs_sync_log() finishes

                                                       btrfs_submit_logged_extents()
                                                     btrfs_log_inode() finishes
                                                   mutex_unlock(inode->i_mutex)

btrfs_sync_file() finishes

                                                   btrfs_sync_log()
                                                      btrfs_wait_logged_extents()
                                                        --> Sees ordered extent X has the
                                                            bit BTRFS_ORDERED_LOGGED set in
                                                            its flags
                                                        --> X's refcount is untouched
                                                   btrfs_sync_log() finishes

                                                 btrfs_sync_file() finishes

btrfs_commit_transaction()
  --> called by transaction kthread for e.g.
  btrfs_wait_pending_ordered()
    --> waits for ordered extent X to
        complete
    --> decrements ordered extent X's
        refcount by 1 only, corresponding
        to the increment done by the fsync
        task ran by CPU 1

In the scenario of the above diagram, after the transaction commit,
the ordered extent will remain with a refcount of 1 forever, leaking
the ordered extent structure and preventing the i_count of its inode
from ever decreasing to 0, since the delayed iput is scheduled only
when the ordered extent's refcount drops to 0, preventing the inode
from ever being evicted by the VFS.

Fix this by using the flag BTRFS_ORDERED_LOGGED differently. Use it to
mean that an ordered extent is already being processed by an fsync call,
which will attach it to the current transaction, preventing it from being
collected by subsequent fsync operations against the same inode.

This race was introduced with the following change (added in 3.19 and
backported to stable 3.18 and 3.17):

  Btrfs: make sure logged extents complete in the current transaction V3
  commit 50d9aa99bd35c77200e0e3dd7a72274f8304701f

I ran into this issue while running xfstests/generic/113 in a loop, which
failed about 1 out of 10 runs with the following warning in dmesg:

[ 2612.440038] WARNING: CPU: 4 PID: 22057 at fs/btrfs/disk-io.c:3558 free_fs_root+0x36/0x133 [btrfs]()
[ 2612.442810] Modules linked in: btrfs crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop processor parport_pc parport psmouse therma
l_sys i2c_piix4 serio_raw pcspkr evdev microcode button i2c_core ext4 crc16 jbd2 mbcache sd_mod sg sr_mod cdrom virtio_scsi ata_generic virtio_pci ata_piix virtio_ring libata virtio flo
ppy e1000 scsi_mod [last unloaded: btrfs]
[ 2612.452711] CPU: 4 PID: 22057 Comm: umount Tainted: G        W      3.19.0-rc5-btrfs-next-4+ #1
[ 2612.454921] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[ 2612.457709]  0000000000000009 ffff8801342c3c78 ffffffff8142425e ffff88023ec8f2d8
[ 2612.459829]  0000000000000000 ffff8801342c3cb8 ffffffff81045308 ffff880046460000
[ 2612.461564]  ffffffffa036da56 ffff88003d07b000 ffff880046460000 ffff880046460068
[ 2612.463163] Call Trace:
[ 2612.463719]  [] dump_stack+0x4c/0x65
[ 2612.464789]  [] warn_slowpath_common+0xa1/0xbb
[ 2612.466026]  [] ? free_fs_root+0x36/0x133 [btrfs]
[ 2612.467247]  [] warn_slowpath_null+0x1a/0x1c
[ 2612.468416]  [] free_fs_root+0x36/0x133 [btrfs]
[ 2612.469625]  [] btrfs_drop_and_free_fs_root+0x93/0x9b [btrfs]
[ 2612.471251]  [] btrfs_free_fs_roots+0xa4/0xd6 [btrfs]
[ 2612.472536]  [] ? wait_for_completion+0x24/0x26
[ 2612.473742]  [] close_ctree+0x1f3/0x33c [btrfs]
[ 2612.475477]  [] ? destroy_workqueue+0x148/0x1ba
[ 2612.476695]  [] btrfs_put_super+0x19/0x1b [btrfs]
[ 2612.477911]  [] generic_shutdown_super+0x73/0xef
[ 2612.479106]  [] kill_anon_super+0x13/0x1e
[ 2612.480226]  [] btrfs_kill_super+0x17/0x23 [btrfs]
[ 2612.481471]  [] deactivate_locked_super+0x3b/0x50
[ 2612.482686]  [] deactivate_super+0x3f/0x43
[ 2612.483791]  [] cleanup_mnt+0x59/0x78
[ 2612.484842]  [] __cleanup_mnt+0x12/0x14
[ 2612.485900]  [] task_work_run+0x8f/0xbc
[ 2612.486960]  [] do_notify_resume+0x5a/0x6b
[ 2612.488083]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 2612.489333]  [] int_signal+0x12/0x17
[ 2612.490353] ---[ end trace 54a960a6bdcb8d93 ]---
[ 2612.557253] VFS: Busy inodes after unmount of sdb. Self-destruct in 5 seconds.  Have a nice day...

Kmemleak confirmed the ordered extent leak (and btrfs inode specific
structures such as delayed nodes):

$ cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff880154290db0 (size 576):
  comm "btrfsck", pid 21980, jiffies 4295542503 (age 1273.412s)
  hex dump (first 32 bytes):
    01 40 00 00 01 00 00 00 b0 1d f1 4e 01 88 ff ff  .@.........N....
    00 00 00 00 00 00 00 00 c8 0d 29 54 01 88 ff ff  ..........)T....
  backtrace:
    [] kmemleak_update_trace+0x4c/0x6a
    [] radix_tree_node_alloc+0x6d/0x83
    [] __radix_tree_create+0x109/0x190
    [] radix_tree_insert+0x30/0xac
    [] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs]
    [] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs]
    [] __btrfs_unlink_inode+0xee/0x288 [btrfs]
    [] btrfs_unlink_inode+0x1e/0x40 [btrfs]
    [] btrfs_unlink+0x60/0x9b [btrfs]
    [] vfs_unlink+0x9c/0xed
    [] do_unlinkat+0x12c/0x1fa
    [] SyS_unlinkat+0x29/0x2b
    [] system_call_fastpath+0x12/0x17
    [] 0xffffffffffffffff
unreferenced object 0xffff88014ef11db0 (size 576):
  comm "rm", pid 22009, jiffies 4295542593 (age 1273.052s)
  hex dump (first 32 bytes):
    02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 c8 1d f1 4e 01 88 ff ff  ...........N....
  backtrace:
    [] kmemleak_update_trace+0x4c/0x6a
    [] radix_tree_node_alloc+0x6d/0x83
    [] __radix_tree_create+0x109/0x190
    [] radix_tree_insert+0x30/0xac
    [] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs]
    [] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs]
    [] __btrfs_unlink_inode+0xee/0x288 [btrfs]
    [] btrfs_unlink_inode+0x1e/0x40 [btrfs]
    [] btrfs_unlink+0x60/0x9b [btrfs]
    [] vfs_unlink+0x9c/0xed
    [] do_unlinkat+0x12c/0x1fa
    [] SyS_unlinkat+0x29/0x2b
    [] system_call_fastpath+0x12/0x17
    [] 0xffffffffffffffff
unreferenced object 0xffff8800336feda8 (size 584):
  comm "aio-stress", pid 22031, jiffies 4295543006 (age 1271.400s)
  hex dump (first 32 bytes):
    00 40 3e 00 00 00 00 00 00 00 8f 42 00 00 00 00  .@>........B....
    00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
  backtrace:
    [] create_object+0x172/0x29a
    [] kmemleak_alloc+0x25/0x41
    [] kmemleak_alloc_recursive.constprop.52+0x16/0x18
    [] kmem_cache_alloc+0xf7/0x198
    [] __btrfs_add_ordered_extent+0x43/0x309 [btrfs]
    [] btrfs_add_ordered_extent_dio+0x12/0x14 [btrfs]
    [] btrfs_get_blocks_direct+0x3ef/0x571 [btrfs]
    [] do_blockdev_direct_IO+0x62a/0xb47
    [] __blockdev_direct_IO+0x34/0x36
    [] btrfs_direct_IO+0x16a/0x1e8 [btrfs]
    [] generic_file_direct_write+0xb8/0x12d
    [] btrfs_file_write_iter+0x24b/0x42f [btrfs]
    [] aio_run_iocb+0x2b7/0x32e
    [] do_io_submit+0x26e/0x2ff
    [] SyS_io_submit+0x10/0x12
    [] system_call_fastpath+0x12/0x17

CC:  # 3.19, 3.18 and 3.17
Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason

Btrfs: collect only the necessary ordered extents on ranged fsync

2014-11-21T19:59:56+00:00

Instead of collecting all ordered extents from the inode's ordered tree
and then wait for all of them to complete, just collect the ones that
overlap the fsync range.

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

Btrfs: make sure logged extents complete in the current transaction V3

2014-11-21T19:58:32+00:00

Liu Bo pointed out that my previous fix would lose the generation update in the
scenario I described.  It is actually much worse than that, we could lose the
entire extent if we lose power right after the transaction commits.  Consider
the following

write extent 0-4k
log extent in log tree
commit transaction
	< power fail happens here
ordered extent completes

We would lose the 0-4k extent because it hasn't updated the actual fs tree, and
the transaction commit will reset the log so it isn't replayed.  If we lose
power before the transaction commit we are save, otherwise we are not.

Fix this by keeping track of all extents we logged in this transaction.  Then
when we go to commit the transaction make sure we wait for all of those ordered
extents to complete before proceeding.  This will make sure that if we lose
power after the transaction commit we still have our data.  This also fixes the
problem of the improperly updated extent generation.  Thanks,

cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: add helper btrfs_fdatawrite_range

2014-11-21T01:14:28+00:00

To avoid duplicating this double filemap_fdatawrite_range() call for
inodes with async extents (compressed writes) so often.

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

Btrfs: fix task hang under heavy compressed write

2014-08-24T14:17:02+00:00

This has been reported and discussed for a long time, and this hang occurs in
both 3.15 and 3.16.

Btrfs now migrates to use kernel workqueue, but it introduces this hang problem.

Btrfs has a kind of work queued as an ordered way, which means that its
ordered_func() must be processed in the way of FIFO, so it usually looks like --

normal_work_helper(arg)
    work = container_of(arg, struct btrfs_work, normal_work);

    work->func() <---- (we name it work X)
    for ordered_work in wq->ordered_list
            ordered_work->ordered_func()
            ordered_work->ordered_free()

The hang is a rare case, first when we find free space, we get an uncached block
group, then we go to read its free space cache inode for free space information,
so it will

file a readahead request
    btrfs_readpages()
         for page that is not in page cache
                __do_readpage()
                     submit_extent_page()
                           btrfs_submit_bio_hook()
                                 btrfs_bio_wq_end_io()
                                 submit_bio()
                                 end_workqueue_bio() <--(ret by the 1st endio)
                                      queue a work(named work Y) for the 2nd
                                      also the real endio()

So the hang occurs when work Y's work_struct and work X's work_struct happens
to share the same address.

A bit more explanation,

A,B,C -- struct btrfs_work
arg   -- struct work_struct

kthread:
worker_thread()
    pick up a work_struct from @worklist
    process_one_work(arg)
	worker->current_work = arg;  <-- arg is A->normal_work
	worker->current_func(arg)
		normal_work_helper(arg)
		     A = container_of(arg, struct btrfs_work, normal_work);

		     A->func()
		     A->ordered_func()
		     A->ordered_free()  <-- A gets freed

		     B->ordered_func()
			  submit_compressed_extents()
			      find_free_extent()
				  load_free_space_inode()
				      ...   <-- (the above readhead stack)
				      end_workqueue_bio()
					   btrfs_queue_work(work C)
		     B->ordered_free()

As if work A has a high priority in wq->ordered_list and there are more ordered
works queued after it, such as B->ordered_func(), its memory could have been
freed before normal_work_helper() returns, which means that kernel workqueue
code worker_thread() still has worker->current_work pointer to be work
A->normal_work's, ie. arg's address.

Meanwhile, work C is allocated after work A is freed, work C->normal_work
and work A->normal_work are likely to share the same address(I confirmed this
with ftrace output, so I'm not just guessing, it's rare though).

When another kthread picks up work C->normal_work to process, and finds our
kthread is processing it(see find_worker_executing_work()), it'll think
work C as a collision and skip then, which ends up nobody processing work C.

So the situation is that our kthread is waiting forever on work C.

Besides, there're other cases that can lead to deadlock, but the real problem
is that all btrfs workqueue shares one work->func, -- normal_work_helper,
so this makes each workqueue to have its own helper function, but only a
wraper pf normal_work_helper.

With this patch, I no long hit the above hang.

Signed-off-by: Liu Bo 
Signed-off-by: Chris Mason

btrfs: disable strict file flushes for renames and truncates

2014-08-15T14:43:42+00:00

Truncates and renames are often used to replace old versions of a file
with new versions.  Applications often expect this to be an atomic
replacement, even if they haven't done anything to make sure the new
version is fully on disk.

Btrfs has strict flushing in place to make sure that renaming over an
old file with a new file will fully flush out the new file before
allowing the transaction commit with the rename to complete.

This ordering means the commit code needs to be able to lock file pages,
and there are a few paths in the filesystem where we will try to end a
transaction with the page lock held.  It's rare, but these things can
deadlock.

This patch removes the ordered flushes and switches to a best effort
filemap_flush like ext4 uses. It's not perfect, but it should fix the
deadlocks.

Signed-off-by: Chris Mason

Btrfs: fix abnormal long waiting in fsync

2014-07-19T18:49:44+00:00

xfstests generic/127 detected this problem.

With commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8, now fsync will only flush
data within the passed range.  This is the cause of the above problem,
-- btrfs's fsync has a stage called 'sync log' which will wait for all the
ordered extents it've recorded to finish.

In xfstests/generic/127, with mixed operations such as truncate, fallocate,
punch hole, and mapwrite, we get some pre-allocated extents, and mapwrite will
mmap, and then msync.  And I find that msync will wait for quite a long time
(about 20s in my case), thanks to ftrace, it turns out that the previous
fallocate calls 'btrfs_wait_ordered_range()' to flush dirty pages, but as the
range of dirty pages may be larger than 'btrfs_wait_ordered_range()' wants,
there can be some ordered extents created but not getting corresponding pages
flushed, then they're left in memory until we fsync which runs into the
stage 'sync log', and fsync will just wait for the system writeback thread
to flush those pages and get ordered extents finished, so the latency is
inevitable.

This adds a flush similar to btrfs_start_ordered_extent() in
btrfs_wait_logged_extents() to fix that.

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

btrfs: remove stale newlines from log messages

2014-06-10T00:20:53+00:00

I've noticed an extra line after "use no compression", but search
revealed much more in messages of more critical levels and rare errors.

Signed-off-by: David Sterba 
Signed-off-by: Chris Mason

Btrfs: split the global ordered extents mutex

2014-03-10T19:17:28+00:00

When we create a snapshot, we just need wait the ordered extents in
the source fs/file root, but because we use the global mutex to protect
this ordered extents list of the source fs/file root to avoid accessing
a empty list, if someone got the mutex to access the ordered extents list
of the other fs/file root, we had to wait.

This patch splits the above global mutex, now every fs/file root has
its own mutex to protect its own list.

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik

Btrfs: wake up the tasks that wait for the io earlier

2014-03-10T19:17:23+00:00

The tasks that wait for the IO_DONE flag just care about the io of the dirty
pages, so it is better to wake up them immediately after all the pages are
written, not the whole process of the io completes.

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik