Re: How to check if a spin lock has been freed or released?

I think you're misunderstanding Bill Paul's post. He's *not* making
assumptions, just providing useful information from his experiences in
writing a compatible NDIS for a different operating system and debugging
buggy NDIS drivers.

There is a *big* difference between understanding how things like spin locks
work "under the hood" so that you can better understand what happens if you
run into a situation where they are being misused, and relying on how they
are implemented in code you write. Bashing people for explaining this kind
of very valuable for tracking down problems and understanding bugs
(particularly in other people's code) information is absolutely the wrong
thing to do.

Yes, you're certainly right that if someone takes this knowledge and uses it
"for evil" and writes drivers that will break unless spinlocks are
implemented in this fashion, that's bad. But knowing how they really work
for things like debugging is certainly not bad, and neither is passing on
that knowledge to others. I think that Bill Paul has provided plenty of
clear warnings to not rely on these implementation details while writing
drivers too, so I'm not understanding your disagreement at all.

"Stephan Wolf [MVP]" <stewo68@xxxxxxxxxxx> wrote in message
news:1138452105.514524.67850@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Bill Paul wrote:
>> Unfortunately, people _do_ make assumptions. Developers assume that
>> they're writing Windows drivers, not NDIS drivers.
>
> Hmm, well, it would seem it is not the poeple but *you* who is making
> assumptions. Both on NDIS as well as on if or how other people make
> assumptions.
>
> One thing a chief developer I worked for taught me was "programming
> errors are *always* the result of false assumptions." Think of it a
> little. It has turned out to be true for me during the last 15 years.
>
>> They make coding
>> mistakes when writing their NDIS drivers and yet they assume everything
>> is fine because the existing Windows NDIS implementation lets them
>> get away with it. And one could argue Microsoft has made the same
>> assumptions since it doesn't instrument the NdisFreeSpinLock() routine
>> so that driver verifier can catch these mistakes.
>
> Right.
>
>> Yes, I know NDIS was supposed to be platform-independent. Novell Netware
>> was another one of the OSes that supported it. But right now, there's
>> only one NDIS implementation in common use, and that's the one Microsoft
>> is shipping in Windows 2K/XP/2K3.
>
> Well, some (if not many) people still use ME/98/95 based Windows. Also,
> Windows CE is widely used in embedded systems.
>
>> There's another class of potential error here, by the way. I also ran
>> across one driver that would do an NdisAllocateSpinLock() in its
>> DriverEntry() routine, and then do NdisFreeSpinLock() in its
>> MiniportHalt()
>> routine. Presumeably the spinlock was designed to guard data that was
>> global across all adapter instances created by the driver. The problem of
>> course is that MiniportHalt() can be called repeatedly once the driver
>> is loaded, so the result is a spinlock that's created only once but
>> destroyed many times. Since NdisAllocateSpinLock() doesn't actually
>> allocate anything, and since NdisFreeSpinLock() is a no-op, the bug ends
>> up being harmless (on Windows NT/2K/XP/2K3), except insofar as it doesn't
>> discourage the developer from writing sloppy code.
>
> Exactly. IIRC, however, in Windows CE, NdisFreeSpinLock() *does*
> actually do something, i.e. it is not a no-op.
>
> Sure the NdisAllocateSpinLock()/NdisFreeSpinLock() either should be in
> DriverEntry()/UnloadHandler() (the latter can be registered by
> NdisMRegisterUnloadHandler()) or it should be in
> MiniportInitialize()/MiniportHalt().
>
> Still I would not make any assumptions on how NDIS functions are
> actually implemented. AFAIK, there even exists a NDIS Wrapper for x86
> Linux, which enables Windows NDIS miniport drivers (binary file) to run
> under x86 Linux. You assumptions on spinlocks probably fail for this
> scenario.
>
> More, it was common to have binary compatible NDIS miniport drivers for
> all of W95/W98/WME/NT4/W2K until MS added some incompatible features
> (see also http://www.wd-3.com/031504/NDISCompile.htm).
>
> Stephan
>


.

Relevant Pages

  • Re: Running NDISTest on Vista with an NDIS IM Driver
    ... Currenty there are no logo programs or tests that test any NDIS IM drivers. ... I tried using the version that comes with WLK/DTM on PassThru (NDIS IM ... Loaded Module Info: ...
    (microsoft.public.development.device.drivers)
  • Re: How to check if a spin lock has been freed or released?
    ... >> they're writing Windows drivers, ... Both on NDIS as well as on if or how other people make ... I think you assumed that I'm a Windows driver developer. ... I said that I wrote the FreeBSD NDIS emulator (or "NDIS ...
    (microsoft.public.development.device.drivers)
  • Re: ndis with USB wifi dongle - no joy
    ... No ndis interface is created, and dmesg shows the following messages: ... Windows NDIS device drivers work because the co-called Project Evil is ...
    (freebsd-questions)
  • Re: How to check if a spin lock has been freed or released?
    ... > they're writing Windows drivers, ... Both on NDIS as well as on if or how other people make ...
    (microsoft.public.development.device.drivers)
  • Re: Need Advice
    ... Filter-hook drivers only allow one to be registered. ... Write NDIS IM. ... what would you recomand me to use in making an effective firewall. ... I am not a complete newbe but I do not have proper documentation. ...
    (microsoft.public.win32.programmer.kernel)