[syzbot] [bcachefs?] kernel BUG in __bch2_str_hash_check_key

[syzbot] [bcachefs?] kernel BUG in __bch2_str_hash_check_key

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    56f944529ec2 Merge tag 'input-for-v6.15-rc0' of git://git...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16391fb0580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f2054704dd53fb80
dashboard link: https://syzkaller.appspot.com/bug?extid=843981bb836d699c07d1
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-56f94452.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c6da83e5191b/vmlinux-56f94452.xz
kernel image: https://storage.googleapis.com/syzbot-assets/5c060438ea13/bzImage-56f94452.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+843981bb836d699c07d1@syzkaller.appspotmail.com

    bi_dir=4096
    bi_dir_offset=5682031293254759865
    bi_subvol=0
    bi_parent_subvol=0
    bi_nocow=0
    bi_depth=0
    bi_inodes_32bit=0, fixing
bcachefs (loop0): inode points to missing dirent
  inum: 4099:4294967295 
    mode=100755
    flags=(15300000)
    journal_seq=5
    hash_seed=ab878b4c5ab7c89e
    hash_type=siphash
    bi_size=1050
    bi_sectors=8
    bi_version=0
    bi_atime=1997793410
    bi_ctime=1997793410
    bi_mtime=1997793410
    bi_otime=1997793410
    bi_uid=0
    bi_gid=0
    bi_nlink=0
    bi_generation=0
    bi_dev=0
    bi_data_checksum=0
    bi_compression=0
    bi_project=0
    bi_background_compression=0
    bi_data_replicas=0
    bi_promote_target=0
    bi_foreground_target=0
    bi_background_target=0
    bi_erasure_code=0
    bi_fields_set=0
    bi_dir=4098
    bi_dir_offset=2566586984702133180
    bi_subvol=0
    bi_parent_subvol=0
    bi_nocow=0
    bi_depth=0
    bi_inodes_32bit=0, fixing
 done
bcachefs (loop0): check_dirents...
bcachefs (loop0): hash table key at wrong offset: btree dirents inode 4096 offset 6229884513039707068, hashed to 5410109479790105297
  u64s 7 type dirent 4096:6229884513039707068:U32_MAX len 0 ver 0: �˨� -> 2166030336 -> 1073741825 type subvol, fixing
bcachefs (loop0): hash table key at wrong offset: btree dirents inode 4096 offset 6229884513039707068, hashed to 5410109479790105297
  u64s 7 type dirent 4096:6229884513039707068:U32_MAX len 0 ver 0: �˨� -> 2166030336 -> 1073741825 type subvol, fixing
------------[ cut here ]------------
kernel BUG at fs/bcachefs/fsck.c:954!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5328 Comm: syz.0.0 Not tainted 6.14.0-syzkaller-13443-g56f944529ec2 #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:bch2_fsck_update_backpointers+0x4ed/0x4f0 fs/bcachefs/fsck.c:954
Code: e9 2b fc ff ff 89 d9 80 e1 07 38 c1 0f 8c 62 fc ff ff 48 89 df e8 63 77 b7 fd e9 55 fc ff ff e8 39 78 ba 07 e8 74 4e 4d fd 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e
RSP: 0018:ffffc9000d4ce460 EFLAGS: 00010246
RAX: ffffffff847608cc RBX: 0000000000000010 RCX: 0000000000100000
RDX: ffffc9000e50a000 RSI: 00000000000fffff RDI: 0000000000100000
RBP: ffffc9000d4ce600 R08: ffffffff84760529 R09: 0000000000000000
R10: ffffc9000d4ce530 R11: fffff52001a99caf R12: ffffc9000d4cf290
R13: dffffc0000000000 R14: ffff888052bda000 R15: ffff888052900000
FS:  00007f5be4f2b6c0(0000) GS:ffff88808c596000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055b32eddc088 CR3: 0000000044eda000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 __bch2_str_hash_check_key+0x202c/0x3b50 fs/bcachefs/str_hash.c:257
 bch2_str_hash_check_key fs/bcachefs/str_hash.h:415 [inline]
 check_dirent fs/bcachefs/fsck.c:2135 [inline]
 bch2_check_dirents+0x2d45/0x3b90 fs/bcachefs/fsck.c:2230
 bch2_run_recovery_pass+0xf0/0x1e0 fs/bcachefs/recovery_passes.c:226
 bch2_run_recovery_passes+0x2ad/0xa90 fs/bcachefs/recovery_passes.c:285
 bch2_fs_recovery+0x292a/0x3e20 fs/bcachefs/recovery.c:936
 bch2_fs_start+0x310/0x620 fs/bcachefs/super.c:1069
 bch2_fs_get_tree+0x113e/0x18f0 fs/bcachefs/fs.c:2253
 vfs_get_tree+0x90/0x2b0 fs/super.c:1759
 do_new_mount+0x2cf/0xb70 fs/namespace.c:3879
 do_mount fs/namespace.c:4219 [inline]
 __do_sys_mount fs/namespace.c:4430 [inline]
 __se_sys_mount+0x38c/0x400 fs/namespace.c:4407
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5be418e90a
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 de 1a 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f5be4f2ae68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f5be4f2aef0 RCX: 00007f5be418e90a
RDX: 000020000000f640 RSI: 0000200000000140 RDI: 00007f5be4f2aeb0
RBP: 000020000000f640 R08: 00007f5be4f2aef0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000200000000140
R13: 00007f5be4f2aeb0 R14: 000000000000f61b R15: 0000200000000340
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:bch2_fsck_update_backpointers+0x4ed/0x4f0 fs/bcachefs/fsck.c:954
Code: e9 2b fc ff ff 89 d9 80 e1 07 38 c1 0f 8c 62 fc ff ff 48 89 df e8 63 77 b7 fd e9 55 fc ff ff e8 39 78 ba 07 e8 74 4e 4d fd 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e
RSP: 0018:ffffc9000d4ce460 EFLAGS: 00010246
RAX: ffffffff847608cc RBX: 0000000000000010 RCX: 0000000000100000
RDX: ffffc9000e50a000 RSI: 00000000000fffff RDI: 0000000000100000
RBP: ffffc9000d4ce600 R08: ffffffff84760529 R09: 0000000000000000
R10: ffffc9000d4ce530 R11: fffff52001a99caf R12: ffffc9000d4cf290
R13: dffffc0000000000 R14: ffff888052bda000 R15: ffff888052900000
FS:  00007f5be4f2b6c0(0000) GS:ffff88808c596000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055b32eddc088 CR3: 0000000044eda000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [bcachefs?] kernel BUG in __bch2_str_hash_check_key

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    9d7a0577c9db gcc-15: disable '-Wunterminated-string-initia..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15456c70580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=45c3bf6fd4cb6a10
dashboard link: https://syzkaller.appspot.com/bug?extid=843981bb836d699c07d1
compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=100ca63f980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=138f0ccc580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-9d7a0577.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2451ac2169e6/vmlinux-9d7a0577.xz
kernel image: https://storage.googleapis.com/syzbot-assets/14cc88d90db9/bzImage-9d7a0577.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/403f0024ed04/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+843981bb836d699c07d1@syzkaller.appspotmail.com

bcachefs (loop0): hash table key at wrong offset: btree dirents inode 4096 offset 6229884513039707068, hashed to 2263426191451115502
  u64s 7 type dirent 4096:6229884513039707068:U32_MAX len 0 ver 0: ��le2 -> 2165878814 -> 1056964609 type subvol, fixing
------------[ cut here ]------------
kernel BUG at fs/bcachefs/fsck.c:979!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5314 Comm: syz-executor312 Not tainted 6.15.0-rc3-syzkaller-00001-g9d7a0577c9db #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:bch2_fsck_update_backpointers+0x4ed/0x4f0 fs/bcachefs/fsck.c:979
Code: e9 2b fc ff ff 89 d9 80 e1 07 38 c1 0f 8c 62 fc ff ff 48 89 df e8 63 c6 b7 fd e9 55 fc ff ff e8 29 70 ba 07 e8 04 8d 4d fd 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e
RSP: 0018:ffffc9000d426460 EFLAGS: 00010293
RAX: ffffffff8475301c RBX: 0000000000000010 RCX: ffff88800081a440
RDX: 0000000000000000 RSI: 0000000000000010 RDI: 0000000000000010
RBP: ffffc9000d426600 R08: ffffffff84752c79 R09: 0000000000000000
R10: ffffc9000d426530 R11: fffff52001a84caf R12: ffffc9000d427290
R13: dffffc0000000000 R14: ffff888040e75f00 R15: ffff88803fdb0000
FS:  000055557bb26380(0000) GS:ffff88808c59a000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a385eda068 CR3: 0000000043706000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 __bch2_str_hash_check_key+0x202c/0x3b50 fs/bcachefs/str_hash.c:257
 bch2_str_hash_check_key fs/bcachefs/str_hash.h:415 [inline]
 check_dirent fs/bcachefs/fsck.c:2177 [inline]
 bch2_check_dirents+0x2d45/0x3b90 fs/bcachefs/fsck.c:2272
 bch2_run_recovery_pass+0xf0/0x1e0 fs/bcachefs/recovery_passes.c:226
 bch2_run_recovery_passes+0x2ad/0xa90 fs/bcachefs/recovery_passes.c:285
 bch2_fs_recovery+0x292a/0x3e20 fs/bcachefs/recovery.c:936
 bch2_fs_start+0x310/0x620 fs/bcachefs/super.c:1065
 bch2_fs_get_tree+0x113e/0x18f0 fs/bcachefs/fs.c:2253
 vfs_get_tree+0x90/0x2b0 fs/super.c:1759
 do_new_mount+0x2cf/0xb70 fs/namespace.c:3881
 do_mount fs/namespace.c:4221 [inline]
 __do_sys_mount fs/namespace.c:4432 [inline]
 __se_sys_mount+0x38c/0x400 fs/namespace.c:4409
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f05363dcf6a
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 5e 04 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe48350348 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffe48350360 RCX: 00007f05363dcf6a
RDX: 000020000000f640 RSI: 0000200000000200 RDI: 00007ffe48350360
RBP: 0000200000000200 R08: 00007ffe483503a0 R09: 000000000000f64b
R10: 0000000002a18414 R11: 0000000000000282 R12: 000020000000f640
R13: 00007ffe483503a0 R14: 0000000000000003 R15: 0000000002a18414
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:bch2_fsck_update_backpointers+0x4ed/0x4f0 fs/bcachefs/fsck.c:979
Code: e9 2b fc ff ff 89 d9 80 e1 07 38 c1 0f 8c 62 fc ff ff 48 89 df e8 63 c6 b7 fd e9 55 fc ff ff e8 29 70 ba 07 e8 04 8d 4d fd 90 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e
RSP: 0018:ffffc9000d426460 EFLAGS: 00010293
RAX: ffffffff8475301c RBX: 0000000000000010 RCX: ffff88800081a440
RDX: 0000000000000000 RSI: 0000000000000010 RDI: 0000000000000010
RBP: ffffc9000d426600 R08: ffffffff84752c79 R09: 0000000000000000
R10: ffffc9000d426530 R11: fffff52001a84caf R12: ffffc9000d427290
R13: dffffc0000000000 R14: ffff888040e75f00 R15: ffff88803fdb0000
FS:  000055557bb26380(0000) GS:ffff88808c59a000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a385eda068 CR3: 0000000043706000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

Sub volumes handling in bch2_fsck_update_backpointers

[Arnaud Lecomte]

Hey everyone, in fsck.c, we have:
/*
 * Prefer to delete the first one, since that will be the one at the wrong
 * offset:
 * return value: 0 -> delete k1, 1 -> delete k2
 */
int bch2_fsck_update_backpointers(struct btree_trans *trans,
				  struct snapshots_seen *s,
				  const struct bch_hash_desc desc,
				  struct bch_hash_info *hash_info,
				  struct bkey_i *new)
{
	if (new->k.type != KEY_TYPE_dirent)
		return 0;

	struct bkey_i_dirent *d = bkey_i_to_dirent(new);
	struct inode_walker target = inode_walker_init();
	int ret = 0;

	if (d->v.d_type == DT_SUBVOL) {
		BUG();
	} else {
		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(d->v.d_inum));
		if (ret)
			goto err;

		darray_for_each(target.inodes, i) {
			i->inode.bi_dir_offset = d->k.p.offset;
			ret = __bch2_fsck_write_inode(trans, &i->inode);
			if (ret)
				goto err;
		}
	}
err:
	inode_walker_exit(&target);
	return ret;
}

What is the current state for handling subvolumes ? In someone already working on or it is something we don't want to implement
for some reasons ?

Regards,
Arnaud

Re: Sub volumes handling in bch2_fsck_update_backpointers

[Kent Overstreet]

On Wed, Apr 23, 2025 at 05:45:31PM +0200, Arnaud Lecomte wrote:
> Hey everyone, in fsck.c, we have:
> /*
>  * Prefer to delete the first one, since that will be the one at the wrong
>  * offset:
>  * return value: 0 -> delete k1, 1 -> delete k2
>  */
> int bch2_fsck_update_backpointers(struct btree_trans *trans,
> 				  struct snapshots_seen *s,
> 				  const struct bch_hash_desc desc,
> 				  struct bch_hash_info *hash_info,
> 				  struct bkey_i *new)
> {
> 	if (new->k.type != KEY_TYPE_dirent)
> 		return 0;
> 
> 	struct bkey_i_dirent *d = bkey_i_to_dirent(new);
> 	struct inode_walker target = inode_walker_init();
> 	int ret = 0;
> 
> 	if (d->v.d_type == DT_SUBVOL) {
> 		BUG();
> 	} else {
> 		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(d->v.d_inum));
> 		if (ret)
> 			goto err;
> 
> 		darray_for_each(target.inodes, i) {
> 			i->inode.bi_dir_offset = d->k.p.offset;
> 			ret = __bch2_fsck_write_inode(trans, &i->inode);
> 			if (ret)
> 				goto err;
> 		}
> 	}
> err:
> 	inode_walker_exit(&target);
> 	return ret;
> }
> 
> What is the current state for handling subvolumes ? In someone already working on or it is something we don't want to implement
> for some reasons ?

This does need to be handled, I haven't started on it yet.

I did just fix another subvolume root backpointers bug, which makes this
one easier - now, only the newest snapshot version of a subvolume root
inode needs to have a backpointer.

Re: Sub volumes handling in bch2_fsck_update_backpointers

[Arnaud Lecomte]

Would you be  okay if I try to handle it ? I am fairly new to bcachefs 
but I am really interested to get involve into it, I like the project.

On 23/04/2025 18:47, Kent Overstreet wrote:
> On Wed, Apr 23, 2025 at 05:45:31PM +0200, Arnaud Lecomte wrote:
>> Hey everyone, in fsck.c, we have:
>> /*
>>   * Prefer to delete the first one, since that will be the one at the wrong
>>   * offset:
>>   * return value: 0 -> delete k1, 1 -> delete k2
>>   */
>> int bch2_fsck_update_backpointers(struct btree_trans *trans,
>> 				  struct snapshots_seen *s,
>> 				  const struct bch_hash_desc desc,
>> 				  struct bch_hash_info *hash_info,
>> 				  struct bkey_i *new)
>> {
>> 	if (new->k.type != KEY_TYPE_dirent)
>> 		return 0;
>>
>> 	struct bkey_i_dirent *d = bkey_i_to_dirent(new);
>> 	struct inode_walker target = inode_walker_init();
>> 	int ret = 0;
>>
>> 	if (d->v.d_type == DT_SUBVOL) {
>> 		BUG();
>> 	} else {
>> 		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(d->v.d_inum));
>> 		if (ret)
>> 			goto err;
>>
>> 		darray_for_each(target.inodes, i) {
>> 			i->inode.bi_dir_offset = d->k.p.offset;
>> 			ret = __bch2_fsck_write_inode(trans, &i->inode);
>> 			if (ret)
>> 				goto err;
>> 		}
>> 	}
>> err:
>> 	inode_walker_exit(&target);
>> 	return ret;
>> }
>>
>> What is the current state for handling subvolumes ? In someone already working on or it is something we don't want to implement
>> for some reasons ?
> This does need to be handled, I haven't started on it yet.
>
> I did just fix another subvolume root backpointers bug, which makes this
> one easier - now, only the newest snapshot version of a subvolume root
> inode needs to have a backpointer.
>

Re: Sub volumes handling in bch2_fsck_update_backpointers

[Kent Overstreet]

On Wed, Apr 23, 2025 at 07:18:34PM +0200, Arnaud Lecomte wrote:
> Would you be  okay if I try to handle it ? I am fairly new to bcachefs but I
> am really interested to get involve into it, I like the project.

go for it, get ktest going and join the IRC channel

https://evilpiepirate.org/git/ktest.git/

> 
> On 23/04/2025 18:47, Kent Overstreet wrote:
> > On Wed, Apr 23, 2025 at 05:45:31PM +0200, Arnaud Lecomte wrote:
> > > Hey everyone, in fsck.c, we have:
> > > /*
> > >   * Prefer to delete the first one, since that will be the one at the wrong
> > >   * offset:
> > >   * return value: 0 -> delete k1, 1 -> delete k2
> > >   */
> > > int bch2_fsck_update_backpointers(struct btree_trans *trans,
> > > 				  struct snapshots_seen *s,
> > > 				  const struct bch_hash_desc desc,
> > > 				  struct bch_hash_info *hash_info,
> > > 				  struct bkey_i *new)
> > > {
> > > 	if (new->k.type != KEY_TYPE_dirent)
> > > 		return 0;
> > > 
> > > 	struct bkey_i_dirent *d = bkey_i_to_dirent(new);
> > > 	struct inode_walker target = inode_walker_init();
> > > 	int ret = 0;
> > > 
> > > 	if (d->v.d_type == DT_SUBVOL) {
> > > 		BUG();
> > > 	} else {
> > > 		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(d->v.d_inum));
> > > 		if (ret)
> > > 			goto err;
> > > 
> > > 		darray_for_each(target.inodes, i) {
> > > 			i->inode.bi_dir_offset = d->k.p.offset;
> > > 			ret = __bch2_fsck_write_inode(trans, &i->inode);
> > > 			if (ret)
> > > 				goto err;
> > > 		}
> > > 	}
> > > err:
> > > 	inode_walker_exit(&target);
> > > 	return ret;
> > > }
> > > 
> > > What is the current state for handling subvolumes ? In someone already working on or it is something we don't want to implement
> > > for some reasons ?
> > This does need to be handled, I haven't started on it yet.
> > 
> > I did just fix another subvolume root backpointers bug, which makes this
> > one easier - now, only the newest snapshot version of a subvolume root
> > inode needs to have a backpointer.
> > 

Re: Sub volumes handling in bch2_fsck_update_backpointers

[Arnaud Lecomte]

On 23/04/2025 19:46, Kent Overstreet wrote:
> On Wed, Apr 23, 2025 at 07:18:34PM +0200, Arnaud Lecomte wrote:
>> Would you be  okay if I try to handle it ? I am fairly new to bcachefs but I
>> am really interested to get involve into it, I like the project.
> go for it, get ktest going and join the IRC channel
>
> https://evilpiepirate.org/git/ktest.git/
Joined, I'll start tomorrow !  Thanks
>> On 23/04/2025 18:47, Kent Overstreet wrote:
>>> On Wed, Apr 23, 2025 at 05:45:31PM +0200, Arnaud Lecomte wrote:
>>>> Hey everyone, in fsck.c, we have:
>>>> /*
>>>>    * Prefer to delete the first one, since that will be the one at the wrong
>>>>    * offset:
>>>>    * return value: 0 -> delete k1, 1 -> delete k2
>>>>    */
>>>> int bch2_fsck_update_backpointers(struct btree_trans *trans,
>>>> 				  struct snapshots_seen *s,
>>>> 				  const struct bch_hash_desc desc,
>>>> 				  struct bch_hash_info *hash_info,
>>>> 				  struct bkey_i *new)
>>>> {
>>>> 	if (new->k.type != KEY_TYPE_dirent)
>>>> 		return 0;
>>>>
>>>> 	struct bkey_i_dirent *d = bkey_i_to_dirent(new);
>>>> 	struct inode_walker target = inode_walker_init();
>>>> 	int ret = 0;
>>>>
>>>> 	if (d->v.d_type == DT_SUBVOL) {
>>>> 		BUG();
>>>> 	} else {
>>>> 		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(d->v.d_inum));
>>>> 		if (ret)
>>>> 			goto err;
>>>>
>>>> 		darray_for_each(target.inodes, i) {
>>>> 			i->inode.bi_dir_offset = d->k.p.offset;
>>>> 			ret = __bch2_fsck_write_inode(trans, &i->inode);
>>>> 			if (ret)
>>>> 				goto err;
>>>> 		}
>>>> 	}
>>>> err:
>>>> 	inode_walker_exit(&target);
>>>> 	return ret;
>>>> }
>>>>
>>>> What is the current state for handling subvolumes ? In someone already working on or it is something we don't want to implement
>>>> for some reasons ?
>>> This does need to be handled, I haven't started on it yet.
>>>
>>> I did just fix another subvolume root backpointers bug, which makes this
>>> one easier - now, only the newest snapshot version of a subvolume root
>>> inode needs to have a backpointer.
>>>

Re: [syzbot] [bcachefs?] kernel BUG in __bch2_str_hash_check_key

[syzbot]

syzbot has bisected this issue to:

commit d37c14ac6f05ec98db9b3d9db424dc73a0f5b1cd
Author: Joshua Ashton <joshua@froggi.es>
Date:   Sun Aug 13 17:34:17 2023 +0000

    bcachefs: bcachefs_metadata_version_casefolding

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=10718ecc580000
start commit:   a79be02bba5c Fix mis-uses of 'cc-option' for warning disab..
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=12718ecc580000
console output: https://syzkaller.appspot.com/x/log.txt?x=14718ecc580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=3bbffc3b5b4301e1
dashboard link: https://syzkaller.appspot.com/bug?extid=843981bb836d699c07d1
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11f8c1b3980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=177ce574580000

Reported-by: syzbot+843981bb836d699c07d1@syzkaller.appspotmail.com
Fixes: d37c14ac6f05 ("bcachefs: bcachefs_metadata_version_casefolding")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

syztest

[Arnaud Lecomte]

#syz test

--- a/fs/bcachefs/fsck.c
+++ b/fs/bcachefs/fsck.c
@@ -976,7 +976,24 @@ int bch2_fsck_update_backpointers(struct btree_trans *trans,
 	int ret = 0;
 
 	if (d->v.d_type == DT_SUBVOL) {
-		BUG();
+		struct bch_subvolume subvol;
+
+		ret = bch2_subvolume_get(trans, le32_to_cpu(d->v.d_child_subvol),
+					     false, &subvol);
+		if (ret && !bch2_err_matches(ret, ENOENT))
+			goto err;
+
+		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(subvol.inode));
+		if (ret)
+			goto err;
+
+		if (target.inodes.nr) {
+			target.inodes.data[0].inode.bi_dir_offset = d->k.p.offset;
+			ret = __bch2_fsck_write_inode(trans, &target.inodes.data[0].inode);
+			if (ret)
+				goto err;
+		}
+
 	} else {
 		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(d->v.d_inum));
 		if (ret)
-- 
2.43.0

Re: syztest

[Kent Overstreet]

On Mon, Apr 28, 2025 at 06:09:03PM +0200, Arnaud Lecomte wrote:
> #syz test

Don't rely on syzbot for testing, you really need to be running the
tests yourself and looking at all the output.

It's not enough to know that we're not crashing anymore, we want the
filesystem to repair and mount successfully.

> --- a/fs/bcachefs/fsck.c
> +++ b/fs/bcachefs/fsck.c
> @@ -976,7 +976,24 @@ int bch2_fsck_update_backpointers(struct btree_trans *trans,
>  	int ret = 0;
>  
>  	if (d->v.d_type == DT_SUBVOL) {
> -		BUG();
> +		struct bch_subvolume subvol;
> +
> +		ret = bch2_subvolume_get(trans, le32_to_cpu(d->v.d_child_subvol),
> +					     false, &subvol);
> +		if (ret && !bch2_err_matches(ret, ENOENT))
> +			goto err;
> +
> +		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(subvol.inode));
> +		if (ret)
> +			goto err;
> +
> +		if (target.inodes.nr) {
> +			target.inodes.data[0].inode.bi_dir_offset = d->k.p.offset;
> +			ret = __bch2_fsck_write_inode(trans, &target.inodes.data[0].inode);
> +			if (ret)
> +				goto err;
> +		}
> +
>  	} else {
>  		ret = get_visible_inodes(trans, &target, s, le64_to_cpu(d->v.d_inum));
>  		if (ret)
> -- 
> 2.43.0

Re: [syzbot] [bcachefs?] kernel BUG in __bch2_str_hash_check_key

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+843981bb836d699c07d1@syzkaller.appspotmail.com
Tested-by: syzbot+843981bb836d699c07d1@syzkaller.appspotmail.com

Tested on:

commit:         b4432656 Linux 6.15-rc4
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=150dd270580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a33ce5560507649
dashboard link: https://syzkaller.appspot.com/bug?extid=843981bb836d699c07d1
compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2
patch:          https://syzkaller.appspot.com/x/patch.diff?x=11d7e368580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [bcachefs?] kernel BUG in __bch2_str_hash_check_key

[syzbot]

syzbot suspects this issue was fixed by commit:

commit 757601ef853359fe2d57d75c00b5045f62efc608
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Sun Jun 8 15:40:00 2025 +0000

    bcachefs: Don't put rhashtable on stack

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=15319582580000
start commit:   a79be02bba5c Fix mis-uses of 'cc-option' for warning disab..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=3bbffc3b5b4301e1
dashboard link: https://syzkaller.appspot.com/bug?extid=843981bb836d699c07d1
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11f8c1b3980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=177ce574580000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: bcachefs: Don't put rhashtable on stack

For information about bisection process see: https://goo.gl/tpsmEJ#bisection