Date: Sun, 5 Jul 1998 23:53:46 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: HEADS UP: Sleeping in strategy routines? Message-ID: <Pine.BSF.3.95.980705234049.11949A-100000@current1.whistle.com> In-Reply-To: <19980706145310.C6528@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Jul 1998, Greg Lehey wrote:
> 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
I don't think you asked me, or I wasn't thinking..
you can't call strategy from interupt level... (e.g. biodone())
but you seem to have noticed this :-)
strategy is a top level routine, called directly from
read->physio->strategy.
there are other things you can do of course, but they really depend on
having everything preallocated.
> #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.
I wouldn't expect to call strategy from that level.
> 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).
yes, but strategy is suppoosed to allocate resources needed for a
transfer. It is conceivable that to do so may require sleeping.
I personally would expect this. Maybe I'm in the minority. From my
perspective the whole reason for having strategy and start separated
in the way they are is to divide top/bottom operation.
>
> 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?
strategy expects to be called and to return to the caller, having done
all that is needed to queue the work. This may require waiting on
a structure to become 'unbusy' (for example).
In practice it is nearly always possible to avoid
sleeping in there, but I think making it 'illegal' would
limit the flexibility for other users.
On the other hand, it is possible that some people feel that strategy
shouldn't sleep and that this is the reason that physio()
sleeps rather than letting the strategy to do so.
>
> 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
>
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?Pine.BSF.3.95.980705234049.11949A-100000>