linux-kernel - Re: Sub volumes handling in bch2_fsck_update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <22hlu76p6uzlu6zexcjxgpijenfba3en4bx74nx6etr2mpgw4g@liyxgcpx7hbl>
Date: Wed, 23 Apr 2025 12:47:44 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Arnaud Lecomte <contact@...aud-lcm.com>
Cc: syzbot+843981bb836d699c07d1@...kaller.appspotmail.com, 
	linux-bcachefs@...r.kernel.org, linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: Sub volumes handling in bch2_fsck_update_backpointers

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.