NetBSD Problem Report #38762
From gson@gson.org Mon May 26 19:02:10 2008
Return-Path: <gson@gson.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id 6995663B8E3
for <gnats-bugs@gnats.NetBSD.org>; Mon, 26 May 2008 19:02:10 +0000 (UTC)
Message-Id: <20080526190207.4BABA7616A@guava.gson.org>
Date: Mon, 26 May 2008 22:02:07 +0300 (EEST)
From: gson@gson.org (Andreas Gustafsson)
Reply-To: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@gnats.NetBSD.org
Subject: panic: vwakeup: neg numoutput
X-Send-Pr-Version: 3.95
>Number: 38762
>Category: kern
>Synopsis: panic: vwakeup: neg numoutput
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: hannken
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon May 26 19:05:04 +0000 2008
>Closed-Date: Sun Jul 17 09:21:04 +0000 2011
>Last-Modified: Sun Jul 17 09:21:04 +0000 2011
>Originator: Andreas Gustafsson
>Release: NetBSD 4.99.62 as of 20080516-1010 EET
>Organization:
>Environment:
System: NetBSD 4.99.62
Architecture: i386
Machine: i386
>Description:
NetBSD-current will panic if I attach a USB mass storage device with
an FFS file system to a USB 2.0 port, mount it, and write a file to
it. The panic message looks like
panic: vwakeup: neg numoutput, vp 0xcccb274c
I have reproduced this on three different i386 machines using two
different USB mass storage devices (one flash memory stick and one
hard disk).
For a screenshot and DDB backtrace, see
http://www.gson.org/netbsd/bugs/negnum/1.jpg
http://www.gson.org/netbsd/bugs/negnum/2.jpg
http://www.gson.org/netbsd/bugs/negnum/3.jpg
The file system used in this test was freshly fsck'd.
>How-To-Repeat:
Create a FFS file system on a USB mass storage device. Attach it to a
USB 2.0 (EHCI) port; let's assume it attaches as sd0. Enter the
commands
mount /dev/sd0a /mnt
echo foo >/mnt/bar
If this doesn't panic, try
umount /dev/sd0a
>Fix:
>Release-Note:
>Audit-Trail:
From: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Sun, 8 Jun 2008 22:55:10 +0300
I have now reproduced the problem on a fourth machine, this time with
an uhci USB controller. In other words, it is not ehci specific.
Could someone please look into this?
--
Andreas Gustafsson, gson@gson.org
From: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Sun, 27 Jul 2008 21:49:10 +0300
The panic still happens with 4.99.70 (source date 20080725-1531 EET).
--
Andreas Gustafsson, gson@gson.org
From: Greg Oster <oster@cs.usask.ca>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Sun, 27 Jul 2008 16:27:36 -0600
Andreas Gustafsson writes:
> The following reply was made to PR kern/38762; it has been noted by GNATS.
>
> From: gson@gson.org (Andreas Gustafsson)
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: kern/38762: panic: vwakeup: neg numoutput
> Date: Sun, 27 Jul 2008 21:49:10 +0300
>
> The panic still happens with 4.99.70 (source date 20080725-1531 EET).
I'm unable to replicate this panic, but could you try this patch and
see if it changes anything?
Thanks.
Later...
Greg Oster
-----------
Index: genfs_io.c
===================================================================
RCS file: /cvsroot/src/sys/miscfs/genfs/genfs_io.c,v
retrieving revision 1.8.2.1
diff -u -r1.8.2.1 genfs_io.c
--- genfs_io.c 10 Jun 2008 14:51:22 -0000 1.8.2.1
+++ genfs_io.c 27 Jul 2008 22:23:43 -0000
@@ -1513,13 +1513,14 @@
uio.uio_rw = UIO_WRITE;
uio.uio_resid = npages << PAGE_SHIFT;
UIO_SETUP_SYSSPACE(&uio);
- /* XXX vn_lock */
- error = VOP_WRITE(vp, &uio, 0, cred);
mutex_enter(&vp->v_interlock);
vp->v_numoutput++;
mutex_exit(&vp->v_interlock);
+ /* XXX vn_lock */
+ error = VOP_WRITE(vp, &uio, 0, cred);
+
bp = getiobuf(vp, true);
bp->b_cflags = BC_BUSY | BC_AGE;
bp->b_lblkno = offset >> vp->v_mount->mnt_fs_bshift;
From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Mon, 28 Jul 2008 03:31:15 +0300
On Sun Jul 27 2008 at 22:30:02 +0000, Greg Oster wrote:
> The following reply was made to PR kern/38762; it has been noted by GNATS.
>
> From: Greg Oster <oster@cs.usask.ca>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: kern/38762: panic: vwakeup: neg numoutput
> Date: Sun, 27 Jul 2008 16:27:36 -0600
>
> Andreas Gustafsson writes:
> > The following reply was made to PR kern/38762; it has been noted by GNATS.
> >
> > From: gson@gson.org (Andreas Gustafsson)
> > To: gnats-bugs@NetBSD.org
> > Cc:
> > Subject: Re: kern/38762: panic: vwakeup: neg numoutput
> > Date: Sun, 27 Jul 2008 21:49:10 +0300
> >
> > The panic still happens with 4.99.70 (source date 20080725-1531 EET).
>
> I'm unable to replicate this panic, but could you try this patch and
> see if it changes anything?
Very unlikely because a) genfs_compat_gop_write() is for file systems
which don't support UBC (unlike ffs) and b) the numoutput is for the
write done to the buffer from getiobuf(), not VOP_WRITE().
Probably a problem with usb, scsi, or whatever.
> Thanks.
>
> Later...
>
> Greg Oster
>
> -----------
> Index: genfs_io.c
> ===================================================================
> RCS file: /cvsroot/src/sys/miscfs/genfs/genfs_io.c,v
> retrieving revision 1.8.2.1
> diff -u -r1.8.2.1 genfs_io.c
> --- genfs_io.c 10 Jun 2008 14:51:22 -0000 1.8.2.1
> +++ genfs_io.c 27 Jul 2008 22:23:43 -0000
> @@ -1513,13 +1513,14 @@
> uio.uio_rw = UIO_WRITE;
> uio.uio_resid = npages << PAGE_SHIFT;
> UIO_SETUP_SYSSPACE(&uio);
> - /* XXX vn_lock */
> - error = VOP_WRITE(vp, &uio, 0, cred);
>
> mutex_enter(&vp->v_interlock);
> vp->v_numoutput++;
> mutex_exit(&vp->v_interlock);
>
> + /* XXX vn_lock */
> + error = VOP_WRITE(vp, &uio, 0, cred);
> +
> bp = getiobuf(vp, true);
> bp->b_cflags = BC_BUSY | BC_AGE;
> bp->b_lblkno = offset >> vp->v_mount->mnt_fs_bshift;
>
>
>
From: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@NetBSD.org
Cc: Greg Oster <oster@cs.usask.ca>
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 22 Aug 2008 14:22:29 +0300 (EEST)
After running a number of additional tests, some successfully
reproducing the panic and some not, I think I have figured out a
pattern: the panic is easily reproduced when the system is booted from
a live CD (built using mklivecd from pkgsrc), but I can't reproduce it
when booting from the network.
I haven't tried reproducing the bug using a system booted from a hard
disk yet, but based on the fact that this panic has not been widely
reported or reproduced, I assume the panic does not occur when booting
from a hard disk but is somehow specific to the live CD case.
--
Andreas Gustafsson, gson@gson.org
From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@NetBSD.org
Cc: Andreas Gustafsson <gson@gson.org>
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 22 Aug 2008 14:35:21 +0300
On Fri Aug 22 2008 at 11:25:01 +0000, Andreas Gustafsson wrote:
> After running a number of additional tests, some successfully
> reproducing the panic and some not, I think I have figured out a
> pattern: the panic is easily reproduced when the system is booted from
> a live CD (built using mklivecd from pkgsrc), but I can't reproduce it
> when booting from the network.
>
> I haven't tried reproducing the bug using a system booted from a hard
> disk yet, but based on the fact that this panic has not been widely
> reported or reproduced, I assume the panic does not occur when booting
> from a hard disk but is somehow specific to the live CD case.
Hmm, sounds suspicious. Are you *sure* you're trying the exact same
kernel, machine, usb stick, etc?
Seems like the data flush triggers the problem, as the echo command has
returned already. So I'm guessing "sync" is enough instead of unmount.
Can you do "show vnode" for the problematic vnode?
If you have puffs/rump available, can you see if it tickles the problem
also? rump_ffs /dev/rsd0a /mnt ; echo foo > /mnt/bar ; sync
From: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@NetBSD.org
Cc: Greg Oster <oster@cs.usask.ca>
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 22 Aug 2008 14:55:18 +0300 (EEST)
To rule out the possibility that I might have built my live CD wrong,
I went looking for other live CDs based on -current, and stumbled
across the following comment from a user of the "jibbed" live CD at
<http://www.jibbed.org/usercomments.php#67>:
Usually, system hanged when I try to write any data to any
normal disk or USB device after boot from jibbed
That gave me the idea to try booting from a live CD (still one of my
own builds, not jibbed) but mounting, writing to, and unmounting a
file system on a hard disk (wd0a) instead of one on a USB mass storage
device. And guess what: at the unmount, it paniced with the same
"vwakeup: neg numoutput" message as when using the USB device.
So, it appares the bug is not USB specific at all, but that a mount /
write / unmount of _any_ FFS file system will cause a panic if you
have booted from a live CD.
--
Andreas Gustafsson, gson@gson.org
From: gson@gson.org (Andreas Gustafsson)
To: Antti Kantee <pooka@cs.hut.fi>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 22 Aug 2008 15:23:34 +0300
Antti Kantee wrote:
> Hmm, sounds suspicious. Are you *sure* you're trying the exact same
> kernel, machine, usb stick, etc?
The netboot kernel configuration is GENERIC; the live CD kernel
configuration is LIVECD, with the following contents:
include "GENERIC"
no config netbsd
config netbsd root on cd0a type cd9660 dumps on none
options INCLUDE_CONFIG_FILE
Same physical machine, same USB stick.
> Seems like the data flush triggers the problem, as the echo command has
> returned already. So I'm guessing "sync" is enough instead of unmount.
You are correct. The following sequence of commands triggered the
panic when booted from the live CD (and if anyone wants to try it,
please note that it will wipe out the entire contents of your hard
disk):
dd if=/dev/zero bs=1m of=/dev/rwd0d
newfs /dev/rwd0a
mount /dev/wd0a /mnt
echo foo >/mnt/bar
sync
> Can you do "show vnode" for the problematic vnode?
Yes. This is transcribed by hand from a VGA console, so there may be
typos:
panic: wvakeup: neg numoutput, vp 0xcc10c750
Stopped in pid 0.4 (system) at netbsd:breakpoint+0x4: popl %ebp
db{0}> show vnode 0xcc10c750
OBJECT 0xcc10c750: locked=1, pgops=0xc07cfca0, npages=0, refs=3
VNODE flags 24010<MPSAFER,ONWORKLST,LAYER>
mp 0xcbd19000 numoutput -1 size 0x0 writesize 0x0
data 0xcbe4044c writecount 0 holdcnt 4
tag VT_NULL(9) type VBLK(3) mount 0xcbd19000 typedata 0xcbe40460
v_lock 0xcc10c7dc v_unlock 0xcbe70b1c
> If you have puffs/rump available, can you see if it tickles the problem
> also? rump_ffs /dev/rsd0a /mnt ; echo foo > /mnt/bar ; sync
I will try that after -current has finished building.
--
Andreas Gustafsson, gson@gson.org
State-Changed-From-To: open->analyzed
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Fri, 22 Aug 2008 15:32:30 +0300
State-Changed-Why:
dev nodes and nullfs are known not to mix
From: Antti Kantee <pooka@cs.hut.fi>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 22 Aug 2008 15:31:54 +0300
On Fri Aug 22 2008 at 15:23:34 +0300, Andreas Gustafsson wrote:
> panic: wvakeup: neg numoutput, vp 0xcc10c750
> Stopped in pid 0.4 (system) at netbsd:breakpoint+0x4: popl %ebp
> db{0}> show vnode 0xcc10c750
> OBJECT 0xcc10c750: locked=1, pgops=0xc07cfca0, npages=0, refs=3
>
> VNODE flags 24010<MPSAFER,ONWORKLST,LAYER>
> mp 0xcbd19000 numoutput -1 size 0x0 writesize 0x0
> data 0xcbe4044c writecount 0 holdcnt 4
> tag VT_NULL(9) type VBLK(3) mount 0xcbd19000 typedata 0xcbe40460
> v_lock 0xcc10c7dc v_unlock 0xcbe70b1c
Ahaa, so the livecd device node is *still* on nullfs. Well that explains
a few things. IIRC having a device node on nullfs is broken in other
ways also. I think there's a tech-something thread from around last
summer going over the issues, maybe even a PR somewhere (I was really
busy that time).
Either fix layerfs or use tmpfs for /dev.
From: David Holland <dholland-bugs@netbsd.org>
To: Andreas Gustafsson <gson@gson.org>, gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 22 Aug 2008 16:19:55 +0000
On Fri, Aug 22, 2008 at 12:25:02PM +0000, Andreas Gustafsson wrote:
> type VBLK(3)
There is an ongoing problem whereby the code from the FS on which the
volume's device node lives is sometimes used to process files on the
volume itself. This is almost certainly another manifestation.
Something must be severely wrong somewhere, because it ought not to be
architecturally possible for this to happen. One of these days I need
to go after it with a chainsaw.
--
David A. Holland
dholland@netbsd.org
From: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 5 Sep 2008 15:54:48 +0300
Here's a way to reproduce the panic that should work on any NetBSD
system. Unlike the previous methods, this one does not require a
live CD, nor a physical scratch device to create a file system on.
Simply execute the following sequence of commands as root:
mkdir /tmp/dev2
mount_null /dev /tmp/dev2
dd if=/dev/zero of=/tmp/img bs=1k count=1024
vnconfig /dev/vnd0 /tmp/img
newfs /dev/rvnd0a
mount /tmp/dev2/vnd0a /mnt
echo foo >/mnt/bar
sync
--
Andreas Gustafsson, gson@gson.org
From: "=?UTF-8?Q?Zafer_Aydo=C4=9Fan?=" <zafer@aydogan.de>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
"Andreas Gustafsson" <gson@gson.org>
Subject: Re: kern/38762: panic: vwakeup: neg numoutput
Date: Fri, 5 Sep 2008 18:38:45 +0200
2008/9/5 Andreas Gustafsson <gson@gson.org>:
> The following reply was made to PR kern/38762; it has been noted by GNATS.
>
> From: gson@gson.org (Andreas Gustafsson)
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: kern/38762: panic: vwakeup: neg numoutput
> Date: Fri, 5 Sep 2008 15:54:48 +0300
>
> Here's a way to reproduce the panic that should work on any NetBSD
> system. Unlike the previous methods, this one does not require a
> live CD, nor a physical scratch device to create a file system on.
>
> Simply execute the following sequence of commands as root:
>
> mkdir /tmp/dev2
> mount_null /dev /tmp/dev2
> dd if=/dev/zero of=/tmp/img bs=1k count=1024
> vnconfig /dev/vnd0 /tmp/img
> newfs /dev/rvnd0a
> mount /tmp/dev2/vnd0a /mnt
> echo foo >/mnt/bar
> sync
>
> --
> Andreas Gustafsson, gson@gson.org
>
>
I don't know if this is related (except the nullfs part), but I have
filed a PR a while ago
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=38872
regarding panics upon mounting compressed images via vnconfig. (which
is used by mklivecd and jibbed)
Zafer.
From: Andrew Doran <andrew@hairylemon.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/38762 (panic: vwakeup: neg numoutput)
Date: Wed, 24 Sep 2008 11:00:58 +0000
Also:
panic: kernel diagnostic assertion "bp->b_objlock == &vp->v_interlock" failed: file "../../../../kern/vfs_bio.c", line 805
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0363b8c cs 8 eflags 286 cr2 bbb42d08 ilevel 0
Stopped in pid 298.1 (sync) at netbsd:breakpoint+0x4: popl %ebp
db{6}> bt
breakpoint(cf4dea58,100,cf4dea8c,c02dcfc9,c049b1ba,cf4dea98,c459a000,c02d6398,0,
cdee97e4) at netbsd:breakpoint+0x4
cpu_Debugger(c049b1ba,cf4dea98,c459a000,c02d6398,0,cdee97e4,0,c02d66bb,0,cf90bac
0) at netbsd:cpu_Debugger+0xb
panic(c04da5d0,c0478744,c048b4a8,c049fc33,325,cdee97e4,cf4deadc,c03127e1,c047874
4,c049fc33) at netbsd:panic+0x127
__kernassert(c0478744,c049fc33,325,c048b4a8,0,cdee97e4,0,c4700178,cf919d00,0) at
netbsd:__kernassert+0x37
bwrite(c4700178,18,cf4deb1c,c032bd3d,cf4deb10,800,cf4deb1c,c0322cb4,0,0) at netb
sd:bwrite+0xa5
vn_bwrite(cf4deb10,800,cf4deb1c,c0322cb4,0,0,cf4deb4c,c04599e0,c4700178,c4700178
) at netbsd:vn_bwrite+0x14
VOP_BWRITE(c4700178,0,cf4deb3c,c459a118,c4700178,cf7d6800,cf4deb6c,c032bd3d,cf4d
eb60,cf4debcc) at netbsd:VOP_BWRITE+0x6d
layer_bwrite(cf4deb60,cf4debcc,cf4deb8c,c0244142,c4700178,0,0,c04599e0,c4700178,
c4700178) at netbsd:layer_bwrite+0x2b
VOP_BWRITE(c4700178,0,cf4debbc,c46e9800,c46e9800,c46e9800,cf4debdc,c02446b3,c470
0178,c46e9800) at netbsd:VOP_BWRITE+0x6d
bawrite(c4700178,c46e9800,600,ffffffff,ffffffff,600,0,cf4debcc,cef9838c,cf919d00
) at netbsd:bawrite+0x43
ffs_sbupdate(c46fbf00,2,cf4dec0c,c0331722,cef9838c,6,cf4dec3c,cf919d00,cf9198b0,
0) at netbsd:ffs_sbupdate+0x185
ffs_cgupdate(c46fbf00,2,10,0,0,0,0,cf90bac0,c46fbf00,c46e9800) at netbsd:ffs_cgu
pdate+0x1e
ffs_sync(ce090ba8,2,cd826b40,ce090ba8,ce090ba8,1000,cf4decdc,c0321aee,ce090ba8,2
) at netbsd:ffs_sync+0x4a3
VFS_SYNC(ce090ba8,2,cd826b40,0,0,c04e4908,ce090ba8,0,cf90bac0,c04e4a70) at netbs
d:VFS_SYNC+0x34
sys_sync(cf90bac0,cf4ded00,cf4ded28,bbb42d08,bbb42000,ce209d00,1,bfbfea74,2,bbbe
81a0) at netbsd:sys_sync+0x88
syscall(cf4ded48,b3,ab,1f,1f,bfbfeb48,80498f0,bfbfeae8,80498c8,0) at netbsd:sysc
all+0xf5
db{6}>
State-Changed-From-To: analyzed->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 13 Jun 2011 02:27:03 +0000
State-Changed-Why:
hannken@'s recent syncer fixes should have (hopefully) fixed this.
any luck?
From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org,
gnats-admin@netbsd.org,
dholland@NetBSD.org,
hannken@NetBSD.org
Subject: Re: kern/38762 (panic: vwakeup: neg numoutput)
Date: Tue, 14 Jun 2011 13:14:54 +0300
dholland@NetBSD.org wrote:
> Synopsis: panic: vwakeup: neg numoutput
>
> State-Changed-From-To: analyzed->feedback
> State-Changed-By: dholland@NetBSD.org
> State-Changed-When: Mon, 13 Jun 2011 02:27:03 +0000
> State-Changed-Why:
> hannken@'s recent syncer fixes should have (hopefully) fixed this.
> any luck?
No such luck. I just tested a -current system (source date
2011.06.14.07.53.29), and as before, it paniced when I ran
the following commands:
mkdir /tmp/dev2
mount_null /dev /tmp/dev2
dd if=/dev/zero of=/tmp/img bs=1k count=1024
vnconfig /dev/vnd0 /tmp/img
newfs /dev/rvnd0a
mount /tmp/dev2/vnd0a /mnt
echo foo >/mnt/bar
sync
--
Andreas Gustafsson, gson@gson.org
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Wed, 22 Jun 2011 04:43:53 +0000
State-Changed-Why:
No such luck. sigh
From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/38762 CVS commit: src/sys/kern
Date: Mon, 11 Jul 2011 08:23:01 +0000
Module Name: src
Committed By: hannken
Date: Mon Jul 11 08:23:01 UTC 2011
Modified Files:
src/sys/kern: vnode_if.sh vnode_if.src
Log Message:
Change VOP_BWRITE() to take a vnode as its first argument like all other
VOPs do. Layered file systems no longer have to modify bp->b_vp and run
into trouble when an async VOP_BWRITE() uses the wrong vnode.
Adresses PR kern/38762 panic: vwakeup: neg numoutput
No objections from tech-kern@.
To generate a diff of this commit:
cvs rdiff -u -r1.57 -r1.58 src/sys/kern/vnode_if.sh
cvs rdiff -u -r1.61 -r1.62 src/sys/kern/vnode_if.src
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/38762 CVS commit: src
Date: Mon, 11 Jul 2011 08:27:42 +0000
Module Name: src
Committed By: hannken
Date: Mon Jul 11 08:27:41 UTC 2011
Modified Files:
src/share/man/man9: vnodeops.9
src/sys/kern: vfs_bio.c vfs_subr.c vnode_if.c
src/sys/miscfs/genfs: layer_extern.h layer_vnops.c
src/sys/miscfs/nullfs: null_vnops.c
src/sys/miscfs/overlay: overlay_vnops.c
src/sys/miscfs/umapfs: umap_vnops.c
src/sys/rump/include/rump: rumpvnode_if.h
src/sys/rump/librump/rumpvfs: rumpvnode_if.c
src/sys/sys: param.h vnode_if.h
src/sys/ufs/ext2fs: ext2fs_lookup.c
src/sys/ufs/lfs: lfs.h lfs_balloc.c lfs_bio.c lfs_inode.c lfs_segment.c
lfs_vfsops.c lfs_vnops.c
src/sys/ufs/ufs: ufs_lookup.c ufs_readwrite.c ufs_vnops.c
Log Message:
Change VOP_BWRITE() to take a vnode as its first argument like all other
VOPs do. Layered file systems no longer have to modify bp->b_vp and run
into trouble when an async VOP_BWRITE() uses the wrong vnode.
- change all occurences of VOP_BWRITE(bp) to VOP_BWRITE(bp->b_vp, bp).
- remove layer_bwrite().
- welcome to 5.99.55
Adresses PR kern/38762 panic: vwakeup: neg numoutput
No objections from tech-kern@.
To generate a diff of this commit:
cvs rdiff -u -r1.81 -r1.82 src/share/man/man9/vnodeops.9
cvs rdiff -u -r1.230 -r1.231 src/sys/kern/vfs_bio.c
cvs rdiff -u -r1.423 -r1.424 src/sys/kern/vfs_subr.c
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/vnode_if.c
cvs rdiff -u -r1.28 -r1.29 src/sys/miscfs/genfs/layer_extern.h
cvs rdiff -u -r1.48 -r1.49 src/sys/miscfs/genfs/layer_vnops.c
cvs rdiff -u -r1.37 -r1.38 src/sys/miscfs/nullfs/null_vnops.c
cvs rdiff -u -r1.18 -r1.19 src/sys/miscfs/overlay/overlay_vnops.c
cvs rdiff -u -r1.52 -r1.53 src/sys/miscfs/umapfs/umap_vnops.c
cvs rdiff -u -r1.10 -r1.11 src/sys/rump/include/rump/rumpvnode_if.h
cvs rdiff -u -r1.9 -r1.10 src/sys/rump/librump/rumpvfs/rumpvnode_if.c
cvs rdiff -u -r1.391 -r1.392 src/sys/sys/param.h
cvs rdiff -u -r1.81 -r1.82 src/sys/sys/vnode_if.h
cvs rdiff -u -r1.63 -r1.64 src/sys/ufs/ext2fs/ext2fs_lookup.c
cvs rdiff -u -r1.133 -r1.134 src/sys/ufs/lfs/lfs.h
cvs rdiff -u -r1.69 -r1.70 src/sys/ufs/lfs/lfs_balloc.c
cvs rdiff -u -r1.119 -r1.120 src/sys/ufs/lfs/lfs_bio.c
cvs rdiff -u -r1.124 -r1.125 src/sys/ufs/lfs/lfs_inode.c
cvs rdiff -u -r1.221 -r1.222 src/sys/ufs/lfs/lfs_segment.c
cvs rdiff -u -r1.289 -r1.290 src/sys/ufs/lfs/lfs_vfsops.c
cvs rdiff -u -r1.235 -r1.236 src/sys/ufs/lfs/lfs_vnops.c
cvs rdiff -u -r1.106 -r1.107 src/sys/ufs/ufs/ufs_lookup.c
cvs rdiff -u -r1.98 -r1.99 src/sys/ufs/ufs/ufs_readwrite.c
cvs rdiff -u -r1.189 -r1.190 src/sys/ufs/ufs/ufs_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/38762 CVS commit: src/sys/miscfs/genfs
Date: Mon, 11 Jul 2011 08:34:02 +0000
Module Name: src
Committed By: hannken
Date: Mon Jul 11 08:34:01 UTC 2011
Modified Files:
src/sys/miscfs/genfs: layer_vnops.c
Log Message:
Layer_fsync(): when syncing a device node call spec_fsync() to clean the
layer node before descending to the lower file system.
Adresses PR kern/38762 panic: vwakeup: neg numoutput
To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50 src/sys/miscfs/genfs/layer_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Responsible-Changed-From-To: kern-bug-people->hannken
Responsible-Changed-By: hannken@NetBSD.org
Responsible-Changed-When: Mon, 11 Jul 2011 08:49:44 +0000
Responsible-Changed-Why:
Take.
State-Changed-From-To: open->feedback
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Mon, 11 Jul 2011 08:49:44 +0000
State-Changed-Why:
Hopefully fixed with 5.99.55 -- please confirm.
From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: hannken@NetBSD.org,
kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org,
gnats-admin@netbsd.org
Subject: Re: kern/38762 (panic: vwakeup: neg numoutput)
Date: Sun, 17 Jul 2011 12:11:00 +0300
hannken@NetBSD.org wrote:
> Hopefully fixed with 5.99.55 -- please confirm.
Confirmed fixed in 2011.07.17.04.30.56 sources. Thanks!
--
Andreas Gustafsson, gson@gson.org
State-Changed-From-To: feedback->closed
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Sun, 17 Jul 2011 09:21:04 +0000
State-Changed-Why:
Submitter confirmed fixed.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home