fs/bcachefs/btree_node_scan.c | 3 +++ 1 file changed, 3 insertions(+)
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].
[1] https://syzkaller.appspot.com/bug?extid=cf7b2215b5d70600ec00
Reported-by: syzbot+cf7b2215b5d70600ec00@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=cf7b2215b5d70600ec00
Fixes: 4409b8081d16 ("bcachefs: Repair pass for scanning for btree nodes")
Signed-off-by: Piotr Zalewski <pZ010001011111@proton.me>
---
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
> 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: syzbot+cf7b2215b5d70600ec00@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=cf7b2215b5d70600ec00
> Fixes: 4409b8081d16 ("bcachefs: Repair pass for scanning for btree nodes")
> Signed-off-by: Piotr Zalewski pZ010001011111@proton.me
>
> ---
> 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
>
On Mon, Oct 07, 2024 at 02:53:13AM GMT, Piotr Zalewski wrote: > > 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 Your patch looks correct, [2] shouldn't be possible with it - and it appears to only be reported on upstream commits. I'll apply your patch.
On Monday, October 7th, 2024 at 5:05 AM, Kent Overstreet <kent.overstreet@linux.dev> wrote: > On Mon, Oct 07, 2024 at 02:53:13AM GMT, Piotr Zalewski wrote: > > > > 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 > > > Your patch looks correct, [2] shouldn't be possible with it - and it > appears to only be reported on upstream commits. I'll apply your patch. Hi Kent, Today I sat down to the other bug found by syzbot and retested it on master, it triggers the same deadlock warning[3]. It seems like in bch2_replicas_entry_validate mutex doesn't have to be always acquired? Also, I found the issue for specifically that warning[4]. The "count" is high for the issue, is there some patch for that already pending? I couldn't find any. [3] https://syzkaller.appspot.com/bug?extid=a1b59c8e1a3f022fd301 [4] https://syzkaller.appspot.com/bug?extid=4d24267b490e2b68a5fa Best regards, Piotr Zalewski
© 2016 - 2026 Red Hat, Inc.