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>
This commit is contained in:
parent
39a1ea129a
commit
747ded6ddf
@ -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) ?:
|
||||
|
Loading…
Reference in New Issue
Block a user