NetBSD Problem Report #52380

From www@NetBSD.org  Sun Jul  9 09:15:41 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id BA1967A265
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  9 Jul 2017 09:15:41 +0000 (UTC)
Message-Id: <20170709091540.77C197A2A6@mollari.NetBSD.org>
Date: Sun,  9 Jul 2017 09:15:40 +0000 (UTC)
From: joel.bertrand@systella.fr
Reply-To: joel.bertrand@systella.fr
To: gnats-bugs@NetBSD.org
Subject: [NetBSD 8.0] Another panic in ffs_newvnode()
X-Send-Pr-Version: www-1.0

>Number:         52380
>Category:       kern
>Synopsis:       [NetBSD 8.0] Another panic in ffs_newvnode()
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 09 09:20:00 +0000 2017
>Last-Modified:  Wed May 29 16:00:05 +0000 2019
>Originator:     BERTRAND Joël
>Release:        8.0 BETA
>Organization:
>Environment:
NetBSD legendre.systella.fr 8.0_BETA NetBSD 8.0_BETA (CUSTOM) #4: Fri Jul  7 22:39:32 CEST 2017  root@legendre.systella.fr:/usr/src/netbsd-8/obj/sys/arch/amd64/compile/CUSTOM amd64
>Description:
    Hello,

    Yesterfay, my server running NetBSD 8.0 (built from sources this morning) has paniced :

legendre# crash -M netbsd.4.core -N netbsd.4
Crash version 8.0_BETA, image version 8.0_BETA.
System panicked: ffs_newvnode: dup alloc ino=1109312 on /usr: mode 2f20/2f20 gen 65642f6a/65642f6a size 726964747365642f blocks 752f3436646d612e
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
?() at fffffe84075c4000
vpanic() at vpanic+0x149
snprintf() at snprintf
ffs_newvnode() at ffs_newvnode+0x530
vcache_new() at vcache_new+0x7c
ufs_makeinode() at ufs_makeinode+0x38
ufs_create() at ufs_create+0x31
VOP_CREATE() at VOP_CREATE+0x38
vn_open() at vn_open+0x351
do_open() at do_open+0x112
do_sys_openat() at do_sys_openat+0x68
sys_open() at sys_open+0x24
syscall() at syscall+0x1bc
--- syscall (number 5) ---
7f2ccc03e07a:

gdb gives following backtrace :
#0  0xffffffff802292e5 in cpu_reboot (howto=howto@entry=260,
    bootstr=bootstr@entry=0x0)
    at /usr/src/netbsd-8/src/sys/arch/amd64/amd64/machdep.c:674
#1  0xffffffff8094b121 in vpanic (
    fmt=fmt@entry=0xffffffff8115d870 "%s: dup alloc ino=%ld on %s: mode %x/%x gen %x/%x size %lx blocks %lx", ap=ap@entry=0xfffffe811e5b29c8)
    at /usr/src/netbsd-8/src/sys/kern/subr_prf.c:342
#2  0xffffffff8094b1d5 in panic (
    fmt=fmt@entry=0xffffffff8115d870 "%s: dup alloc ino=%ld on %s: mode %x/%x gen %x/%x size %lx blocks %lx") at /usr/src/netbsd-8/src/sys/kern/subr_prf.c:258
#3  0xffffffff808a773b in ffs_newvnode (mp=0xfffffe841b078000,
    dvp=0xfffffe81687fbbd0, vp=0xfffffe81fe181698, vap=0xfffffe811e5b2c30,
    cred=0xfffffe84075c4000, key_len=<optimized out>,
    new_key=0xfffffe81fe1817d8)
    at /usr/src/netbsd-8/src/sys/ufs/ffs/ffs_vfsops.c:2135
#4  0xffffffff809965b6 in vcache_new (mp=0xfffffe841b078000,
    dvp=dvp@entry=0xfffffe81687fbbd0, vap=vap@entry=0xfffffe811e5b2c30,
    cred=0xfffffe84075c4000, vpp=vpp@entry=0xfffffe811e5b2b48)
    at /usr/src/netbsd-8/src/sys/kern/vfs_vnode.c:1375
#5  0xffffffff808d8518 in ufs_makeinode (vap=0xfffffe811e5b2c30,
    dvp=dvp@entry=0xfffffe81687fbbd0, ulr=0xfffffe815aa29088,
    vpp=0xfffffe811e5b2d80, cnp=0xfffffe811e5b2da8)
    at /usr/src/netbsd-8/src/sys/ufs/ufs/ufs_vnops.c:1739
#6  0xffffffff808d87fa in ufs_create (v=0xfffffe811e5b2bc8)
    at /usr/src/netbsd-8/src/sys/ufs/ufs/ufs_vnops.c:156
#7  0xffffffff8099d5d2 in VOP_CREATE (dvp=0xfffffe81687fbbd0,
    vpp=vpp@entry=0xfffffe811e5b2d80, cnp=cnp@entry=0xfffffe811e5b2da8,
    vap=vap@entry=0xfffffe811e5b2c30)
    at /usr/src/netbsd-8/src/sys/kern/vnode_if.c:216
#8  0xffffffff80997f1c in vn_open (ndp=ndp@entry=0xfffffe811e5b2d58,
    fmode=fmode@entry=4196866, cmode=cmode@entry=420)
    at /usr/src/netbsd-8/src/sys/kern/vfs_vnops.c:211
#9  0xffffffff80990254 in do_open (l=l@entry=0xfffffe83df1594e0, dvp=0x0,
    pb=<optimized out>, open_flags=open_flags@entry=4196865,
    open_mode=open_mode@entry=420, fd=fd@entry=0xfffffe811e5b2e7c)
    at /usr/src/netbsd-8/src/sys/kern/vfs_syscalls.c:1576
#10 0xffffffff809903a5 in do_sys_openat (l=0xfffffe83df1594e0,
    fdat=fdat@entry=-100, path=<optimized out>, flags=4196865, mode=420,
    fd=fd@entry=0xfffffe811e5b2e7c)
    at /usr/src/netbsd-8/src/sys/kern/vfs_syscalls.c:1656
#11 0xffffffff80990463 in sys_open (l=<optimized out>, uap=<optimized out>,
    retval=0xfffffe811e5b2eb0)
    at /usr/src/netbsd-8/src/sys/kern/vfs_syscalls.c:1676
#12 0xffffffff8024aaec in sy_call (rval=0xfffffe811e5b2eb0,
    uap=0xfffffe811e5b2f00, l=0xfffffe83df1594e0,
    sy=0xffffffff8147dad8 <sysent+120>)

ffs_newvnode() seems to panic on /usr

My /etc/fstab is :
/dev/raid0a             /       ffs     rw,log,async    1 1
/dev/raid0b             none    swap    sw,dp           0 0
/dev/raid0e             /usr    ffs     rw,log,async    1 2
/dev/raid0f             /var    ffs     rw,log,async    1 2
/dev/raid0g             /usr/src        ffs     rw,log,async    1 2
/dev/raid0h             /srv    ffs     rw,log,async    1 2
/dev/dk0                /home   ffs     rw,log,async    1 3
kernfs          /kern   kernfs  rw
ptyfs           /dev/pts        ptyfs   rw
procfs          /proc   procfs  rw
/dev/cd0a               /cdrom  cd9660  ro,noauto
tmpfs           /var/shm        tmpfs   rw,-m1777,-sram%25

raid0 : /dev/wd[01] (raid level 1) -> raid0[abefgh]
raid1 : /dev/wd[234] (raid level 5) -> dk0

    Of course, I have checked that my disks were not faulty (no error logged in disk firmware). fsck doesn't return error also.

    Best regards,

    JKB 
>How-To-Repeat:
I don't know, panic occurs when I build packages from pkgsrc, but kernel seems to complain about another filesystem (/usr/pkgsrc and /usr are on different slices).
>Fix:

>Audit-Trail:
From: "Frank Kardel" <kardel@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52380 CVS commit: src/sys/ufs/ffs
Date: Sun, 14 Apr 2019 15:55:24 +0000

 Module Name:	src
 Committed By:	kardel
 Date:		Sun Apr 14 15:55:24 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs: ffs_alloc.c

 Log Message:
 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
    a) less than
         #_of_initialized_inodes(cg->cg_initediblk)
         - inodes_per_filesystem_block
       are allocated in the cylinder group
    b) cg->cg_irotor points to a uninterupted run of
       allocated inodes in the inode bitmap up to the
       end of dynamically initialized inodes
       (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.
 Further conditions to occur after the above:
    c) no panic
    d) no (forced) fsck
    e) and more than cg->cg_initediblk - inodes_per_filesystem_block
       allocated inodes.

 Fix:
 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.163 -r1.164 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52380 CVS commit: [netbsd-8] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:51:40 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:51:40 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-8]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1272):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.156.6.1 -r1.156.6.2 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52380 CVS commit: [netbsd-7] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:53:31 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:53:31 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-7]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1697):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.146.2.1 -r1.146.2.2 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52380 CVS commit: [netbsd-7-1] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:54:31 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:54:31 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-7-1]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1697):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.146.2.1 -r1.146.2.1.6.1 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52380 CVS commit: [netbsd-7-0] src/sys/ufs/ffs
Date: Wed, 29 May 2019 15:55:18 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 29 15:55:18 UTC 2019

 Modified Files:
 	src/sys/ufs/ffs [netbsd-7-0]: ffs_alloc.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1697):

 	sys/ufs/ffs/ffs_alloc.c: revision 1.164

 PR/53990, PR/52380, PR/52102: UFS2 cylinder group inode allocation botch

 Fix rare allocation botch in ffs_nodealloccg().

 Conditions:
     a) less than
          #_of_initialized_inodes(cg->cg_initediblk)
          - inodes_per_filesystem_block
        are allocated in the cylinder group
     b) cg->cg_irotor points to a uninterupted run of
        allocated inodes in the inode bitmap up to the
        end of dynamically initialized inodes
        (cg->cg_initediblk)

 In this case the next inode after this run was returned
 without initializing the respective inode block. As the
 block is not initialized these inodes could trigger panics
 on inode consistency due to old (uninitialized) disk data.

 In very rare cases data loss could occur when
 the uninitialized inode block is initialized via the
 normal mechanism.

 Further conditions to occur after the above:
     c) no panic
     d) no (forced) fsck
     e) and more than cg->cg_initediblk - inodes_per_filesystem_block
        allocated inodes.

 Fix:

 Always insure allocation always in initialized inode range
 extending the initialized inode range as needed.

 Add KASSERTMSG() safeguards.

 ok hannken@


 To generate a diff of this commit:
 cvs rdiff -u -r1.146.2.1 -r1.146.2.1.2.1 src/sys/ufs/ffs/ffs_alloc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.