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

[Stephan Uphoff]

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.