lkml.org 
[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDead lock in kill_fasync() in 2.4.0-test2
kill_fasync() in ../fs/fcntl.c is called on interrupt and also from
non-interrupt code. This causes the read_lock(&fasync_lock) to be (on
occasion) locked by the same processor.

Has this been fixed in later versions?

Here is the trace:
#0 0xc0157a1a in kill_fasync (fp=0xc12fb028, sig=29, band=131073) at
fcntl.c:400
#1 0xc01c4aae in handle_kbd_event () at pc_keyb.c:418
#2 0xc01c4bd3 in keyboard_interrupt (irq=12, dev_id=0xc12fb000,
regs=0xc44f9c58) at pc_keyb.c:488
#3 0xc010c24f in handle_IRQ_event (irq=12, regs=0xc44f9c58,
action=0xc78252e0) at irq.c:441
#4 0xc010c623 in do_IRQ (regs={ebx = -1053950720, ecx = 11, edx = 99,
esi = 1, edi = 11, ebp = -1001415528, eax = 0, xds = 24, xes = 24,
orig_eax = -244, eip = -1072643520, xcs = 16, eflags = 582,
esp = -1070740896, xss = 134}) at irq.c:595
#5 0xc010aa40 in ret_from_intr () at tulip_core.c:1456
#6 0xc010c623 in do_IRQ (regs={ebx = -1001422848, ecx = -999239680,
edx = 4094, esi = 514, edi = -1070901992, ebp = -1001415412,
eax = -1072334299, xds = 24, xes = 24, orig_eax = -245,
eip = -1072334279, xcs = 16, eflags = 514, esp = 0, xss =
-999239680})
at irq.c:595
#7 0xc010aa40 in ret_from_intr () at tulip_core.c:1456

For some reason gdb doesn't print the following line (but note eip above
-1072334279=0xc0157a39):
0xc0157a39 in kill_fasync (fp=0xc470d12c, sig=29, band=131073) at
fcntl.c:402
#8 0xc01bcfe8 in n_tty_receive_buf (tty=0xc470d000, cp=0xc44f9e7d "",
fp=0x0, count=0) at n_tty.c:737
#9 0xc01abd29 in pty_write (tty=0xc470c000, from_user=0, buf=0xc44f9e7c
".", count=1) at pty.c:180
#10 0xc01baaee in opost_block (tty=0xc470c000, inbuf=0x804ce8d ".",
nr=1) at n_tty.c:270
#11 0xc01be828 in write_chan (tty=0xc470c000, file=0xc497a960,
buf=0x804ce8d ".", nr=1) at n_tty.c:1125
#12 0xc01a8a02 in tty_write (file=0xc497a960, buf=0x804ce8d ".",
count=1, ppos=0xc497a980) at tty_io.c:699
#13 0xc0141715 in sys_write (fd=1, buf=0x804ce8d ".", count=1) at
read_write.c:156
#14 0xc010a974 in system_call () at tulip_core.c:1456
#15 0x8049c50 in ?? () at tulip_core.c:1456

This trace was obtained by putting debug code in the lock calls to check
for prior locks on lock and unlocked on unlocks. The machine is a
simple pentium II UP. The test load is from windows, in a shell window
run "ping -f add" where add is an up and nearby machine on the local
area net. Then all you have to do is move the focus (by using the
mouse) to another shell window. Fails very easily.

I would think that obtaining locks from interrupt code should be a
NO-NO. Is this not so? Or is the fact that is it a read lock a reason
to dismiss it? But even read locks are on a machine basis, not an
interrupt basis....

George

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.119 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site