Date: Tue, 11 Jun 1996 16:02:21 -0700 From: Matt Day <mday@artisoft.com> To: freebsd-current@FreeBSD.org, taob@io.org Subject: Re: Kernel panic in fsync, 2.2-960501-SNAP Message-ID: <199606112302.QAA28053@sting.artisoft.com>
next in thread | raw e-mail | index | archive | help
Brian Tao <taob@io.org> 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 <mday@artisoft.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606112302.QAA28053>