From owner-freebsd-current Tue Jun 11 16:02:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA05123 for current-outgoing; Tue, 11 Jun 1996 16:02:56 -0700 (PDT) Received: from sting.artisoft.com (sting.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA05118 for ; Tue, 11 Jun 1996 16:02:52 -0700 (PDT) Received: (from mday@localhost) by sting.artisoft.com (8.6.12/8.6.12) id QAA28053; Tue, 11 Jun 1996 16:02:21 -0700 Date: Tue, 11 Jun 1996 16:02:21 -0700 From: Matt Day Message-Id: <199606112302.QAA28053@sting.artisoft.com> To: freebsd-current@FreeBSD.org, taob@io.org Subject: Re: Kernel panic in fsync, 2.2-960501-SNAP Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brian Tao wrote: > Any caveats to running a 2.2-960501-SNAP kernel with the patch? > It applies cleanly enough. [..] The patch should work fine on 2.2-960501-SNAP. But, out of curiousity I was just taking another closer look at your panic log and now I'm pretty sure that the patch I sent yesterday will not fix your panic (though I'm still convinced that it fixes another panic). >From what I can tell, your panic log says that your system was in fsync() when it tried to access memory address 0x18. This suggests that some structure pointer was NULL and it tried to access the element at offset 0x18 in that structure. In fsync() there are two places where this can occur: if vp was NULL then it would access address 0x18 when it fetched vp->v_mount, and if vp->v_mount was NULL then it would access address 0x18 when it fetched vp->v_mount->mnt_flag. Since other elements of vp are accessed before the vp->v_mount access in fsync(), I think what probably happened is vp->v_mount was NULL. (Line 1866 of kern/vfs_syscalls.c) So, it appears that there is some way for getvnode() to return a kernel file descriptor whose f_data is a vnode that has a NULL v_mount. Unfortunately, I can't come up with a scenario where the bug I reported yesterday can cause this to happen. I'll try to track down this different bug. Sorry for the false alarm on yesterday's patch. I saw "NULL dereference" and "fsync" and I immediately thought of that fsync dereferencing NULL bug... but that was ffs_fsync(), not plain old fsync()! I think appropriate punishment for my error would be to find this other bug. :-) Matt Day