Date: Mon, 6 Jul 1998 14:53:10 +0930 From: Greg Lehey <grog@lemis.com> To: FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: HEADS UP: Sleeping in strategy routines? Message-ID: <19980706145310.C6528@freebie.lemis.com>
next in thread | raw e-mail | index | archive | help
At USENIX I discussed the idea of calling block^H^H^H^H^H device
strategy routines from the bottom half of a driver, and the general
consensus was yes, you can do this. I've just had a panic which seems
to point to other problems. Here's the trace:
Program received signal SIGSEGV, Segmentation fault.
tsleep (ident=0xf0278964, priority=0x10, wmesg=0xf01f7536 "bncwai", timo=0x0) at ../../kern/kern_synch.c:374
374 if (KTRPOINT(p, KTR_CSW))
(kgdb) bt
#0 tsleep (ident=0xf0278964, priority=0x10, wmesg=0xf01f7536 "bncwai", timo=0x0) at ../../kern/kern_synch.c:374
#1 0xf01f75b3 in vm_bounce_page_find (count=0x1) at ../../i386/i386/vm_machdep.c:160
#2 0xf01f7be7 in vm_bounce_alloc (bp=0xf0783018) at ../../i386/i386/vm_machdep.c:397
#3 0xf01bae01 in sd_strategy (bp=0xf0783018, sc_link=0xf075dd80) at ../../scsi/sd.c:623
#4 0xf01b792c in scsi_strategy (bp=0xf0783018, device=0xf025333c) at ../../scsi/scsi_driver.c:220
#5 0xf01ba804 in sdstrategy (bp=0xf0783018) at ../../scsi/sd.c:173
#6 0xf01494de in spec_strategy (ap=0xf024ae2c) at ../../miscfs/specfs/spec_vnops.c:557
#7 0xf0148bc9 in spec_vnoperate (ap=0xf024ae2c) at ../../miscfs/specfs/spec_vnops.c:127
#8 0xf01cb6f1 in ufs_vnoperatespec (ap=0xf024ae2c) at ../../ufs/ufs/ufs_vnops.c:2282
#9 0xf430a04f in VOP_STRATEGY (bp=0xf0783018) at vnode_if.h:1100
#10 0xf4309fd8 in complete_raid5_write (rqe=0xf0783018) at raid5.c:767
#11 0xf4307ae0 in complete_rqe (bp=0xf0783160) at request.c:797
#12 0xf0137d52 in biodone (bp=0xf0783160) at ../../kern/vfs_bio.c:1912
#13 0xf01b6954 in scsi_done (xs=0xf07b9000) at ../../scsi/scsi_base.c:448
#14 0xf01f924b in aha_done (aha=0xf075f000, ccb=0xf075fa64) at ../../i386/isa/aha1542.c:945
#15 0xf01f8d39 in ahaintr (unit=0x0) at ../../i386/isa/aha1542.c:751
(kgdb) l
369 struct proc *p = curproc;
370 int s, sig, catch = priority & PCATCH;
371 struct callout_handle thandle;
372
373 #ifdef KTRACE
374 if (KTRPOINT(p, KTR_CSW))
375 ktrcsw(p->p_tracep, 1, 0);
376 #endif
377 s = splhigh();
378 if (cold || panicstr) {
(kgdb) p p
$1 = (struct proc *) 0x0
I can't make up my mind whose fault this is. If it's true that you
should be able to call a strategy routine from the lower half, then
vm_bounce_page_find shouldn't be tsleeping. But so far this is an
assertion, even if it's shared by others. On the other hand, I've
been working quite happily with this driver (well, I haven't run into
problems like this :-) until I changed to a system with more than 16
MB of memory and didn't change the controller (AHA 1542, as the trace
shows).
This really boils down to a policy question: should strategy routines
do anything that requires a process context? Do *you* have code which
relies on being in a process context?
Greg
--
See complete headers for address and phone numbers
finger grog@lemis.com for PGP public key
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980706145310.C6528>