kern/58258: Panic in knote_drop()
Stefan Farfeleder
stefan at fafoe.narf.at
Fri Nov 7 09:09:01 PST 2003
On Mon, Nov 03, 2003 at 05:28:20PM -0800, Olivier Houchard wrote:
> State-Changed-From-To: open->closed
Thanks for trying to fix it, but now I'm getting a different panic,
though much less frequently. Running the same program as in the PR and
again sending SIGSTOP/SIGCONT, kn->kn_fp->f_data seems to be NULL inside
filt_piperead(). The LOR happened a few seconds before the panic.
%%
lock order reversal
1st 0xc6b0ada8 process lock (process lock) @ /freebsd/testing/src/sys/kern/kern_sig.c:1476
2nd 0xc69d12c0 pipe mutex (pipe mutex) @ /freebsd/testing/src/sys/kern/sys_pipe.c:1492
Stack backtrace:
backtrace(c0601cb9,c69d12c0,c06018d3,c06018d3,c06022f9) at backtrace+0x17
witness_lock(c69d12c0,8,c06022f9,5d4,c6ab2ec8) at witness_lock+0x5b6
_mtx_lock_flags(c69d12c0,0,c06022f9,5d4,c6a89880) at _mtx_lock_flags+0x6a
filt_piperead(c6a89880,8000002,c6b0ad3c,c6b0ad3c,e3d9ba18) at filt_piperead+0x44
knote(c6b0ae60,8000002,e3d9ba38,c04f98c2,c6b22000) at knote+0x21
do_tdsignal(c6b0b8c0,2,0,c6b0ada8,5c4) at do_tdsignal+0x4b
tdsignal(c6b0b8c0,2,0,c6b0ad3c,e3d9ba80) at tdsignal+0x4e
psignal(c6b0ad3c,2,c05ff66d,5c4,3) at psignal+0x5b
pgsignal(c6a03d80,2,1,1a9,c5) at pgsignal+0x59
ttyinput(3,c6712630,e3d9bc80,c669fa00,c0651c44) at ttyinput+0x362
ptcwrite(c663f900,e3d9bc80,7f0011,e3d9bb98,c062afe0) at ptcwrite+0x1a4
spec_write(e3d9bbe4,e3d9bc30,c0536322,e3d9bbe4,20002) at spec_write+0x183
spec_vnoperate(e3d9bbe4,20002,c669fa00,231,e3d9bc80) at spec_vnoperate+0x18
vn_write(c66993b8,e3d9bc80,c6893b80,0,c669fa00) at vn_write+0x1f2
dofilewrite(c669fa00,c66993b8,7,8085000,1) at dofilewrite+0xe9
write(c669fa00,e3d9bd14,c0611457,3ee,3) at write+0x6e
syscall(2f,2f,2f,807a200,807a248) at syscall+0x272
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x282ee1cf, esp = 0xbfbff3ac, ebp = 0xbfbff418 ---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x98
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04ff708
stack pointer = 0x10:0xe3d9b9b4
frame pointer = 0x10:0xe3d9b9d0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 573 (sshd)
kernel: type 12 trap, code=0
Stopped at filt_piperead+0x18: movl 0x98(%ebx),%edi
db> t
filt_piperead(c6a89200,8000002,c6a7f1e4,c6a7f1e4,e3d9ba18) at filt_piperead+0x18
knote(c6a7f308,8000002,e3d9ba38,c04f98c2,c6aa8000) at knote+0x21
do_tdsignal(c6a35640,2,0,c6a7f250,5c4) at do_tdsignal+0x4b
tdsignal(c6a35640,2,0,c6a7f1e4,e3d9ba80) at tdsignal+0x4e
psignal(c6a7f1e4,2,c05ff66d,5c4,3) at psignal+0x5b
pgsignal(c69d3e80,2,1,1a9,c5) at pgsignal+0x59
ttyinput(3,c6712630,e3d9bc80,c669fa00,c0651c44) at ttyinput+0x362
ptcwrite(c663f900,e3d9bc80,7f0011,e3d9bb98,c062afe0) at ptcwrite+0x1a4
spec_write(e3d9bbe4,e3d9bc30,c0536322,e3d9bbe4,20002) at spec_write+0x183
spec_vnoperate(e3d9bbe4,20002,c669fa00,231,e3d9bc80) at spec_vnoperate+0x18
vn_write(c66993b8,e3d9bc80,c6893b80,0,c669fa00) at vn_write+0x1f2
dofilewrite(c669fa00,c66993b8,7,8085000,1) at dofilewrite+0xe9
write(c669fa00,e3d9bd14,c0611457,3ee,3) at write+0x6e
syscall(2f,2f,2f,807a200,807a248) at syscall+0x272
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4, FreeBSD ELF32, write), eip = 0x282ee1cf, esp = 0xbfbff3ac, ebp =
0xbfbff418 ---
db> call doadump
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
Dump complete
0xf
db> r
cpu_reset called on cpu#1
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 1
%%
The generated vmcore isn't usable unfortunately.
Here are the interesting parts of objdump -dS sys_pipe.o:
%%
00002330 <filt_piperead>:
/*ARGSUSED*/
static int
filt_piperead(struct knote *kn, long hint)
{
2330: 55 push %ebp
2331: 89 e5 mov %esp,%ebp
2333: 83 ec 1c sub $0x1c,%esp
2336: 89 5d f4 mov %ebx,0xfffffff4(%ebp)
2339: 89 75 f8 mov %esi,0xfffffff8(%ebp)
233c: 89 7d fc mov %edi,0xfffffffc(%ebp)
233f: 8b 75 08 mov 0x8(%ebp),%esi
struct pipe *rpipe = kn->kn_fp->f_data;
2342: 8b 46 34 mov 0x34(%esi),%eax
2345: 8b 58 0c mov 0xc(%eax),%ebx
struct pipe *wpipe = rpipe->pipe_peer;
2348: 8b bb 98 00 00 00 mov 0x98(%ebx),%edi
%%
The fault occurs due to rpipe/ebx being 0.
At this point I'm not sure whether this is a kqueue or a pipe bug.
Should I open a new PR for this panic?
Stefan
More information about the freebsd-bugs
mailing list