Re: kern/54945 (nfs uvm_pagegetdirty panic)

[Andrew Doran <ad%netbsd.org@localhost>]

The following reply was made to PR kern/54945; it has been noted by GNATS.

From: Andrew Doran <ad%netbsd.org@localhost>
To: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	prlw1%cam.ac.uk@localhost
Subject: Re: kern/54945 (nfs uvm_pagegetdirty panic)
Date: Sat, 22 Feb 2020 23:22:41 +0000

 Hi,
 
 On Fri, Feb 21, 2020 at 12:07:59AM +0900, Rin Okuyama wrote:
 > I found that the test program in the previous message does not cause
 > panic even with NFS on ibm4xx, if taking enough intervals manually
 > between each steps in the program, i.e., write-wait-mmap-wait...
 > 
 > This result maybe implies that panic occurred only on ibm4xx, and not
 > amd64 nor armv6 just because of timing problem; ibm4xx is too slow to
 > finish asynchronous NFS IO and mark that page clean before read from
 > mmap'ed address.
 > 
 > Here's UVMHIST for successful read from mmap'ed address:
 > 
 >     http://www.netbsd.org/~rin/uvmhist_20200220_success.txt
 > 
 > Thoughts?
 
 Thank you for the detailed investigation.  I think this is unlikely to be a
 pmap prolem, since the assertion is concerned with software state - CLEAN
 and DIRTY are very definite states set by UVM.  The pmap only comes into
 play if the page's state is UNKNOWN.  The NFS changes on yamt-pagecache are
 unlikey to help either, as you discovered.  I need to think about this one
 more.
 
 Andrew