Don
Thu Sep 07 17:27:27 CDT 2006
No, I am referring to a routine normally called at DISPATCH_LEVEL that takes
a lock, and which an individual forgot was for DISPATCH and called from his
ISR. This was a purely unitentional mistake, that happened to work just
fine on an SMP, but not on a uni-processor.
--
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@hotmail.com> wrote in message
news:1157667798.504670.23420@i42g2000cwa.googlegroups.com...
> Hi Don
>
> In fact, I thought we were speaking about accidentally forgetting that
> the routine, called by ISR, deals with spinlocks. However, what you
> have mentioned in your latest post is already from the totally
> different field - you mentioned the scenario of synchronizing some
> routine with ISR by means of spinlock, rather than of
> KeSynchronizeExecution(). This is the classical example of intentional
> improper design, rather than of accidental bug .
>
> However, I made it clear that my statement does not cover intentional
> "unsupported" strategies - after all, if you intentionally go for
> something "unsupported" you have to know what you are doing (and, at
> this point, you may ask yourself whether you really want to do it). In
> this particular case, the routine that you want to synchronize with ISR
> has to check how many CPUs are there, i.e. do something like
>
> if(*KeNumberOfProcessors==1) KeRaiseIrql (IRQL >=the one ISR runs
> at,...);
> else KeAcquireSpinlock(...);
>
> If you do it it this way, your code will be able to run on SMP machine,
> UP one plus UP machine with MP HAL installed. Certainly, this is still
> improper design (after all, you make code that runs at DIRQL "wait" for
> the one that runs at DISPATCH_LEVEL, which is just stupid thing to do),
> but it will work
>
> 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@hotmail.com> wrote in message
>> news:1157659623.530224.278180@m73g2000cwd.googlegroups.com...
>> > 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@hotmail.com> wrote in message
>> >> news:1157640287.046142.16480@i42g2000cwa.googlegroups.com...
>> >> > 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@hotmail.com> 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
>> >> >
>> >
>