Re: panic: vm_fault: fault on nofault entry

On Sun, Mar 09, 2014 at 12:56:48PM -0400, Glen Barber wrote:
> We are having regular panics on several machines in the cluster.
> 
> Below follows the script from the kgdb(1) session, hopefully providing
> enough information.  This machine runs 11.0-CURRENT #2 r262892, from
> 2 days ago.
> 
> It uses tmpfs(5) for the port build workspace.  I have an unconfirmed
> suspicion that use of sysutils/lsof is involved somehow, but cannot be
> sure.  (In my experience with panics with port building, removing lsof
> from the system did have an effect, but I may be going down the wrong
> rabbit hole.)
> 
> 
> Script started on Sun Mar  9 16:40:07 2014
> root_at_redbuild01.nyi:/usr/obj/usr/src/sys/REDBUILD # sh
> # kgdb ./kernel.debug /var/crash/vmcore.1
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> panic: vm_fault: fault on nofault entry, addr: fffffe035021a000
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1839a54180
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1839a54230
> panic() at panic+0x155/frame 0xfffffe1839a542b0
> vm_fault_hold() at vm_fault_hold+0x1e7a/frame 0xfffffe1839a54500
> vm_fault() at vm_fault+0x77/frame 0xfffffe1839a54540
> trap_pfault() at trap_pfault+0x199/frame 0xfffffe1839a545e0
> trap() at trap+0x4a0/frame 0xfffffe1839a547f0
> calltrap() at calltrap+0x8/frame 0xfffffe1839a547f0
> --- trap 0xc, rip = 0xffffffff80d97bab, rsp = 0xfffffe1839a548b0, rbp = 0xfffffe1839a54910 ---
> copyout() at copyout+0x3b/frame 0xfffffe1839a54910
> memrw() at memrw+0x19f/frame 0xfffffe1839a54950
> giant_read() at giant_read+0xa4/frame 0xfffffe1839a54990
> devfs_read_f() at devfs_read_f+0xeb/frame 0xfffffe1839a549f0
> dofileread() at dofileread+0x95/frame 0xfffffe1839a54a40
> kern_readv() at kern_readv+0x68/frame 0xfffffe1839a54a90
> sys_read() at sys_read+0x63/frame 0xfffffe1839a54ae0
> amd64_syscall() at amd64_syscall+0x3fb/frame 0xfffffe1839a54bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1839a54bf0
> --- syscall (3, FreeBSD ELF64, sys_read), rip = 0x800b8444a, rsp = 0x7fffffffd088, rbp = 0x7fffffffd0d0 ---
> KDB: enter: panic

This is very similar to issue reported several time ago.
Try this patch.  I never get a feedback.

diff --git a/sys/amd64/amd64/mem.c b/sys/amd64/amd64/mem.c
index abbbb21..fd9c5df 100644
--- a/sys/amd64/amd64/mem.c
+++ b/sys/amd64/amd64/mem.c
_at__at_ -98,7 +98,13 _at__at_ memrw(struct cdev *dev, struct uio *uio, int flags)
 kmemphys:
 			o = v & PAGE_MASK;
 			c = min(uio->uio_resid, (u_int)(PAGE_SIZE - o));
-			error = uiomove((void *)PHYS_TO_DMAP(v), (int)c, uio);
+			v = PHYS_TO_DMAP(v);
+			if (v < DMAP_MIN_ADDRESS ||
+			    (v > DMAP_MIN_ADDRESS + dmaplimit &&
+			    v <= DMAP_MAX_ADDRESS) ||
+			    pmap_kextract(v) == 0)
+				return (EFAULT);
+			error = uiomove((void *)v, (int)c, uio);
 			continue;
 		}
 		else if (dev2unit(dev) == CDEV_MINOR_KMEM) {