NetBSD Problem Report #56725

From cjep@berkeley.localdomain  Mon Feb 21 09:36:53 2022
Return-Path: <cjep@berkeley.localdomain>
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 110EB1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 21 Feb 2022 09:36:53 +0000 (UTC)
Message-Id: <20220221082047.CBC7D287AA7E@berkeley.localdomain>
Date: Mon, 21 Feb 2022 08:20:47 +0000 (UTC)
From: cjep@netbsd.org
Reply-To: cjep@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: Panic when ls directory with device nodes on an older ffs
X-Send-Pr-Version: 3.95

>Number:         56725
>Category:       kern
>Synopsis:       NetBSD current panics on ls in a directory with device nodes on older ffs format
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 21 09:40:00 +0000 2022
>Closed-Date:    Thu Feb 24 21:14:11 +0000 2022
>Last-Modified:  Thu Feb 24 21:14:11 +0000 2022
>Originator:     Chris Pinnock
>Release:        NetBSD 9.99.93
>Organization:
Very little
>Environment:
System: NetBSD berkeley 9.99.93 NetBSD 9.99.93 (BERKELEY) #21: Thu Dec 23 14:09:06 UTC 2021 cjep@berkeley:/home/cjep/src/NetBSD/current/src/sys/arch/amd64/compile/BERKELEY amd64
Architecture: x86_64
Machine: amd64
>Description:
On a very old FFS image mounted via a vnd, it is possible to panic 9.99.93 
by running ls on a directory containing device nodes. I cannot reproduce 
this on 9.2.

# vnconfig vnd0 inst-10.fs 
# mount /dev/vnd0d /mnt
[ 410.5390917] /dev/vnd0d: file system not clean (fs_clean=0); please fsck(8)
[ 410.5390917] /dev/vnd0d: lost blocks 0 files 0
# ls -l /mnt/dev

(Crashes after listing the tty devs)

[ 414.1587747] panic: kernel diagnostic assertion "vp->v_type != VLNK || ump->umvp->v_type != VLNK || ump->um_maxsymlinklen !=0 || DIP(ip, blocks) ufs_readwrite.c line 144
[ 414.1587747] cpu0: Begin traceback...
[ 414.1587747] vpanic() at netbsd:vpanic+0x156
[ 414.1587747] kern_assert() at netbsd:kern_assert+0x4b
[ 414.1688707] ffs_bufrd() at netbsd:ffs_bufrd+0x336
[ 414.1688707] VOP_READLINK() at netbsd:VOP_READLINK+0x40
[ 414.1688707] do_sys_readlinkat() at netbsd:do_sys_readlinkat+0x1b9
[ 414.1789647] syscall() at netbsd:syscall+0x196
[ 414.1789647] --- syscall (number 58) ---
[ 414.1789647] netbsd:syscall+0x196:
[ 414.1789647] cpu0: End traceback...

(I've recreated this on a QEmu VM as well has real hardware.)

Crash and core dumps here:
http://downloads.chrispinnock.com/crash/netbsd.0.core.gz
http://downloads.chrispinnock.com/crash/netbsd.0.gz

>How-To-Repeat:
- Get the install floppy image for 1.0 (yes weird - I'm working on a
nostalgic project).
- mount it and ls the dev directory.

ftp -a http://archive.netbsd.org/pub/NetBSD-archive/NetBSD-1.0/i386/floppies/inst-10.fs
vnconfig vnd0 inst-10.fs
mount /dev/vnd0d /mnt
ls -l /mnt/dev

>Fix:
not known but looks like a bug introduced since 9.2

>Release-Note:

>Audit-Trail:

From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56725 CVS commit: src/sys/ufs/ufs
Date: Mon, 21 Feb 2022 17:07:45 +0000

 Module Name:	src
 Committed By:	hannken
 Date:		Mon Feb 21 17:07:45 UTC 2022

 Modified Files:
 	src/sys/ufs/ufs: ufs_readwrite.c

 Log Message:
 Fix wrong assertion, the negatiopn of "a && b" is "!a || !b" so we
 need "DIP(ip, blocks) != 0" here.

 Should fix PR kern/56725 (Panic when ls directory with device nodes
 on an older ffs)


 To generate a diff of this commit:
 cvs rdiff -u -r1.127 -r1.128 src/sys/ufs/ufs/ufs_readwrite.c

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

State-Changed-From-To: open->closed
State-Changed-By: cjep@NetBSD.org
State-Changed-When: Thu, 24 Feb 2022 21:14:11 +0000
State-Changed-Why:
I've tested the patch with the disk image that caused the panic
and it appears to have fixed the specific issue in this PR.


>Unformatted:

Home	PR Database Search