>Number:         524
>Category:       kern
>Synopsis:       mmap'ed files on nullfs filesystem's don't work properly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 17 17:05:03 1994
>Originator:     Duncan McEwan
>Organization:
"	Computer Science Department, Victoria University of Wellington, NZ"
>Release:        netbsd-current supped on Oct 11th
>Environment:
System: NetBSD orsinis.pc.comp.vuw.ac.nz 1.0_BETA NetBSD 1.0_BETA (ORSINIS) #5: Mon Oct 17 18:50:33 NZDT 1994 duncan@orsinis.pc.comp.vuw.ac.nz:/usr/src/sys/arch/i386/compile/ORSINIS i386

>Description:
	When a file on a nullfs filesystem is mmaped and the mmaped memory
	is changed (such as by using vi) it appears that the on disk version
	of the file and the in memory cached versions become inconsistent.

>How-To-Repeat:
	On a nullfs mounted filesystem:

		orsinis% cat > foobar
		this is a line of text
		^D
		orsinis% vi foobar
		<add a second line of text and exit vi>
		orsinis% vi foobar
		<you should see that the second line you just added is not
		present, and the end of the file contains a number of null
		characters equal to the length of the second line entered.>

	I believe that the 2nd invocation of vi gets stale data from the vm
	cache, but figures out the length of the file from a stat of the
	(correct) on-disk version.  This has the effect that the 2nd line added
	does not appear in the file, and an equivelent number of null bytes
	appears to be added to the end of the file.

>Fix:
	I'm not sure exactly what is happening here.  The problem could be
	related to the fact that the null_inactive() routine in null_vnops.c
	is a stub routine that doesn't pass the vnode operation down to the
	underlying filesystem, so the cached data is not properly invalidated.
	But I don't understand the vm system enough to know whether this is
	the way things work.  I tracked the call sequence back from
	null_inactive(), through VOP_INACTIVE to vrele() and vclean() but
	then got stuck!

	I haven't looked at the vi code, to see if some change could be made
	to the way it uses mmap to work around the problem.
>Audit-Trail:
>Unformatted: