Lenny -
I was wondering if we could get a time to talk about reqcom, dkdriver's
internal looping, and what to do about them?

Tom Coughlan wanted to be in on it too, if he's available btw.

The issue, you'll recall, is the fact that reqcom recursively
calls driver start_io and can overflow kernel stack, and that dkdriver
loops internally to avoid this.

Currently the best way to avoid this looks to me to be something along
the lines of

1. Test that the stack isn't "too close" to the base of its page. If it
is far enough above it, just continue to use it. (My bogey has been a
pagelet.)

2. If the stack is in the bottom of its current page, call EXE$GET_STACK_LIMIT
to get the limit. If enough above the limit, continue to use the current
SP. Otherwise, fork. Then call start_io from the fork routine, which will
ensure that you're running with the kernel stack cleared off.

The EXE$GET_STACK_LIMIT routine has been around since 1991 and is
well behaved for speed except that it uses DSBINT  ENVIRON=UNIPROCESSOR 
and the corresponding ENBINT, which are PAL calls.

The routine is supposed to be callable from any mode or IPL, which is
probably the reason for using IPL 31. 

What I'd like general opinion on is whether a copy of the routine
might be used for this purpose that, knowing it's always running from
fork, doesn't bother going to IPL 31 for its FIND_CPU_DATA call.

I find in the sys facility that DEADLOCK.MAR is the only place that
calls this routine, BTW, and in [sysloa] it's called from DSTRDLCK.MAR
(which is quite similar in function). Nothing else seems to touch it...
not drivers, not lan, not scsi...

I've put together dkdriver and iosubnpag versions with the logic
outlined above in them and tried some back/phy/nocrc to stress the
disks without trouble (writing to nla0:). If of course it's possible to
have a fromfork_get_stack_limit routine that doesn't mess with IPL,
that would be still less overhead.

I'd like to get this seen to though, since I need it for multipath, and
I'd like to get it dealt with.

(Your opinions about whether my IRP extend scheme looks doable would
also be most welcome; I'd really like to avoid having to use other 
structures if possible, as would EDO...)


I can make most any time tomorrow or next week. Tomorrow's better for Tom
I think.
glenn everhart