On Tue, Oct 10, 2023 at 11:20:59PM +0800, Coly Li wrote: > Forward it to [email protected] > <mailto:[email protected]> > > > 2023年10月10日 07:43，Daniel J Blueman <[email protected]> 写道： > > > > Firstly, bcachefs introduces a new era of in-tree filesystems with > > some monumental features (sorry, ZFS); hats off to Kent for landing > > this! > > > > My testing finds it is in great shape; far better than BTRFS was when > > it landed. Testing on linux next-20231005 with additional debug checks > > atop the Ubuntu 23.04 kernel generic config [1], I was able to provoke > > a btree trans path overflow cornercase [2]. > > > > The minimal reproducer is: > > # modprobe brd rd_nr=2 rd_size=1048576 > > # bcachefs format --metadata_replicas=2 --label=tier1.1 /dev/ram0 > > --label=tier1.2 /dev/ram1 > > # mount -t bcachefs /dev/ram0:/dev/ram1 /mnt > > # dd if=/dev/zero of=/mnt/test bs=128M > > > > The issue doesn't reproduce with metadata_replicas=1 or a single block > > device. > > > > At debug entry, I couldn't determine why BTREE_ITER_MAX must be 64 > > rather than 32 when CONFIG_LOCKDEP is set, however the panic doesn't > > occur without CONFIG_LOCKDEP, so it appears related; keeping it at > > value 32 with CONFIG_LOCKDEP doesn't prevent the panic also.
Lockup can only track up to 48 held locks but each btree path can hold a lock - hence we need to limit the number of max paths for lockdep to function. In the main branch there's a patch that ups the lockdep limit to 63 and drops the BTREE_ITER_MAX=32. The underlying issue is a bit more serious though; it is becoming increasingly impractical to count the number of paths we're going to need ahead of time so that we can run inside of a fixed limit. There's a number of extra btrees for allocation purposes that we only hit sometimes, and we really can't predict ahead of time which ones will need to be updated. Long term, we're probably going to need to figure out a way to dynamically allocate btree paths and get rid of the fixed limit.
