file system crash

[Renaud Barbier]

I have a BSP (not upstreamed) using a ARMv9 that I rebased fromv2025.06 to 2026.01. This board has a SPI NOR with a UBI volume.
The system starts perfectly.

When doing an umount or ls -l or reset barebox crashes. Debugging the code,  the cdevname pointer in destroy_inode is sometimes (set to 0xffffffff) or the string corrupted. Also below the filename is corrupted.
OWBOOT> / ls -l /mnt/primary
ERROR: RENAUD: cdev_by_name: name = cs0 filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0 filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment filename = .ӿk
…
One can see the filename above is corrupted

During reset:
ERROR: RENAUD: devfs_open: cdevname = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = cs0 filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0 filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.env-secondary filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.boot-vars filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: found cdev m25p0.boot-vars
ERROR: fs_remove: ENTER
ERROR: ubifs_remove: ENTER
ERROR: ubifs_remove: END
ERROR: destroy_inode: inode = bff36380
ERROR: destroy_inode: cdevname@ = bff3647c
ERROR: RENAUD: destroy_inode cdevname: tc`, len = 5 ???
!block_is_last(block)common/tlsf.c 253
[<dfd8387c>] (unwind_backtrace+0x0/0xe4) from [<dfd0a0dc>] (block_next+0x38/0x48)
[<dfd0a0dc>] (block_next+0x38/0x48) from [<dfd0a0f8>] (block_link_next+0xc/0x14)
[<dfd0a0f8>] (block_link_next+0xc/0x14) from [<dfd0a76c>] (tlsf_free+0x48/0x108)
[<dfd0a76c>] (tlsf_free+0x48/0x108) from [<dfd65a74>] (destroy_inode+0x84/0x188)
[<dfd65a74>] (destroy_inode+0x84/0x188) from [<dfd671cc>] (dentry_kill+0x18/0x54)
[<dfd671cc>] (dentry_kill+0x18/0x54) from [<dfd67e24>] (fs_remove+0x144/0x1b0)
[<dfd67e24>] (fs_remove+0x144/0x1b0) from [<dfd12230>] (devices_shutdown+0x54/0x68)
[<dfd12230>] (devices_shutdown+0x54/0x68) from [<dfd0221c>] (shutdown_barebox+0x44/0x58)
[<dfd0221c>] (shutdown_barebox+0x44/0x58) from [<dfd48244>] (cmd_reset+0x114/0x154)
[<dfd48244>] (cmd_reset+0x114/0x154) from [<dfd06160>] (execute_command+0x4c/0x90)
[<dfd06160>] (execute_command+0x4c/0x90) from [<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0)
[<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0) from [<dfd0d13c>] (parse_stream_outer+0x130/0x1f4)
[<dfd0d13c>] (parse_stream_outer+0x130/0x1f4) from [<dfd0df04>] (run_shell+0x74/0xb4)
[<dfd0df04>] (run_shell+0x74/0xb4) from [<dfd01e80>] (start_barebox+0x58/0x9c)
[<dfd01e80>] (start_barebox+0x58/0x9c) from [<dfd7f1b8>] (barebox_non_pbl_start+0xc4/0xdc)
[<dfd7f1b8>] (barebox_non_pbl_start+0xc4/0xdc) from [<dfd00004>] (__bare_init_start+0x0/0x10)

Again, it seems there is memory corruption of cdevname

Has anybody seen this?

Note this is not happening with barebox v2025.12.0 and I did notice there was lots of rework on the fs directory from v2026.01