Re: MiniportReturnPacket() not getting called in NT D eserialized miniport Driver

OSR_Community_User · February 22, 2002, 4:12pm

> The missing part is that in a deserialized driver,

MiniportReturnPacket() can be called even before
NdisMIndicateReceivePacket() returns! That is, the packet passed up
might have been returned to the Miniport before it has a chance to
inspect the ‘Status’ member of any packet. The packet’s memory might
even have been freed already - boom!

You can set the packet’s status to NDIS_STATUS_RESOURCES before indicating the packet to prevent this from occurring (this is documented in the XP DDK).

Regards,

Ed Lau
MidCore Software, Inc.
900 Straits Tpke
Middlebury, CT 06762

www.midcore.com
----- Original Message -----
From: Michal Vodicka
To: NT Developers Interest List
Sent: Friday, February 22, 2002 3:29 PM
Subject: [ntdev] Re: MiniportReturnPacket() not getting called in NT D eserialized miniport Driver

Stephan,

for w2k+ is it exactly as you say. For NT4, there is a difference. SP3+
*supports* deserialized drivers but implementation differs from w2k and of
course also from w2k DDK docs. The situation is as Ed desribed; you have to
check packet status after call to NdisMIndicateReceivePacket(). Yes, there
are race conditions as you stated but it is unfortunately the only way
because MiniportReturnPacket isn’t called for other than pending packets. If
I remember correctly, I tested it and found that problem doesn’t occur on
NT4. Also, our customers never reported problem with this driver

Ah, I agree that concept is dangerous and should be designed better

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, February 22, 2002 6:17 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: MiniportReturnPacket() not getting called in NT
Deserialized miniport Driver

Caution: The whole concept of NdisMIndicateReceivePacket() as well as
MiniportSendPackets() is IMHO dangerous. I reported to MS immediately
when they invented it. They didn’t realize I was right but changed
docs as well as functionality when they catched up.

The problem is that people get a wrong idea of how how things work
here.

When you pass up a packet to NdisMIndicateReceivePacket(), the packet
is out of your Miniport’s control. You actually release “ownership” of
the packet until NDIS passes the packet back to you.

Now when does NDIS pass you back “ownership” of the packet?

When NDIS calls MiniportReturnPacket(), the packet is clearly
re-owned by the Miniport. No doubt about it.

When the NdisMIndicateReceivePacket() call returns, the Miniport
shall inspect the ‘Status’ of each packet. If it’s PENDING, then NDIS
still owns the packet. Otherwise, the Miniport already owns the packet
again and MiniportReturnPacket() will not be called.

The missing part is that in a deserialized driver,
MiniportReturnPacket() can be called even before
NdisMIndicateReceivePacket() returns! That is, the packet passed up
might have been returned to the Miniport before it has a chance to
inspect the ‘Status’ member of any packet. The packet’s memory might
even have been freed already - boom!

MS finally also realized this and changed the docs to say that
deserialized Miniports must not check the packet ‘Status’ after a call
to NdisMIndicateReceivePacket().

Now if you’re running on NT4 with an NDIS.SYS that does *not* support
deserialized, NDIS handles your Miniport as “serialized” but you think
you’re actually running deserialized. Because you set the
NDIS_ATTRIBUTE_DESERIALIZE flag, which NDIS ignores. And the conflict
is exactly that you think you do not need to or even must not inspect
the ‘Status’ while NDIS expects you to.

I hope you understand what I’m saying. This isn’t trivial, I know.

Stephan

On Fri, 22 Feb 2002 08:31:09 -0800, “Ed Reed”
wrote:
>
> >I ran into this problem as well in my NDIS Intermediate driver. I found
> the
> >answer in the ImSamp sample driver. It looks like there was a change made
> >between NDIS 4 and NDIS 5 with regards to NdisMIndicateReceivePacket().
> >Under NDIS 4, you need to check the packet status AFTER the call to
> >NdisMIndicateReceivePacket(). If the packet status is anything but
> >NDIS_STATUS_PENDING, no upper-level protocol has retained the packet and
> you
> >must dispose (or recycle) it appropriately. Your MiniportReturnPacket()
> >function will only be called if the packet status is NDIS_STATUS_PENDING
> >AFTER the call to NdisMIndicateReceivePacket().
> >
> >Again this is different behavior is different from the NDIS 5 behavior
> where
> >the packet status after the call to NdisMIndicateReceivePacket() is
> >irrelevant.
> >
> >–
> >Ed Reed mailto:xxxxx
> >Connectix Corporation
> >
> >“Anandhi” wrote in message news:xxxxx@ntdev…
> >
> >
> >Hi all,
> >
> >I face the same problem as Gopikrishna. but I don’t see any replies to
> his
> >mail. Gopikrishna did U find a way out ?
> >
> >Devs, any suggestions ?
> >
> >Regards
> >Anandhi
> >
> >
> >Hi,
> >
> >I have a problem in Deserialized miniport NIC driver in
> >Windows NT of MiniportReturnPacket() not getting called.
> >Before calling the NdisMIndicateReceivePacket() the status is set to
> >NDIS_STATUS_SUCCESS.
> >
> >As per the DDK for Win 2000 (NDIS 5), all the packet descriptors are
> >returned by NDIS to Miniport driver through MiniportReturnPacket()
> function.
> >But the MiniPortReturnPacket() is never getting called for our driver.
> >
> >We are assuming that the behavior in case of deserialized driver in WinNT
> >(NDIS 4) is identical to the above.
> >
> >
> >
> >Can anybody give some pointers for this problem ? Does anybody have the
> >documentation for NDIS4 deserialized driver.
> >
> >
> >
> >Thanx
> >Gopikrishna
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: xxxxx@midcore.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</mailto:xxxxx>