public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Tomas Alvarez Vanoli <tomas.alvarez-vanoli@hitachienergy.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [BUG] UBIFS corruption on powerpc 32-bit targets
Date: Thu, 5 Feb 2026 10:14:36 +0800	[thread overview]
Message-ID: <d0eb0572-e383-466e-7b4f-97e4a853b7c5@huawei.com> (raw)
In-Reply-To: <DB9PR06MB78498340513D9788FC7576FDC298A@DB9PR06MB7849.eurprd06.prod.outlook.com>

在 2026/2/4 22:04, Tomas Alvarez Vanoli 写道:
>> Try 'fsck.ubifs -g3 -y /dev/ubi0_1'.
> 
> I downloaded and cross-compiled mtd-utils for ppc, not sure if I had given
> some wrong param for configure but I was getting a segfault at
> ubifs-utils/fsck.ubifs/problem.c:236 (log_out in FILE_IS_INCONSISTENT).
> 
> This is the backtrace of the crash in case you are interested (otherwise skip
> ahead to the run that worked):
> 
> ```
> (gdb) bt
> #0 __GI_strlen () at ../sysdeps/powerpc/powerpc32/strlen.S:98
> #1 0x0f7ec038 in __printf_buffer (buf=buf@entry=0xbffff748,
> format=format@entry=0x1005bd38 "%s[%d] (%s%s): problem: %s, ino %lu type %s,
> nlink %u xcnt %u xsz %u xnms %u size %llu, should be nlink %u xcnt %u xsz %u
> xnms %u size %llu\n", ap=ap@entry=0xbffff838,
> mode_flags=mode_flags@entry=0) at vfprintf-process-arg.c:435
> #2 0x0f7ec608 in __vfprintf_internal (s=<optimized out>,
> format=0x1005bd38 "%s[%d] (%s%s): problem: %s, ino %lu type %s, nlink %u xcnt %u
> xsz %u xnms %u size %llu, should be nlink %u xcnt %u xsz %u xnms %u size %llu\n"
>   ap=ap@entry=0xbffff838,
> mode_flags=mode_flags@entry=0) at vfprintf-internal.c:1544
> #3 0x0f7e211c in __printf (format=<optimized out>) at printf.c:33
> #4 0x1003da80 in print_problem (priv=0xbffff970, problem_type=<optimized out>,
> problem=0x10060494 <problem_table+184>, c=0x1006d2e8 <info_>) at
> ubifs-utils/fsck.ubifs/problem.c:236
> #5 fix_problem (c=c@entry=0x1006d2e8 <info_>,
> problem_type=problem_type@entry=23,
> priv=priv@entry=0xbffff9f0) at ubifs-utils/fsck.ubifs/problem.c:354
> #6 0x1003f9dc in handle_invalid_file (priv=0x0, file=0x1011c890,
> problem_type=23, c=0x1006d2e8 <info_>)
> at ubifs-utils/fsck.ubifs/extract_files.c:844
> #7 correct_file_info (file=0x1011c890, c=0x1006d2e8 <info_>)
> at ubifs-utils/fsck.ubifs/extract_files.c:1496
> #8 correct_file_info (c=0x1006d2e8 <info_>, file=0x1011c890)
> at ubifs-utils/fsck.ubifs/extract_files.c:1473
> #9 0x100439dc in check_and_correct_files (c=c@entry=0x1006d2e8 <info_>)
> at ubifs-utils/fsck.ubifs/extract_files.c:1552
> #10 0x10005f94 in do_fsck () at ubifs-utils/fsck.ubifs/fsck.ubifs.c:490
> #11 main (argc=<optimized out>, argv=<optimized out>) at
> ubifs-utils/fsck.ubifs/fsck.ubifs.c:622
> (gdb)
> ```
> 

Thanks for pointing it out, Hayama has sent out the patches to fix it, 
see 
https://patchwork.ozlabs.org/project/linux-mtd/cover/9276ac09-7c7d-41df-9ee2-094f1c8edf93@lineo.co.jp/. 
It would be appreciate that if you could modify according to the 
suggestions and resend them.
> There's a warning about the formatter used for ino_t, used formatter is %lu but
> ino_t is long long unsigned int.
> 
> Anyway, I split the logs into one call per value and ran it, got the following
> (patched up the log into a single line again):
> 
> ```
> root@kmcent2:~# ./fsck.ubifs -y -g3 /dev/ubi1_0
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Read superblock
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Read master & init lpt
> <INFO> fsck.ubifs[182] (/dev/ubi1_0): ubifs_load_filesystem: recovery needed
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Replay journal
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Handle orphan nodes
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Recover isize
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Traverse TNC and construct files
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Check and handle invalid files
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): problem: File has no inode, ino 0
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Delete it? y

Looks like that there is only one problem, the inode cannot be found but 
the dentry(ne_config.xml.gz) still exists on flash. I guess the lost 
inode is 3917759 in previous log.
Maybe the inode is

UBIFS error (ubi1:0 pid 134): ubifs_iget: failed to read inode 3917759, 
error -2
UBIFS error (ubi1:0 pid 134): ubifs_lookup: dead directory entry 
'ne_config.xml.gz', error -2
UBIFS warning (ubi1:0 pid 134): ubifs_ro_mode: switched to read-only 
mode, error -2
find: /cfg/board/cfg/mob/backup/ne/ne_config.xml.gz: No such fiCPU: 1 
UID: 0 PID: 134 Comm: find Not tainted 6.12.57-00435-gf9e139970f1f #0

Apply following patch to kernel and mount bad ubifs image, let's try to 
find more information after a full volume scanning:
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index f453c37cee37..35d54e1a7ecd 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1491,6 +1491,89 @@ static int mount_ubifs(struct ubifs_info *c)
  	} else
  		ubifs_assert(c, c->lst.taken_empty_lebs > 0);

+	int lnum, len, ret, offs;
+	char *leb_buf, *buf;
+
+	leb_buf = vmalloc(c->leb_size);
+	if (!leb_buf)
+		return -ENOMEM;
+
+	for (lnum = c->main_first; lnum < c->leb_cnt; ++lnum) {
+	pr_info("---------- Start scan LEB %d (main_first %d) ----------\n", 
lnum, c->main_first);
+	ubifs_leb_read(c, lnum, leb_buf, 0, c->leb_size, 0);
+	//print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 32, 1, (void 
*)leb_buf, c->leb_size, 1);
+	len = c->leb_size;
+	buf = leb_buf;
+	offs = 0;
+
+	while (len >= 8) {
+		int found;
+		int node_len;
+		struct ubifs_ch *ch = (struct ubifs_ch *)buf;
+		struct ubifs_ino_node *ino;
+		struct ubifs_dent_node *dent;
+		struct ubifs_data_node *dn;
+		union ubifs_key key;
+
+		ret = ubifs_scan_a_node(c, buf, len, lnum, offs, 0);
+		if (ret > 0) {
+			pr_info("padding bytes %d:%d\n", offs, offs + ret);
+			offs += ret;
+			buf += ret;
+			len -= ret;
+			continue;
+		}
+		if (ret == SCANNED_EMPTY_SPACE) {
+			break;
+		} else if (ret != SCANNED_A_NODE) {
+			ubifs_err(c, "SCAN ret = %d", ret);
+			break;
+		}
+
+		node_len = ALIGN(le32_to_cpu(ch->len), 8);
+
+		switch (ch->node_type) {
+			case UBIFS_INO_NODE:
+				ino = (struct ubifs_ino_node *)buf;
+				key_read(c, &ino->key, &key);
+
+				found = ubifs_tnc_has_node(c, &key, 0, lnum, offs, 0);
+				pr_info("ino %u found %d %d-%d\n", key.u32[0], found, offs, offs + 
node_len);
+				break;
+			case UBIFS_DENT_NODE:
+				dent = (struct ubifs_dent_node *)buf;
+				key_read(c, &dent->key, &key);
+
+				found = ubifs_tnc_has_node(c, &key, 0, lnum, offs, 0);
+				pr_info("dent %llu(%s) found %d %d-%d\n", dent->inum, dent->name, 
found, offs, offs + node_len);
+				break;
+			case UBIFS_DATA_NODE:
+				dn = (struct ubifs_data_node *)buf;
+				key_read(c, &dn->key, &key);
+
+				found = ubifs_tnc_has_node(c, &key, 0, lnum, offs, 0);
+				pr_info("data %u found %d %d-%d\n", key.u32[0], found, offs, offs + 
node_len);
+				break;
+			default:
+				pr_info("unknown type %d\n", ch->node_type);
+				break;
+		}
+
+		offs += node_len;
+		buf += node_len;
+		len -= node_len;
+	}
+
+	for (; len > 4; offs += 4, buf += 4, len -= 4)
+		if (*(uint32_t *)buf != 0xffffffff)
+			break;
+	for (; len; offs++, buf++, len--)
+		if (*(uint8_t *)buf != 0xff)
+			ubifs_err(c, "corrupt empty space at LEB %d:%d", lnum, offs);
+	}
+
+	pr_info("============ FINISH ==========\n");
+
  	err = dbg_check_filesystem(c);
  	if (err)
  		goto out_infos;
> 
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Check and handle unreachable files
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Check and correct files
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): problem: File is inconsistent ino
> 184322 type dir nlink 2 xcnt 0 xsz 0 xnms 0 size 472, should be nlink 2 xcnt 0
> xsz 0 xnms 0 size 392
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Fix it? y
> 
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Check whether the TNC is empty
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Check and correct the space
> statistics
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Commit problem fixing modifications
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Check and correct the index size
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Check and create root dir
> fsck.ubifs[182] (/dev/ubi1_0,danger mode): Final committing
> fsck.ubifs[182] (-): ********** Filesystem was modified **********
> fsck.ubifs[182] (-): FSCK success!
> root@kmcent2:~#
> ```
> 
> Seems potentially the size of the node was wrong?
> After the run, the fs is, as expected, not broken anymore.
> 
> 
> PS: my email client might be omitting the in-reply-to headers, sorry about that
> 
> Best regards,
> Tomas
> 
> 
> .
> 


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

  reply	other threads:[~2026-02-05  2:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29 10:30 [BUG] UBIFS corruption on powerpc 32-bit targets Tomas Alvarez Vanoli
2026-01-30  1:34 ` Zhihao Cheng
2026-02-03  9:12   ` Tomas Alvarez Vanoli
2026-02-04  4:54     ` Zhihao Cheng
2026-02-04 14:04       ` Tomas Alvarez Vanoli
2026-02-05  2:14         ` Zhihao Cheng [this message]
2026-02-05 15:47           ` Tomas Alvarez Vanoli
2026-02-06  2:21             ` Zhihao Cheng
2026-02-06 16:14               ` Tomas Alvarez Vanoli
2026-02-07  2:58                 ` Zhihao Cheng
2026-02-09 15:45                   ` Tomas Alvarez Vanoli
2026-02-10  2:38                     ` Zhihao Cheng
2026-02-10 16:40                       ` Tomas Alvarez Vanoli
2026-02-11  6:58                         ` Zhihao Cheng
2026-02-11  7:01                           ` Zhihao Cheng
2026-02-11 16:51                             ` Tomas Alvarez Vanoli
2026-02-12  1:19                               ` Zhihao Cheng
2026-02-12 15:43                                 ` Tomas Alvarez Vanoli
2026-02-13  1:16                                   ` Zhihao Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d0eb0572-e383-466e-7b4f-97e4a853b7c5@huawei.com \
    --to=chengzhihao1@huawei.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tomas.alvarez-vanoli@hitachienergy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox