I'm working with a client on integrating a hardware driver for one of our
products (using the Hi/fn 7751 encryption processor) with a FreeS/WAN-based
IPSec stack. The problem I keep running into is when I send a packet to our
driver to be decrypted. Usually, when we send a request to our driver, the
request is sent to it and then put to sleep using add_wait_queue and
schedule(), and once the card is done processing the request, we hit a
callback and wake up the sleeping process. What I see happening when I call
our driver from inside the IPsec code (in klips/src/ipsec_rcv.c from
FreeS/WAN 1.5), we hit the callback *before* the card is done, followed by a
"Scheduling in interrupt" message, and a crash inside the scheduler:
ksymoops 2.3.4 on i586 2.2.18. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.18/misc/ (specified)
-m /System.map (specified)
Warning (compare_maps): mismatch on symbol zeroes , ipsec says c484bcc0,
/lib/modules/2.2.18/misc/ipsec.o says c484bb60. Ignoring
/lib/modules/2.2.18/misc/ipsec.o entry
Oops: 0002
CPU: 0
EIP: 0010:[<c0113df5>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010296
eax: 00000018 ebx: c0261ccc ecx: c02503fd edx: 00000001
esi: c0260000 edi: c028cf00 ebp: c0261cb4 esp: c0261c84
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=c0261000)
Stack: 00000010 00000286 c0261ccc 00000086 c2f5962c c01171a6 c2f59680
c39eec80
c2f5962c c2f59600 00000000 00000001 c0261cd4 c0114173 00000002
c39eec80
c2f5962c c2f59600 c0260000 c484a854 c2f59600 c482ecaf c2d99700
c0261e10
Call Trace: [<c01171a6>] [<c0114173>] [<c484a854>] [<c482ecaf>] [<c482e3aa>]
[<c484a840>] [<c0194700>]
[<c484a6e0>] [<c48164e0>] [<c017f737>] [<c48164e0>] [<c017f9dc>]
[<c48164e0>] [<c0178ef6>] [<c48164e0>]
[<c011bf19>] [<c0106000>] [<c010bed9>] [<c010bef0>] [<c010a948>]
[<c0106000>] [<c0107ec5>] [<c0106000>]
[<c010607c>] [<c0106000>] [<c01001ae>]
Code: c7 05 00 00 00 00 00 00 00 00 8d 65 d8 5b 5e 5f 89 ec 5d c3
>>EIP; c0113df5 <schedule+395/3ac> <=====
Trace; c01171a6 <printk+16e/17c>
Trace; c0114173 <interruptible_sleep_on+5b/a8>
Trace; c484a854 <[ipsec]esp_protocol+14/18>
Trace; c482ecaf <[ipsec]DEScrypto+297/32e>
Trace; c482e3aa <[ipsec]ipsec_rcv+150a/1b39>
Trace; c484a840 <[ipsec]esp_protocol+0/18>
Trace; c0194700 <fn_new_zone+f0/158>
Trace; c484a6e0 <[ipsec]dev_ipsec0+0/100>
Trace; c48164e0 <[ne]dev_ne+0/390>
Trace; c017f737 <ip_local_deliver+173/1c8>
Trace; c48164e0 <[ne]dev_ne+0/390>
Trace; c017f9dc <ip_rcv+250/280>
Trace; c48164e0 <[ne]dev_ne+0/390>
Trace; c0178ef6 <net_bh+1aa/208>
Trace; c48164e0 <[ne]dev_ne+0/390>
Trace; c011bf19 <do_bottom_half+89/ac>
Trace; c0106000 <get_options+0/7c>
Trace; c010bed9 <do_IRQ+3d/58>
Trace; c010bef0 <do_IRQ+54/58>
Trace; c010a948 <common_interrupt+18/20>
Trace; c0106000 <get_options+0/7c>
Trace; c0107ec5 <cpu_idle+41/54>
Trace; c0106000 <get_options+0/7c>
Trace; c010607c <init+0/144>
Trace; c0106000 <get_options+0/7c>
Trace; c01001ae <L6+0/2>
Code; c0113df5 <schedule+395/3ac>
00000000 <_EIP>:
Code; c0113df5 <schedule+395/3ac> <=====
0: c7 05 00 00 00 00 00 movl $0x0,0x0 <=====
Code; c0113dfc <schedule+39c/3ac>
7: 00 00 00
Code; c0113dff <schedule+39f/3ac>
a: 8d 65 d8 lea 0xffffffd8(%ebp),%esp
Code; c0113e02 <schedule+3a2/3ac>
d: 5b pop %ebx
Code; c0113e03 <schedule+3a3/3ac>
e: 5e pop %esi
Code; c0113e04 <schedule+3a4/3ac>
f: 5f pop %edi
Code; c0113e05 <schedule+3a5/3ac>
10: 89 ec mov %ebp,%esp
Code; c0113e07 <schedule+3a7/3ac>
12: 5d pop %ebp
Code; c0113e08 <schedule+3a8/3ac>
13: c3 ret
The questions I have, given all this, are:
1) Are schedule()-based functions (like sleep_on, wake_up, add_wait_queue,
etc.) safe to call from inside the networking code?
2) If not, is there a better way I could do this?
Thanks in advance for any help...
-lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 31 2001 - 21:00:25 EST