Re: kern/54945 (nfs uvm_pagegetdirty panic)

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

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

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost, ad%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, prlw1%cam.ac.uk@localhost
Cc: 
Subject: Re: kern/54945 (nfs uvm_pagegetdirty panic)
Date: Thu, 20 Feb 2020 18:16:47 +0900

 I can now reproduce the assertion failure
 
      panic: kernel diagnostic assertion "uobj == NULL || !UVM_OBJ_IS_CLEAN(uobjpage->uobject) || uvm_pagegetdirty(uobjpage) == UVM_PAGE_STATUS_CLEAN" failed: file "../../../../uvm/uvm_fault.c", line 1754
 
 on powerpc/ibm4xx. It is triggered by this sample code:
 
      http://www.netbsd.org/~rin/pr54945.c
 
 This is taken from configure script of some 3rd party software. This
 mmap's temporary file onto a fixed address, where anonymous memory has
 already been mapped by malloc. The KASSERT fires when reading from
 mmap'ed address, if temporary file is on NFS:
 
      # /home/rin/a.out
      malloc data1
 
      malloc data2
 
      data2: 0xfdc04000 --> 0xfdc04000
 
      mmap to data2
 
      read from data2
      [  25.3799285] panic: kernel diagnostic assertion "uobj == NULL || !UVM_OBJ_IS_CLEAN(uobjpage->uobject) || uvm_pagegetdirty(uobjpage) == UVM_PAGE_STATUS_CLEAN" failed: file "../../../../uvm/uvm_fault.c", line 1754
      [  25.3799285] cpu0: Begin traceback...
      [  25.3799285] 0x079afc90:
                                 at vpanic+0x130
      [  25.6800570] 0x079afcc0: at kern_assert+0x60
      [  25.7299618] 0x079afd00: at uvm_fault_internal+0x2114
      [  25.7799536] 0x079afe70: at trap+0x560
      [  25.8399672] 0x079aff20: user DTMISS trap by 0x1800c94: srr1=0xc030
      [  25.8399672]             r1=0xfffeba10 cr=0x44000848 xer=0 ctr=0xfdcba4c0 esr=0 pid=0xc
      [  25.8399672] cpu0: End traceback...
      Stopped in pid 10.1 (a.out) at  netbsd:vpanic+0x134:    or      r3, r29, r29
 
 While this is almost reproducible on NFS, it does not occur on tmpfs nor
 FFS as far as I can see. Also, panic does not occur on amd64 and armv6.
 
 MMU of ibm4xx is different from ones of standard powerpc processors, and
 therefore has its own pmap implementation. Page size is 16KB, and TLB is
 completely managed by software. Modified and referenced bits are absent.
 
 Here's full UVMHIST log when panic occurs:
 
      http://www.netbsd.org/~rin/uvmhist_20200220.txt
 
 I tried yamt's fixes. This is patch against -HEAD:
 
      http://www.netbsd.org/~rin/nfs_yamt-pagecache_20200220.patch
 
 But this does not solve the problem.
 
 Thanks,
 rin