[lkml]   [2019]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subject[PATCH 4.9 17/56] btrfs: remove WARN_ON in log_dir_items
    4.9-stable review patch.  If anyone has any objections, please let me know.


    From: Josef Bacik <>

    commit 2cc8334270e281815c3850c3adea363c51f21e0d upstream.

    When Filipe added the recursive directory logging stuff in
    2f2ff0ee5e430 ("Btrfs: fix metadata inconsistencies after directory
    fsync") he specifically didn't take the directory i_mutex for the
    children directories that we need to log because of lockdep. This is
    generally fine, but can lead to this WARN_ON() tripping if we happen to
    run delayed deletion's in between our first search and our second search
    of dir_item/dir_indexes for this directory. We expect this to happen,
    so the WARN_ON() isn't necessary. Drop the WARN_ON() and add a comment
    so we know why this case can happen.

    CC: # 4.4+
    Reviewed-by: Filipe Manana <>
    Signed-off-by: Josef Bacik <>
    Signed-off-by: David Sterba <>
    Signed-off-by: Greg Kroah-Hartman <>

    fs/btrfs/tree-log.c | 11 +++++++++--
    1 file changed, 9 insertions(+), 2 deletions(-)

    --- a/fs/btrfs/tree-log.c
    +++ b/fs/btrfs/tree-log.c
    @@ -3343,9 +3343,16 @@ static noinline int log_dir_items(struct

    - /* find the first key from this transaction again */
    + /*
    + * Find the first key from this transaction again. See the note for
    + * log_new_dir_dentries, if we're logging a directory recursively we
    + * won't be holding its i_mutex, which means we can modify the directory
    + * while we're logging it. If we remove an entry between our first
    + * search and this search we'll not find the key again and can just
    + * bail.
    + */
    ret = btrfs_search_slot(NULL, root, &min_key, path, 0, 0);
    - if (WARN_ON(ret != 0))
    + if (ret != 0)
    goto done;


     \ /
      Last update: 2019-04-01 19:53    [W:2.685 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site