> Add check for read node's btree_id against BTREE_ID_NR_MAX in > try_read_btree_node to prevent triggering EBUG_ON condition in > bch2_btree_id_root[1].
There seems to be some kind of (pro)regression regarding this issue. Now it triggers a deadlock. I also found related bug detected by syzbot[2] for which someone supplied the same patch recently and it triggered the same deadlock. I will look into it (perhaps simple check isn't a proper fix here). > [1] https://syzkaller.appspot.com/bug?extid=cf7b2215b5d70600ec00 [2] https://syzkaller.appspot.com/bug?extid=9f41e4b255897d99d4e9 > Reported-by: [email protected] > Closes: https://syzkaller.appspot.com/bug?extid=cf7b2215b5d70600ec00 > Fixes: 4409b8081d16 ("bcachefs: Repair pass for scanning for btree nodes") > Signed-off-by: Piotr Zalewski [email protected] > > --- > fs/bcachefs/btree_node_scan.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/bcachefs/btree_node_scan.c b/fs/bcachefs/btree_node_scan.c > index b28c649c6838..a24b4004e8f0 100644 > --- a/fs/bcachefs/btree_node_scan.c > +++ b/fs/bcachefs/btree_node_scan.c > @@ -171,6 +171,9 @@ static void try_read_btree_node(struct find_btree_nodes > *f, struct bch_dev *ca, > if (BTREE_NODE_LEVEL(bn) >= BTREE_MAX_DEPTH) > > return; > > + if (BTREE_NODE_ID(bn) >= BTREE_ID_NR_MAX) > > + return; > + > rcu_read_lock(); > struct found_btree_node n = { > .btree_id = BTREE_NODE_ID(bn), > -- > 2.46.2 >
