On Tue, 2005-09-06 at 21:59 -0400, Mark Lord wrote: > Daniel Phillips wrote: > > There are only two stacks involved, the normal kernel stack and your new > > ndis > > stack. You save ESP of the kernel stack at the base of the ndis stack. > > When > > the Windows code calls your api, you get the ndis ESP, load the kernel ESP > > from the base of the ndis stack, push the ndis ESP so you can get back to > > the > > ndis code later, and continue on your merry way. > > With CONFIG_PREEMPT, this will still cause trouble due to lack > of "current" task info on the NDIS stack. > > One option is to copy (duplicate) the bottom-of-stack info when > switching to the NDIS stack. > > Another option is to stick a Mutex around any use of the NDIS stack > when calling into the foreign driver (might be done like this already??), > which will prevent PREEMPTion during the call.
Isn't it bad to rely on taking a lock disabling preemption as a side effect? For example it will break on PREEMPT_RT (not merged yet, but still...). If you really just need preemption disabled/reenabled can't you just do it explicitly? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
