bcachefs: Fix for shared paths in write buffer flush

It's possible for bch2_write_buffer_flush_one() to end up with a shared
path, if called from a context that already has a btree iterator
pointing to a key being flushed. We have to be careful when that
happens, since we can't clone a path that holds write locks.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>

diff --git a/fs/bcachefs/btree_write_buffer.c b/fs/bcachefs/btree_write_buffer.c
index 6285532e77904f3e834afe317d0b6fac98b36aa5..026c249a3f441c9073aaa2641a9fec9290b50baf 100644 (file)
--- a/fs/bcachefs/btree_write_buffer.c
+++ b/fs/bcachefs/btree_write_buffer.c
@@ -64,6 +64,15 @@ static int bch2_btree_write_buffer_flush_one(struct btree_trans *trans,
 
        bch2_btree_insert_key_leaf(trans, path, &wb->k, wb->journal_seq);
        (*fast)++;
+
+       if (path->ref > 1) {
+               /*
+                * We can't clone a path that has write locks: if the path is
+                * shared, unlock before set_pos(), traverse():
+                */
+               bch2_btree_node_unlock_write(trans, path, path->l[0].b);
+               *write_locked = false;
+       }
        return 0;
 trans_commit:
        return  bch2_trans_update(trans, iter, &wb->k, 0) ?: