Re: WinXPSP2, Intel Core2Duo, Kernel drivers

Hi Don

In fact, this bug has a chance to reveal itself on the MP system as
well (after a bit of thinking I realized that your example is not
so-well suited for MP machines either, although it is not so obvious at
the very first glance). Consider the following scenario:

1. CPU1 obtains a spinlock
2. Interrupt occurs, and gets dispensed to CPU1, rather than CPU2

What is going to happen if the above scenario occurs???? ISR that runs
on CPU1 will try to acquire the spinlock that CPU1 has already
acquired. As a result, CPU1 starts spinning in infinite loop at DIRQL,
and there is nothing that can terminate this loop

To be honest, I cannot tell you how the system will react, but I
believe BSOD is due pretty shortly.....

Anton Bassov



Don Burn wrote:
Because on an SMP machine CPU 1 will get the lock, then an interrupt occurs
on CPU 2 and it will spin when it calls the routine until CPU 1 is finished,
but if this is a uni-processor, the lock is taken, the interupt occurs, the
interupt executes through the code, and then the returns with the processor
finishing the code under the lock. If this is for instance a lock to
protect insertion into a linked list, you can have a totally messed up list
with the forward link of A pointing to B whose back link points to C.

This is because KeAcquireSpinLockAtDpcLevel on a uni-processor is a NOP.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



<soviet_bloke@xxxxxxxxxxx> wrote in message
news:1157659623.530224.278180@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Don

Sorry, it was early the instance I was thinking of was
KeAcquireSpinLockAtDpc.

But why should KeAcquireSpinLockAtDpcLevel() pose problems???? After
all, it does not try to modify IRQL

Anton Bassov


Don Burn wrote:
Sorry, it was early the instance I was thinking of was
KeAcquireSpinLockAtDpc. This code was done by a very good developer who
is
now a respected member of the Windows driver community (and not me).


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply


<soviet_bloke@xxxxxxxxxxx> wrote in message
news:1157640287.046142.16480@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Don

For instance, if you forget that a routine uses
spinlocks and then accidently call it from your ISR, it may very well
work
on an SMP system because the spinlock is an actual test and set, but
it
has
terrible consequences on a UP system where it becomes a NOP since the
IRQL
is above DISPATCH_LEVEL.

Trying to call the routine that uses spinlocks from ISR is not going to
work fine on
MP system either. Let's look at how MP HAL obtains spinlocks - the code
below is implementation of KeAcquireSpinLock() from halmacpi.dll


80012830: mov edx,dword ptr ds:[FFFE0080h]
80012836: mov dword ptr ds:[FFFE0080h],41h
80012840: shr edx,4
80012843: movzx eax,byte ptr [edx+8001D218h]

8001284A: lock bts dword ptr [ecx],0
8001284F: jb 80012854
80012851: ret

As you can see, the very first step KeAcquireSpinLock() does is
UNCONDITIONALLY(!!!)writing 0x41 to the Task Priority Register, i.e.
setting IRQL to DISPATCH_LEVEL, and then proceeds to set and test.
KeAcquireQueuedSpinLock() behaves in similar fashion. Therefore,
calling these functions at IRQL>DISPATCH_LEVEL is quite unwise thing to
do - even on MP HAL.

Anton Bassov




Don Burn wrote:
<soviet_bloke@xxxxxxxxxxx> wrote in message
Well, you can think of my examples as of ones of the bugs if you
wish -
no matter how you call them, these are the examples of doing
something
you are not supposed to do, which may have undesirable effects
(unless
you are 100% sure you know what you are doing)

Yes they are doing something you are not supposed to do, that is a
pretty
good definition of a bug. For instance, if you forget that a routine
uses
spinlocks and then accidently call it from your ISR, it may very well
work
on an SMP system because the spinlock is an actual test and set, but
it
has
terrible consequences on a UP system where it becomes a NOP since the
IRQL
is above DISPATCH_LEVEL.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



.

Relevant Pages

  • Can I call KeAcquireSpinLockAtDpcLevel at DISPATCH_LEVEL?
    ... Can I call KeAcquireSpinLockAtDpcLevel at DISPATCH_LEVEL? ... that it is made exactly for acquiring a spinlock at DISPATCH_LEVEL), ... Never wait on a kernel dispatcher object for a nonzero interval at ... If SpinLocks are not considered "kernel dispatcher objects", ...
    (microsoft.public.development.device.drivers)
  • Re: How to check if a spin lock has been freed or released?
    ... lessen the number of hardware able to run Windows). ... For Linux and FreeBSD, this can be ... > bugs like NdisFreeSpinLock() misuse would show up immediately during ... KeRaise/LowerIrql, as it is done in uniprocessor NT kernels, but the spinlock ...
    (microsoft.public.development.device.drivers)
  • Re: Defender unexpected error 0x8050800c
    ... I keep getting Error 0x8050800f - is this the same error that spinlock is ... realtime protection facility should continue to work, ... Microsoft MVP [Windows XP Shell/User] ... Windows® XP Troubleshooting http://www.winhelponline.com ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Can I call KeAcquireSpinLockAtDpcLevel at DISPATCH_LEVEL?
    ... More so - DISPATCH_LEVEL is a must for KeAcquireSpinLockAtDpcLevel. ... interrupt spinlock is the only chance. ... Spinlock is not a dispatcher object. ... Waiting on a spinlock stalls the CPU in a dead loop. ...
    (microsoft.public.development.device.drivers)
  • Re: W2K3 - Looking for ATAPI.SYS 4-28-2003 with ResetErrorCountersOnSuccess Registry Key
    ... Dave Patrick ....Please no email replies - reply in newsgroup. ... Microsoft MVP [Windows] ... "spinlock" wrote: ...
    (microsoft.public.windows.server.general)
Loading