Re: [BUG] UBIFS corruption on powerpc 32-bit targets

[Zhihao Cheng <chengzhihao1@huawei.com>]

在 2026/2/11 14:58, Zhihao Cheng 写道:
> 在 2026/2/11 0:40, Tomas Alvarez Vanoli 写道:
>>> Is the ubifs mounted in readonly mode in 4.14?
>>> If not, the do_kill_orphan process will be committed on flash.
>>
>> No, it is not read only.
>>
>>> The commit 3af2d3a8c56fe7dc24f60c4df0ab85b7ac941902("ubifs: Fix
>>> unattached inode when powercut happens in creating") [v6.11] is
>>> introduced between 6.1 and 6.12, which will add every inode into orphan
>>> area at the begining of creation.
>>
>> By creation you mean the first occurence of it or whenever there's an 
>> update?
>>
>> If I understand correctly, what you suggest is that it's possible that as
>> the new inode is added to orphan area and the board is reset and 
>> booted into the
>> older kernel, which then cleans all the orphans even if they have link 
>> count,
>> leaving the fs broken?
>>
>> So, in other words, my understanding of what you say is that for
>> 3af2d3a8c56fe7dc24f60c4df0ab85b7ac941902 to not break anything, any 
>> kernel that
>> mounts the same partition needs 
>> ee1438ce5dc4d67dd8dd1ff51583122a61f5bd9e and
>> 4ab25ac8b2b5514151d5f91cf9514df08dd26938 .
> 
> Correct.
>>
>>> So, you may try option  1 or 2 and check whether the problem could 
>>> happen:
>>> 1. mount 4.14 readonly
>>> 2. backport fix patches on 4.14
>>
>> Potentially also replacing the 4.14 application with an application 
>> based on
>> 6.1?
> 
> What does 'application' mean?
>>
>> I am also interested in consistently reproducing this at my desk. I 
>> have been
>> tinkering with adding a message + a 10 second delay at points in the 
>> ubifs code
>> so that I can reset the board and boot the old kernel to trigger this 
>> behaviour.
>> Would you know at which exact point/conditions it would make sense to 
>> add this?
>> Or is it not possible?
>> I do not fully understand your theory, I have read the docs for the fs 
>> but I
>> have little experience with filesystem implementation in general, so I 
>> am not
>> sure how feasible this "hack" is.
> 
> Apply following patch in 6.12:
> 
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 3c3d3ad4fa6c..3d2f0f6b9a07 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -302,6 +302,8 @@ static int ubifs_prepare_create(struct inode *dir, 
struct dentry *dentry,
  	return fscrypt_setup_filename(dir, &dentry->d_name, 0, nm);
  }

+#include <linux/delay.h>
+extern int g_wait;
  static int ubifs_create(struct mnt_idmap *idmap, struct inode *dir,
  			struct dentry *dentry, umode_t mode, bool excl)
  {
@@ -341,6 +343,13 @@ static int ubifs_create(struct mnt_idmap *idmap, 
struct inode *dir,
  	if (err)
  		goto out_inode;

+	pr_err("wait sync and write orphans\n");
+	while (!g_wait) {
+		smp_rmb();
+		msleep(10);
+	}
+	pr_err("wait done\n");
+
  	set_nlink(inode, 1);
  	mutex_lock(&dir_ui->ui_mutex);
  	dir->i_size += sz_change;
diff --git a/fs/ubifs/orphan.c b/fs/ubifs/orphan.c
index 5555dd740889..943c93e2f49d 100644
--- a/fs/ubifs/orphan.c
+++ b/fs/ubifs/orphan.c
@@ -284,6 +284,7 @@ static int do_write_orph_node(struct ubifs_info *c, 
int len, int atomic)
   * orphan head. On success, %0 is returned, otherwise a negative error 
code
   * is returned.
   */
+int g_wait = 0;
  static int write_orph_node(struct ubifs_info *c, int atomic)
  {
  	struct ubifs_orphan *orphan, *cnext;
@@ -318,6 +319,8 @@ static int write_orph_node(struct ubifs_info *c, int 
atomic)
  		orphan = cnext;
  		ubifs_assert(c, orphan->cmt);
  		orph->inos[i] = cpu_to_le64(orphan->inum);
+		pr_err("write orphan %lu\n", orphan->inum);
+		g_wait = 1;
  		orphan->cmt = 0;
  		cnext = orphan->cnext;
  		orphan->cnext = NULL;
> 
> Apply following patch in 4.14:
> 
diff --git a/fs/ubifs/orphan.c b/fs/ubifs/orphan.c
index 8f70494efb0c..f04a9609c753 100644
--- a/fs/ubifs/orphan.c
+++ b/fs/ubifs/orphan.c
@@ -614,6 +614,7 @@ static int do_kill_orphans(struct ubifs_info *c, 
struct ubifs_scan_leb *sleb,
  			inum = le64_to_cpu(orph->inos[i]);
  			dbg_rcvry("deleting orphaned inode %lu",
  				  (unsigned long)inum);
+			pr_err("remove ino %lu\n", inum);
  			err = ubifs_tnc_remove_ino(c, inum);
  			if (err)
  				return err;

> 
> Run:

My ubifs image is mkfs in 4.14.
> start kernel 6.12
> $ touch $MNT/file # cmd will stuck, $MNT is the ubifs mntpoint
> $ dmesg # you will see kernel message 'wait sync and write orphans', 
> open another terminal
> $ sync # open another terminal, you will see kernel message 'write 
> orphan XX', and the 'touch' cmd goes on
> $ dd if=/dev/mtd0 of=flash bs=1M
> $ sync and poweroff
> 
> start kernel 4.14
> $ flash_eraseall /dev/mtd0
> $ dd if=flash of=/dev/mtd0 bs=1M # make sure mtd0 is not attached by ubi
> $ ubiattach -m0
> $ mount /dev/ubi0_0 temp # dmesg will show 'remove ino XX'
> $ ls temp
> ls: cannot access 'temp/file': No such file or directory
> file
> $ dmesg
> [   69.200639] UBIFS error (ubi0:0 pid 1587): ubifs_iget [ubifs]: failed 
> to read inode 65, error -2
> [   69.206214] UBIFS error (ubi0:0 pid 1587): ubifs_lookup [ubifs]: dead 
> directory entry 'file', error -2
> [   69.207482] UBIFS warning (ubi0:0 pid 1587): ubifs_ro_mode [ubifs]: 
> switched to read-only mode, error -2
> [   69.208783] CPU: 2 PID: 1587 Comm: ls Not tainted 
> 4.19.90-00006-g332043630ae1-dirty #50
> [   69.209837] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 
> 04/01/2014
> [   69.211545] Call Trace:
> [   69.211921]  dump_stack+0xb8/0xef
> [   69.212370]  ubifs_ro_mode+0x54/0x60 [ubifs]
> [   69.212950]  ubifs_lookup+0x3b6/0x550 [ubifs]
> [   69.213535]  __lookup_slow+0x9e/0x210
> [   69.214045]  lookup_slow+0x46/0x70
> [   69.214491]  walk_component+0x265/0x4c0
> [   69.215013]  path_lookupat.isra.0+0x9e/0x360
> [   69.215588]  filename_lookup+0xb5/0x230
> [   69.216107]  ? _raw_spin_unlock_irqrestore+0x3f/0x80
> [   69.216769]  ? __this_cpu_preempt_check+0x17/0x20
> [   69.217386]  ? __local_bh_enable_ip+0x62/0x110
> [   69.218038]  ? _raw_spin_unlock_bh+0x2e/0x40
> [   69.218761]  ? wb_wakeup_delayed+0x56/0x90
> [   69.219301]  ? kmem_cache_alloc+0x110/0x3d0
> [   69.219852]  user_path_at_empty+0x43/0x60
> [   69.220391]  vfs_statx+0x90/0x150
> [   69.220847]  ? __sb_end_write+0x5f/0xb0
> [   69.221354]  __se_sys_newlstat+0x46/0xa0
> [   69.221892]  ? __se_sys_getdents+0xe0/0x1c0
> [   69.222465]  ? filldir64+0x340/0x340
> [   69.222958]  __x64_sys_newlstat+0x1a/0x30
> [   69.223499]  do_syscall_64+0x95/0x460
> [   69.224004]  ? prepare_exit_to_usermode+0xaa/0x180
> [   69.224652]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1
> 
>>
>> Thanks for all your support!
>> Best regards,
>> Tomas
>> .
>>
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/