Re: fstat triggered INVARIANTS panic in memrw()

On Sat, Jan 15, 2005 at 12:38:47AM -0800, Kris Kennaway wrote:
> The full panic string is
> 
> panic: vm_fault: fault on nofault entry, addr: deae2000
> 
> ----- Forwarded message from Kris Kennaway <kris_at_obsecurity.org> -----
> 
> Date: Fri, 24 Dec 2004 17:42:08 -0800
> From: Kris Kennaway <kris_at_obsecurity.org>
> To: current_at_FreeBSD.org
> Cc: phk_at_FreeBSD.org
> Subject: fstat triggered INVARIANTS panic
> User-Agent: Mutt/1.4.2.1i
> 
> I ran fstat | more on a SMP 6.0 machine with kernel from about a month
> ago, which had a lot of files open.  It panicked with:
> 
> panic: vm_fault: fau
> 
> and got no further on the console, but I was able to break to DBB and
> obtain the following traceback from fstat:
> 
> db> tr 94874
> Tracing pid 94874 tid 100815 td 0xc9ec1780
> sched_switch(c9ec1780,c34dc480,1,11a,88a1da96) at sched_switch+0x105
> mi_switch(6,c34dc480,c06d4ca0,271,c34dc5d0) at mi_switch+0x1d3
> maybe_preempt(c34dc480,1,c06d4c85,3d6,46) at maybe_preempt+0x11d
> sched_add(c34dc480,4,c06d4ca0,1ce,c9ec1780,0,c06d11f3,197,197,c06d11f3) at sched_add+0x299
> setrunqueue(c34dc480,4,c06d11f3,197,c077a900) at setrunqueue+0x109
> ithread_schedule(c34d4380,0,eed96788,a0f1b,c9ec1780) at ithread_schedule+0xaf
> intr_execute_handlers(c34d2ea8,eed967b8,eed96810,c0686583,45) at intr_execute_handlers+0x74
> lapic_handle_intr(45) at lapic_handle_intr+0x2d
> Xapic_isr2() at Xapic_isr2+0x33
> --- interrupt, eip = 0xc0519495, esp = 0xeed967fc, ebp = 0xeed96810 ---
> critical_exit(c0768120,0,c06ea261,a23,1) at critical_exit+0x75
> siocnputc(c071b960,75,5,75,eed9696c) at siocnputc+0x9b
> cnputc(75,10,1,0,c06d396c) at cnputc+0x65
> putchar(75,eed9696c,c0524e6c,30,13) at putchar+0xa8
> kvprintf(c06d3963,c0524780,eed9696c,a,eed96990) at kvprintf+0x87d
> printf(c06d3963,c072c680,c06e688a,eed969bc,c9ec1780) at printf+0x54
> panic(c06e688a,deae6000,1,eed96aa8,eed96a98) at panic+0xe1
> vm_fault(c1059000,deae6000,1,0,c9ec1780) at vm_fault+0x1327
> trap_pfault(deae6000,c9ec1780,eed96ba8,c050e2c3,deae6000) at trap_pfault+0x82
> trap(c06e0018,10,c1050010,8058f20,deae5ffe) at trap+0x363
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc0697f2a, esp = 0xeed96bcc, ebp = 0xeed96c04 ---
> generic_copyout(deadc0de,7ab7037c,eed96c84,54,5964d000) at generic_copyout+0x36

(kgdb) l *memrw+0x36
0xc06e3486 is in memrw (../../../i386/i386/mem.c:128).
123
124                             if (!kernacc((caddr_t)(int)uio->uio_offset, c,
125                                 uio->uio_rw == UIO_READ ?
126                                 VM_PROT_READ : VM_PROT_WRITE))
127                                     return (EFAULT);
128                             error = uiomove((caddr_t)(int)uio->uio_offset, (int)c, uio);
129                             continue;
130                     }
131                     /* else panic! */
132             }

> memrw(c34fad00,eed96c84,0,398,7ab7037c) at memrw+0x18a
> devfs_read_f(c51773b8,eed96c84,ca75c800,0,c9ec1780) at devfs_read_f+0x142
> dofileread(4,804f000,7ab7037c,ffffffff,ffffffff) at dofileread+0x92
> read(c9ec1780,eed96d14,c,3ff,3) at read+0x75
> syscall(2f,2f,2f,7ab7037c,80b1078) at syscall+0x137
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (3, FreeBSD ELF32, read), eip = 0x280d347f, esp = 0xbfbfe34c, ebp = 0xbfbfe378 ---
> 
> Note the deadc0de in generic_copyout().
> 
> There seem to be several other bugs here that show off the well-known
> brokenness of panic() and related code on SMP machines.
> 
> Kris
> 
> 
> 
> ----- End forwarded message -----