NetBSD Problem Report #57118

From ocb@l25.fi  Sun Dec 18 13:43:20 2022
Return-Path: <ocb@l25.fi>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id ACDC51A921F
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 18 Dec 2022 13:43:20 +0000 (UTC)
Message-Id: <20221218133936.EDCAB2C0E3E@r.l25.fi>
Date: Sun, 18 Dec 2022 14:39:36 +0100 (CET)
From: ocb@l25.fi
Reply-To: ocb@l25.fi
To: gnats-bugs@NetBSD.org
Subject: panic on invalid dir inode  
X-Send-Pr-Version: 3.95

>Number:         57118
>Category:       port-amd64
>Synopsis:       kernel panics when accessing corrupted directory with invalid inode
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 18 13:45:00 +0000 2022
>Last-Modified:  Sun Dec 18 14:00:02 +0000 2022
>Originator:     ocb@l25.fi
>Release:        NetBSD 9.3
>Organization:

>Environment:


System: NetBSD system 9.3 NetBSD 9.3 (KERNEL1) #1: Sun Oct 29 16:52:03 CEST 2022 build@dc:/usr/kernel/obj/sys/arch/amd64/compile/KERNEL1 amd64
Architecture: x86_64
Machine: amd64
>Description:
	kernel panicked while transferring files and directories from corrupted disk (9.9.100 FFSv2) to a new healthy disk (9.3 FFSv2). transfer was done from live netbsd 9.9.100 running in memory. after first dump, rebooted to new healthy disk installation and trying to access the directory that was copied from corrupted disk with cd(1) or ls(1) will also panic. retested about 7 times to verify, happened until running fsck on the new disk that successfully removed directory in question. since 9.9.100 live image also panicked, the problem also exists on current branch, however the traceback below is from a 9.3 if i remember correctly.

Please understand i do not have a saved system state to easily test, but if needed have some ideas on recreating conditions in test environment.

MD5 (ffs.tar.gz.lrz) = 03abe1e0436042ca0e99600a39a71258 -- http://r.l25.fi/dump/ffs.tar.gz.lrz

[   826.436685] panic: /altroot/home: bad dir ino 6961280 at offset 0: null entry
[   826.436685] cpu2: Begin traceback...

[   826.436685] vpanic() at netbsd:vpanic+0x160
[   826.436685] snprintf() at netbsd:snprintf
[   826.436685] ufs_lookup() at netbsd:ufs_lookup+0x5b7
[   826.446693] VOP_LOOKUP() at netbsd:VOP_LOOKUP+0x4d
[   826.446693] lookup_once() at netbsd:lookup_once+0x18b
[   826.446693] namei_tryemulroot() at netbsd:namei_tryemulroot+0x307
[   826.456700] namei() at netbsd:namei+0x41
[   826.456700] fd_nameiat.isra.2() at netbsd:fd_nameiat.isra.2+0x54
[   826.456700] do_sys_statat() at netbsd:do_sys_statat+0x77
[   826.466707] sys___lstat50() at netbsd:sys___lstat50+0x25
[   826.466707] syscall() at netbsd:syscall+0x157
[   826.466707] --- syscall (number 441) ---
[   826.466707] 7e0699d6286a:
[   826.466707] cpu2: End traceback...
[   826.466707] fatal breakpoint trap in supervisor mode
[   826.466707] trap type 1 code 0 rip 0xffffffff8021dd15 cs 0x8 rflags 0x202 cr2 0x7e067178ea40 ilevel 0 rsp 0xffffc10255fe2a00
[   826.466707] curlwp 0xfffffdf88ebc1a20 pid 4351.1 lowest kstack 0xffffc10255fe02c0

[   826.466707] dumping to dev 20,1 (offset=8, size=8277706):
[   826.466707] dump


0xffffffff802229ea in cpu_reboot (howto=howto@entry=256, bootstr=bootstr@entry=0x0) at /home/build/usr/src/sys/arch/amd64/amd64/machdep.c:728
728     /home/build/usr/src/sys/arch/amd64/amd64/machdep.c: No such file or directory.
#0  0xffffffff802229ea in cpu_reboot (howto=howto@entry=256, bootstr=bootstr@entry=0x0) at /home/build/usr/src/sys/arch/amd64/amd64/machdep.c:728
#1  0xffffffff8076f228 in db_sync_cmd (addr=<optimized out>, have_addr=<optimized out>, count=<optimized out>, modif=<optimized out>) at /home/build/usr/src/sys/ddb/db_command.c:1435
#2  0xffffffff8076fab4 in db_command (last_cmdp=last_cmdp@entry=0xffffc10255fe2658) at /home/build/usr/src/sys/ddb/db_command.c:933
#3  0xffffffff8076fe3d in db_execute_commandlist (cmdlist=0xffffffff81445c80 <db_cmd_on_enter> "\"bt;sync\"") at /home/build/usr/src/sys/ddb/db_command.c:430
#4  db_command_loop () at /home/build/usr/src/sys/ddb/db_command.c:582
#5  0xffffffff80773805 in db_trap (type=type@entry=1, code=code@entry=0) at /home/build/usr/src/sys/ddb/db_trap.c:91
#6  0xffffffff8021f3f5 in kdb_trap (type=type@entry=1, code=code@entry=0, regs=regs@entry=0xffffc10255fe2910) at /home/build/usr/src/sys/arch/amd64/amd64/db_interface.c:247
#7  0xffffffff8022428d in trap (frame=0xffffc10255fe2910) at /home/build/usr/src/sys/arch/amd64/amd64/trap.c:323
#8  0xffffffff8021d56b in alltraps ()
#9  0xffffffff8021dd15 in breakpoint ()
#10 0xffffffff8099983d in vpanic (fmt=0xffffffff811a63f8 "%s: bad dir ino %ju at offset %d: %s\n", ap=ap@entry=0xffffc10255fe2a48) at /home/build/usr/src/sys/kern/subr_prf.c:334
#11 0xffffffff809998f7 in panic (fmt=<optimized out>) at /home/build/usr/src/sys/kern/subr_prf.c:255
#12 0xffffffff80916d39 in ufs_dirbad (how=<optimized out>, offset=<optimized out>, ip=0xfffffdff172e3d00) at /home/build/usr/src/sys/ufs/ufs/ufs_lookup.c:705
#13 ufs_lookup (v=<optimized out>) at /home/build/usr/src/sys/ufs/ufs/ufs_lookup.c:492
#14 0xffffffff809f2ef4 in VOP_LOOKUP (dvp=dvp@entry=0xfffffdff1821dd60, vpp=vpp@entry=0xffffc10255fe2c18, cnp=cnp@entry=0xffffc10255fe2e88) at /home/build/usr/src/sys/kern/vnode_if.c:177
#15 0xffffffff809daa9b in lookup_once (state=state@entry=0xffffc10255fe2db0, searchdir=0xfffffdff1821dd60, newsearchdir_ret=newsearchdir_ret@entry=0xffffc10255fe2cf8, foundobj_ret=foundobj_ret@entry=0xffffc10255fe2d00)
    at /home/build/usr/src/sys/kern/vfs_lookup.c:1021
#16 0xffffffff809db2f2 in namei_oneroot (isnfsd=<optimized out>, inhibitmagic=<optimized out>, neverfollow=<optimized out>, state=<optimized out>) at /home/build/usr/src/sys/kern/vfs_lookup.c:1260
#17 namei_tryemulroot (state=state@entry=0xffffc10255fe2db0, neverfollow=neverfollow@entry=0, inhibitmagic=inhibitmagic@entry=0, isnfsd=isnfsd@entry=0) at /home/build/usr/src/sys/kern/vfs_lookup.c:1565
#18 0xffffffff809dd251 in namei (ndp=ndp@entry=0xffffc10255fe2e38) at /home/build/usr/src/sys/kern/vfs_lookup.c:1601
#19 0xffffffff809e3097 in fd_nameiat (fdat=fdat@entry=-100, ndp=ndp@entry=0xffffc10255fe2e38, l=<optimized out>) at /home/build/usr/src/sys/kern/vfs_syscalls.c:181
#20 0xffffffff809e75c7 in do_sys_statat (l=<optimized out>, fdat=fdat@entry=-100, userpath=<optimized out>, nd_flag=nd_flag@entry=0, sb=sb@entry=0xffffc10255fe2ee8) at /home/build/usr/src/sys/kern/vfs_syscalls.c:3078
#21 0xffffffff809e7695 in sys___lstat50 (l=<optimized out>, uap=0xffffc10255fe3000, retval=<optimized out>) at /home/build/usr/src/sys/kern/vfs_syscalls.c:3123
#22 0xffffffff8024c3e7 in sy_call (rval=0xffffc10255fe2fb0, uap=0xffffc10255fe3000, l=0xfffffdf88ebc1a20, sy=0xffffffff8145b7d8 <sysent+10584>) at /home/build/usr/src/sys/sys/syscallvar.h:65
#23 sy_invoke (code=441, rval=0xffffc10255fe2fb0, uap=0xffffc10255fe3000, l=0xfffffdf88ebc1a20, sy=0xffffffff8145b7d8 <sysent+10584>) at /home/build/usr/src/sys/sys/syscallvar.h:94
#24 syscall (frame=0xffffc10255fe3000) at /home/build/usr/src/sys/arch/x86/x86/syscall.c:138
#25 0xffffffff802096dd in handle_syscall ()
723     in /home/build/usr/src/sys/arch/amd64/amd64/machdep.c
>How-To-Repeat:

>Fix:


>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/57118: panic on invalid dir inode 
Date: Sun, 18 Dec 2022 13:55:48 -0000 (UTC)

 ocb@l25.fi writes:

 >[   826.436685] panic: /altroot/home: bad dir ino 6961280 at offset 0: null entry


 ffs never handled a corrupt filesystem gracefully. But a successful
 fsck (maybe forced to ignore the clean flag) should always repair
 the filesystem enough to prevent such panics.

>Unformatted:

Home	PR Database Search