Date: Thu, 25 May 2006 13:19:51 -0400 From: Stephan Uphoff <ups@freebsd.org> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c src/sys/nfsclient nfs_bio.c src/sys/fs/smbfs smbfs_io.c src/sys/fs/nwfs nwfs_io.c Message-ID: <4475E737.6070404@freebsd.org> In-Reply-To: <1148569279.13356.10.camel@opus.cse.buffalo.edu> References: <200605250100.k4P10a3P002448@repoman.freebsd.org> <1148569279.13356.10.camel@opus.cse.buffalo.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Ken Smith wrote: > On Thu, 2006-05-25 at 01:00 +0000, Stephan Uphoff wrote: > >> ups 2006-05-25 01:00:36 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/kern vfs_subr.c >> sys/nfsclient nfs_bio.c >> sys/fs/smbfs smbfs_io.c >> sys/fs/nwfs nwfs_io.c >> Log: >> Do not set B_NOCACHE on buffers when releasing them in flushbuflist(). >> If B_NOCACHE is set the pages of vm backed buffers will be invalidated. >> However clean buffers can be backed by dirty VM pages so invalidating them >> can lead to data loss. >> Add support for flush dirty page in the data invalidation function >> of some network file systems. >> >> This fixes data losses during vnode recycling (and other code paths >> using invalbuf(*,V_SAVE,*,*)) for data written using an mmaped file. >> >> Collaborative effort by: jhb@,mohans@,peter@,ps@,ups@ >> Reviewed by: tegge@ >> MFC after: 7 days >> >> Revision Changes Path >> 1.43 +4 -0 src/sys/fs/nwfs/nwfs_io.c >> 1.35 +4 -0 src/sys/fs/smbfs/smbfs_io.c >> 1.673 +1 -1 src/sys/kern/vfs_subr.c >> 1.157 +11 -0 src/sys/nfsclient/nfs_bio.c >> > > I'm just guessing but I think this is what's causing sledge (amd64 > reference machine in the cluster) to panic whenever someone tries to log > in to it. Home directories come from the NetApp. It seems to do other > NFS stuff (e.g. it's able to get to the SSH keys which also reside on > the NetApp) but something about logging in causes this: > > panic: mutex vm object not owned at ../../../vm/vm_object.c:695 > cpuid = 0 > KDB: stack backtrace: > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x1d1 > _mtx_assert() at _mtx_assert+0x78 > vm_object_page_clean() at vm_object_page_clean+0x3e > nfs_vinvalbuf() at nfs_vinvalbuf+0xc2 > nfs_bioread() at nfs_bioread+0x43b > nfs_read() at nfs_read+0x33 > VOP_READ_APV() at VOP_READ_APV+0xb1 > vn_read() at vn_read+0x218 > dofileread() at dofileread+0x9e > kern_readv() at kern_readv+0x4f > read() at read+0x4b > syscall() at syscall+0x350 > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (3, FreeBSD ELF64, read), rip = 0x8009de68c, rsp = > 0x7fffffff2798, rbp = 0x2000 --- > KDB: enter: panic > [thread pid 465 tid 100056 ] > Stopped at kdb_enter+0x31: leave > db> Ooopppsss! Thanks for the trace. I just checked in a fix.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4475E737.6070404>