RE: file system crash

[Renaud Barbier <Renaud.Barbier@ametek.com>]

I have enabled KASAN but not output came from the barebox ELF. I can only see message from the PBL.
I later realize that if I replace in start_barebox, "pr_debug("initcall-> %pS\n", *initcall);" by just puts("call initcall\n"); I get two outputs

So that means the barebox load does not comes out of globalvar_init.

I did see a  store instructions of value 0xf1f1f1f1 to an invalid address using my ICE. Wonder if F1 could be related to 
#define KASAN_STACK_LEFT        0xF1

I skipped KASAN that for now and using old fashion debugging came down to:

  static struct inode *ubifs_alloc_inode(struct super_block *sb)
  {
          struct ubifs_inode *ui;

          ui = kmem_cache_alloc(ubifs_inode_slab, GFP_NOFS);
          if (!ui)
                  return NULL;

        memset((void *)ui + sizeof(struct inode), 0,
                        sizeof(struct ubifs_inode) - sizeof(struct inode));
          mutex_init(&ui->ui_mutex);
          spin_lock_init(&ui->ui_lock);
+
          return &ui->vfs_inode;
  };

This function does not clear  ui->vfs_inode which can contain stale data.
If I add     ui->vfs_inode.cdevname = NULL;  the crash described a few email down below does not appears and I can see the contain of the directory. Doing so,  it is likely I am hiding the real problem.

ls -l /mnt/primary/
ERROR: S_IFLNK: alloc ui->data = bfd2cd80 *** 
lrwxrwxrwx             12 fit.itb -> fitImage.itb
-rwxr-xr-x        8327352 fitImage.itb
...

Calling the reset command later, I see:

OWBOOT> / reset
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfd29800
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee8140
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee82c0
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7e80
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee8000
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7bc0
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7d40
ERROR: RENAUD: ubifs_destroy_inode ui->data = bfd2cd80 ***
ERROR: RENAUD: tlsf_free: freeing ptr = 0xbfd2cd80, block = 0xbfd2cd74, size = 67
!block_is_free(block) && "block already marked as free"common/tlsf.c 1061 [<dfd84abc>] (unwind_backtrace+0x0/0xe4) from [<dfd0b520>] (tlsf_free+0x70/0x144) [<dfd0b520>] (tlsf_free+0x70/0x144) from [<dfd6bb40>] (ubifs_destroy_inode+0x30/0x60) [<dfd6bb40>] (ubifs_destroy_inode+0x30/0x60) from [<dfd67328>] (destroy_inode+0x40/0x50) [<dfd67328>] (destroy_inode+0x40/0x50) from [<dfd6898c>] (dentry_kill+0x18/0x54) [<dfd6898c>] (dentry_kill+0x18/0x54) from [<dfd68a00>] (dentry_delete_subtree.isra.0+0x38/0x48)
ERROR: RENAUD: ubifs_destroy_inode ui = bfd2c380
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7940
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7800

Keeping investigating, this issue


> -----Original Message-----
> From: barebox <barebox-bounces@lists.infradead.org> On Behalf Of Renaud
> Barbier
> Sent: 17 March 2026 14:32
> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Barebox List
> <barebox@lists.infradead.org>
> Subject: RE: file system crash
> 
> ***NOTICE*** This came from an external source. Use caution when
> replying, clicking links, or opening attachments.
> 
> I meant ARM Cortex-A9
> 
> > -----Original Message-----
> > From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > Sent: 17 March 2026 11:16
> > To: Renaud Barbier <Renaud.Barbier@ametek.com>; Barebox List
> > <barebox@lists.infradead.org>
> > Subject: Re: file system crash
> >
> > ***NOTICE*** This came from an external source. Use caution when
> > replying, clicking links, or opening attachments.
> >
> > Hello Renaud,
> >
> > On 3/17/26 11:58 AM, Renaud Barbier wrote:
> > > 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.
> >
> > ARMv9 or ARM9?
> >
> > Can you rerun with CONFIG_KASAN=y and report the output?
> >
> > Thanks,
> > Ahmad
> >
> > >
> > > 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
> > >
> > >
> > >
> >
> > --
> > Pengutronix e.K.                  |                             |
> > Steuerwalder Str. 21              |
> >
> https://urldefense.com/v3/__http://www.pengutronix.de/__;!!HKOSU0g!Hv
> >
> VLvDMwr4aG6adXKP423MJRiCOajT_knP3fHFk3vN4LRN7EFCIpUvSk44un5KtT
> > BGf-4O9jlbZGI0ejeILvpghDZVQ$   |
> > 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |