From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 26 Jan 2001 11:10:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 26 Jan 2001 11:10:30 -0500 Received: from www.gtgi.com ([209.183.204.34]:233 "EHLO www.gtgi.com") by vger.kernel.org with ESMTP id ; Fri, 26 Jan 2001 11:10:22 -0500 From: "Lee Cremeans" To: , Subject: IPSec stack and calling a hardware driver using sleep_on/wake_up Date: Fri, 26 Jan 2001 11:09:07 -0500 Message-ID: <000d01c087b2$4fd288e0$0500a8c0@fw.gtgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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:[] 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: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: c7 05 00 00 00 00 00 00 00 00 8d 65 d8 5b 5e 5f 89 ec 5d c3 >>EIP; c0113df5 <===== Trace; c01171a6 Trace; c0114173 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 Trace; c484a6e0 <[ipsec]dev_ipsec0+0/100> Trace; c48164e0 <[ne]dev_ne+0/390> Trace; c017f737 Trace; c48164e0 <[ne]dev_ne+0/390> Trace; c017f9dc Trace; c48164e0 <[ne]dev_ne+0/390> Trace; c0178ef6 Trace; c48164e0 <[ne]dev_ne+0/390> Trace; c011bf19 Trace; c0106000 Trace; c010bed9 Trace; c010bef0 Trace; c010a948 Trace; c0106000 Trace; c0107ec5 Trace; c0106000 Trace; c010607c Trace; c0106000 Trace; c01001ae Code; c0113df5 00000000 <_EIP>: Code; c0113df5 <===== 0: c7 05 00 00 00 00 00 movl $0x0,0x0 <===== Code; c0113dfc 7: 00 00 00 Code; c0113dff a: 8d 65 d8 lea 0xffffffd8(%ebp),%esp Code; c0113e02 d: 5b pop %ebx Code; c0113e03 e: 5e pop %esi Code; c0113e04 f: 5f pop %edi Code; c0113e05 10: 89 ec mov %ebp,%esp Code; c0113e07 12: 5d pop %ebp Code; c0113e08 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/