NetBSD Problem Report #44504

From campbell@mumble.net  Wed Feb  2 21:58:54 2011
Return-Path: <campbell@mumble.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 778E463B873
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  2 Feb 2011 21:58:54 +0000 (UTC)
Message-Id: <20110202215821.3C2B698298@pluto.mumble.net>
Date: Wed,  2 Feb 2011 21:58:21 +0000 (UTC)
From: Taylor R Campbell <campbell+netbsd@mumble.net>
Reply-To: Taylor R Campbell <campbell+netbsd@mumble.net>
To: gnats-bugs@gnats.NetBSD.org
Subject: kernel panics when dding some block sizes to USB flash drives at sd0
X-Send-Pr-Version: 3.95

>Number:         44504
>Category:       kern
>Synopsis:       kernel panics when dding some block sizes to USB flash drives at sd0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 02 22:00:01 +0000 2011
>Closed-Date:    Sat Jul 10 05:40:04 +0000 2021
>Last-Modified:  Sat Jul 10 05:40:04 +0000 2021
>Originator:     Taylor R Campbell <campbell+netbsd@mumble.net>
>Release:        NetBSD 5.1_STABLE
>Organization:
>Environment:
System: NetBSD smalltalk.local 5.1_STABLE NetBSD 5.1_STABLE (RIADEBUG) #0: Tue Feb 1 20:28:45 UTC 2011 root@smalltalk.local:/home/riastradh/netbsd/5/obj/sys/arch/i386/compile/RIADEBUG i386
Architecture: i386
Machine: i386
>Description:

	In multi-user mode on a kernel with DIAGNOSTIC and a few other
	options enabled, I can reliably make the kernel panic by dding
	what appear to be blocks of certain sizes to sd0d, where sd0 is
	some USB flash drive.  I haven't been able to reproduce it in
	single-user mode, and I haven't been able to reproduce it in
	HEAD.

	dmesg output for one of the flash drives I tested:

umass0 at uhub3 port 3 configuration 1 interface 0
umass0: Corsair Flash Voyager, rev 2.00/11.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <Corsair, Flash Voyager, 1100> disk removable
sd0: 1936 MB, 3936 cyl, 16 head, 63 sec, 512 bytes/sect x 3964928 sectors

	Kernel configuration:

include "arch/i386/conf/GENERIC"
options 	DIAGNOSTIC	# expensive kernel consistency checks
options 	DEBUG		# expensive debugging checks/support
options 	LOCKDEBUG	# debug locks
makeoptions 	DEBUG="-g"	# compile full symbol table
options 	FFS_EI		# FFS Endian Independent support
options 	APPLE_UFS	# Apple UFS support in FFS

	Panic message:

panic: kernel diagnostic assertion "LIST_EMPTY(&vp->v_dirtyblkhd)" failed: file "/home/riastradh/netbsd/5/src/sys/kern/vfs_subr.c", line 895
Begin traceback...
uvm_fault(0xcaa5d27c, 0, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c05ce021 cs 8 eflags 10246 cr2 37f ilevel 0
panic: trap
Faulted in mid-traceback; aborting...
dumping to dev 0,1 offset 1049975
dump succeeded

	Stack trace from gdb:

% gdb ./netbsd.gdb
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
(gdb) target kvm /var/crash/netbsd.5.core
#0  0xc05d2f52 in cpu_reboot (howto=260, bootstr=0x0)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/machdep.c:924
924                     dumpsys();
(gdb) bt
#0  0xc05d2f52 in cpu_reboot (howto=260, bootstr=0x0)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/machdep.c:924
#1  0xc0502c90 in panic (fmt=0xc0ae24c3 "trap")
    at /home/riastradh/netbsd/5/src/sys/kern/subr_prf.c:253
#2  0xc05d5f07 in trap (frame=0xcc0ee9b4)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/trap.c:368
#3  0xc010ccd7 in calltrap ()
#4  0xc05ce021 in db_read_bytes (addr=895, size=4, 
    data=0xcc0eea24 "\024�\016�\004")
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/db_memrw.c:91
#5  0xc01b9147 in db_get_value (addr=895, size=4, is_signed=false)
    at /home/riastradh/netbsd/5/src/sys/ddb/db_access.c:62
#6  0xc05ce8a4 in db_stack_trace_print (addr=-871437548, have_addr=true, 
    count=65535, modif=0xc0b1a1fc "", pr=0xc0502a70 <printf>)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/db_trace.c:485
#7  0xc0502c65 in panic (
    fmt=0xc0b27c74 "kernel %sassertion \"%s\" failed: file \"%s\", line %d")
    at /home/riastradh/netbsd/5/src/sys/kern/subr_prf.c:242
#8  0xc086dd89 in __kernassert (t=0xc0a85161 "diagnostic ", 
    f=0xc0ad6cfc "/home/riastradh/netbsd/5/src/sys/kern/vfs_subr.c", l=895, 
    e=0xc0ad650d "LIST_EMPTY(&vp->v_dirtyblkhd)")
    at /home/riastradh/netbsd/5/src/sys/lib/libkern/__assert.c:50
#9  0xc0545571 in vinvalbuf (vp=0xcbe6f230, flags=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    cred=0xcc304480, l=0xcc19e780, catch=false, slptimeo=0)
    at /home/riastradh/netbsd/5/src/sys/kern/vfs_subr.c:895
#10 0xc055edcd in spec_close (v=0xcc0eebd8)
    at /home/riastradh/netbsd/5/src/sys/miscfs/specfs/spec_vnops.c:935
#11 0xc05578dc in VOP_CLOSE (vp=0xcbe6f230, fflag=3, cred=0xcc304480)
    at /home/riastradh/netbsd/5/src/sys/kern/vnode_if.c:314
#12 0xc054f87e in vn_close (vp=0xcbe6f230, flags=3, cred=0xcc304480)
    at /home/riastradh/netbsd/5/src/sys/kern/vfs_vnops.c:352
#13 0xc054f8c2 in vn_closefile (fp=0xcc305c00)
    at /home/riastradh/netbsd/5/src/sys/kern/vfs_vnops.c:782
#14 0xc04bbd3d in closef (fp=0xcc305c00)
    at /home/riastradh/netbsd/5/src/sys/kern/kern_descrip.c:755
#15 0xc04bbf01 in fd_close (fd=4)
    at /home/riastradh/netbsd/5/src/sys/kern/kern_descrip.c:646
#16 0xc05d57c8 in syscall (frame=0xcc0eed48)
    at /home/riastradh/netbsd/5/src/sys/sys/syscallvar.h:49
#17 0xc010058e in syscall1 ()

>How-To-Repeat:

	Plug in a USB flash drive; assume it attaches at sd0.  The
	following all trigger the panic for me:

		# dd if=/dev/zero of=/dev/sd0d bs=123 count=1
		# dd if=/dev/zero of=/dev/sd0d bs=511 count=1
		# dd if=/dev/zero of=/dev/sd0d bs=512 count=1
		# dd if=/dev/zero of=/dev/sd0d bs=1k count=1
		# dd if=/dev/zero of=/dev/sd0d bs=2k count=1

	If F is a file whose size is not an even multiple of 4k, then

		# dd if=F of=/dev/sd0d

	also triggers the panic.

	A block size of 4k does not seem to trigger it; nor does using
	rsd0d.  Specifying a block size that is not a multiple of 512
	with rsd0d fails with EINVAL, but a block size of 512 works,
	even though 512 on sd0d triggers the panic.

>Fix:

	Yes, please!

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44504: kernel panics when dding some block sizes to USB
 flash drives at sd0
Date: Mon, 7 Feb 2011 08:02:23 +0000

 On Wed, Feb 02, 2011 at 10:00:01PM +0000, Taylor R Campbell wrote:
  > 	If F is a file whose size is not an even multiple of 4k, then
  > 
  > 		# dd if=F of=/dev/sd0d
  > 
  > 	also triggers the panic.
  > 
  > 	A block size of 4k does not seem to trigger it; nor does using
  > 	rsd0d.  Specifying a block size that is not a multiple of 512
  > 	with rsd0d fails with EINVAL, but a block size of 512 works,
  > 	even though 512 on sd0d triggers the panic.

 At least part of the answer with sd0d (rather than rsd0d) is "don't do
 that". Sending data through the metadata cache is not recommended.

 That said, it shouldn't panic. I'm surprised it allows unaligned
 writes at all; I'm guessing that attempting them is generating
 odd-sized buffers that aren't getting written out properly. Or
 something like that.

 Arguably this pathway into the metadata cache shouldn't exist; it's an
 artifact of the way the unified buffer cache was integrated.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/44504: kernel panics when dding some block sizes to USBflash
	 drives at sd0
Date: Mon, 7 Feb 2011 22:24:02 +0900

 5.1 Install Notes says in "Known Problems" section:

 >> Using block device nodes (e.g., wd0a) directly for I/O may cause
 >> a kernel crash when the file system containing /dev is FFS and
 >> is mounted with -o log.
 >> Workaround: use raw disk devices (e.g., rwd0a), or remount
 >> the file system without -o log. 

 ---
 Izumi Tsutsui

From: Taylor R Campbell <campbell@mumble.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, Taylor R Campbell <campbell+netbsd@mumble.net>
Subject: Re: kern/44504: kernel panics when dding some block sizes to USBflash
	drives at sd0
Date: Tue, 8 Feb 2011 01:09:43 +0000

    Date: Mon,  7 Feb 2011 13:25:02 +0000 (UTC)
    From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>

    5.1 Install Notes says in "Known Problems" section:

    >> Using block device nodes (e.g., wd0a) directly for I/O may cause
    >> a kernel crash when the file system containing /dev is FFS and
    >> is mounted with -o log.
    >> Workaround: use raw disk devices (e.g., rwd0a), or remount
    >> the file system without -o log. 

 Well, I guess that's it.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44504: kernel panics when dding some block sizes to
 USBflash drives at sd0
Date: Wed, 9 Feb 2011 05:19:39 +0000

 On Tue, Feb 08, 2011 at 01:10:06AM +0000, Taylor R Campbell wrote:
  >     5.1 Install Notes says in "Known Problems" section:
  >  
  >     >> Using block device nodes (e.g., wd0a) directly for I/O may cause
  >     >> a kernel crash when the file system containing /dev is FFS and
  >     >> is mounted with -o log.
  >     >> Workaround: use raw disk devices (e.g., rwd0a), or remount
  >     >> the file system without -o log. 
  >  
  >  Well, I guess that's it.

 I assume this means the fix isn't suitable for pullup, so I guess we
 should close the PR?

 -- 
 David A. Holland
 dholland@netbsd.org

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: dholland-bugs@NetBSD.org, gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/44504: kernel panics when dding some block sizes toUSBflash
	 drives at sd0
Date: Wed, 9 Feb 2011 18:45:25 +0900

 >  I assume this means the fix isn't suitable for pullup, so I guess we
 >  should close the PR?

 AFAIK there is no fix even on -current yet.

 I think it's a good idea to keep this PR to denote the existing
 known serious problem because no other specific PR about this issue.
 (PR kern/41189 might be related but that one has too many other issue)

 ---
 Izumi Tsutsui

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44504: kernel panics when dding some block sizes toUSBflash
 drives at sd0
Date: Sat, 12 Feb 2011 20:33:49 +0000

 On Wed, Feb 09, 2011 at 09:50:04AM +0000, Izumi Tsutsui wrote:
  >>  I assume this means the fix isn't suitable for pullup, so I guess we
  >>  should close the PR?
  >  
  >  AFAIK there is no fix even on -current yet.
  >  
  >  I think it's a good idea to keep this PR to denote the existing
  >  known serious problem because no other specific PR about this issue.
  >  (PR kern/41189 might be related but that one has too many other issue)

 He said he couldn't reproduce it on -current, but ok...

 -- 
 David A. Holland
 dholland@netbsd.org

From: Taylor R Campbell <campbell+netbsd@mumble.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, David Holland <dholland-bugs@netbsd.org>
Subject: Re: kern/44504: kernel panics when dding some block sizes toUSBflash
	drives at sd0
Date: Sat, 12 Feb 2011 20:46:49 +0000

    Date: Sat, 12 Feb 2011 20:33:49 +0000
    From: David Holland <dholland-bugs@netbsd.org>

    On Wed, Feb 09, 2011 at 09:50:04AM +0000, Izumi Tsutsui wrote:
     >>  I assume this means the fix isn't suitable for pullup, so I guess we
     >>  should close the PR?
     > =20
     >  AFAIK there is no fix even on -current yet.
     > =20
     >  I think it's a good idea to keep this PR to denote the existing
     >  known serious problem because no other specific PR about this issue.
     >  (PR kern/41189 might be related but that one has too many other issu=
 e)

    He said he couldn't reproduce it on -current, but ok...

 I didn't try very hard to reproduce it on -current.  In -5, I could
 reproduce it much more reliably in multi-user mode than in single-
 user mode, but in -current, I tested only single-user mode.

From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44504: kernel panics when dding some block sizes to USB
 flash drives at sd0
Date: Sun, 25 Nov 2018 17:44:20 +0000

 Is this even fixable?

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44504: kernel panics when dding some block sizes to USB
 flash drives at sd0
Date: Sat, 10 Jul 2021 04:43:46 +0000

 On Sun, Nov 25, 2018 at 05:45:01PM +0000, coypu@sdf.org wrote:
  >  Is this even fixable?

 If it was a symptom of the problems with calling the wrong fs's ops
 because of confusion about who device vnodes belong to, then yes; all
 the known tentacles of that were fixed quite some time back now.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 10 Jul 2021 05:40:04 +0000
State-Changed-Why:
believed to be a symptom of calling the root fs's vnode ops on other fs's
vnodes, which was cleaned up some years ago.


>Unformatted:

Home	PR Database Search