NetBSD Problem Report #58009

From www@netbsd.org  Fri Mar  8 08:36:39 2024
Return-Path: <www@netbsd.org>
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 AF8421A923C
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  8 Mar 2024 08:36:39 +0000 (UTC)
Message-Id: <20240308083638.2947B1A923D@mollari.NetBSD.org>
Date: Fri,  8 Mar 2024 08:36:38 +0000 (UTC)
From: nia@mailfence.com
Reply-To: nia@mailfence.com
To: gnats-bugs@NetBSD.org
Subject: ffs_newvnode panic while untarring comp.tar.xz
X-Send-Pr-Version: www-1.0

>Number:         58009
>Category:       kern
>Synopsis:       ffs_newvnode panic while untarring comp.tar.xz
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 08 08:40:00 +0000 2024
>Last-Modified:  Sun Apr 21 00:20:01 +0000 2024
>Originator:     nia
>Release:        10.0_RC5
>Organization:
The NetBSD Foundation
>Environment:
NetBSD amnesia 10.0_RC5 NetBSD 10.0_RC5 (GENERIC) #0: Tue Feb 27 05:27:39 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd6
>Description:
file system was mounted with options rw,log,noatime

/encrypt: replaying log to disk
panic: ffs_newvnode: dup alloc ino=3623063 on /: mode 2005/2005 gen 0/0 size 0 blocks 0
cpu1: Begin traceback...
[ c() at netbsd:panic+0x3c
[ 137.6268827] ffs_newvnode() at netbsd:ffs_newvnode+0x572
vcache_new() at netbsd:vcache_new+0x97
ufs_makeinode() at netbsd:ufs_makeinode+0x3c
ufs_create() at netbsd:ufs_create+0x36
VOP_CREATE() at netbsd:VOP_CREATE+0x43

syscall() at netbsd:syscall+0x1fc
--- syscall (number 5) ---
netbsd:syscall+0x1fc:
cpu1: End traceback...

dumping to dev 168,2 (offset=1767, size=2059555):

>How-To-Repeat:

>Fix:
deleting /usr/share/man before untarring seemed to resolve ffs's problems

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/58009: ffs_newvnode panic while untarring comp.tar.xz
Date: Fri, 8 Mar 2024 10:25:07 -0000 (UTC)

 nia@mailfence.com writes:

 >panic: ffs_newvnode: dup alloc ino=3623063 on /: mode 2005/2005 gen 0/0 size 0 blocks 0

 First, that's a previously corrupted filesystem. Did you force fsck?
 Replaying the journal is unlikely to fix things.

From: Nia Alarie <nia@mailfence.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/58009: ffs_newvnode panic while untarring comp.tar.xz
Date: Fri, 8 Mar 2024 11:41:06 +0100

 On Fri, Mar 08, 2024 at 10:30:02AM +0000, Michael van Elst wrote:
 >  >panic: ffs_newvnode: dup alloc ino=3623063 on /: mode 2005/2005 gen 0/0 size 0 blocks 0
 >  
 >  First, that's a previously corrupted filesystem. Did you force fsck?
 >  Replaying the journal is unlikely to fix things.
 >  

 Yes, I forced a fsck and it declared everything clean.

 I also found an old mailing list post where someone
 suggested mounting with "sync" might help. However, it
 still led to the panic.

From: Taylor R Campbell <riastradh@NetBSD.org>
To: nia@mailfence.com
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/58009: ffs_newvnode panic while untarring comp.tar.xz
Date: Sat, 9 Mar 2024 03:22:48 +0000

 Do you have an image of the file system when it was panicking like
 this, or steps to reproduce?  Not sure we can do much with this report
 otherwise.

 When you forced fsck, was that with or without -p?  fsck -p may not
 detect everything (it's only supposed to detect possible intermediate
 states of compound file system updates), but maybe we should try to
 ensure that fsck without -p will at least detect any scenario that the
 kernel will panic on.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/58009: ffs_newvnode panic while untarring comp.tar.xz
Date: Sun, 21 Apr 2024 00:19:30 +0000

 On Fri, Mar 08, 2024 at 08:40:00AM +0000, nia@mailfence.com wrote:
  > /encrypt: replaying log to disk
  > panic: ffs_newvnode: dup alloc ino=3623063 on /: mode 2005/2005 gen 0/0 size 0 blocks 0

 ffsv1 or ffsv2?

 It is unlikely that PR 40525 has resurfaced, but something else like
 it may have happened.

 -- 
 David A. Holland
 dholland@netbsd.org

Home	PR Database Search