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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |