Re: IoSkipCurrentIrpStackLocation() design flaw?
- From: "Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 17 Sep 2006 23:12:55 -0700
the idle code is lock and state free which is why this error can happen.
the idle unregister call, if made at the exact right time can not
successfuly unregister b/c a power irp is about to be sent and there is no
way to handle the race. this is why the PPO for the stack needs to handle
the transition on its own.
i am answering maxim's original question. device and wait wake power irps
are not synchronized with pnp state changing orips. system power irps are
synchronized against pnp state changing irps. all the usual issues about
handling i/o after remove and draining for remove still apply to the power
irps, i am just pointing out how they are sent to the stack in relation to
its own state.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
<BubbaGump> wrote in message
news:dbcsg2pfbois0hvflpiab028shn2von2nr@xxxxxxxxxx
Shouldn't any IRP that arrives after IRP_MN_REMOVE_DEVICE be completed
safely with error status because the receiving driver can no longer
acquire its device's remove lock, and shouldn't IRPs be able to arrive
during and after IRP_MN_REMOVE_DEVICE as long as the entity sending
them has a reference to the receiving driver's device? That is, even
though a remove makes a driver non-functional, the driver's code
(including its dispatch routine) can't be unloaded from memory until
all references to it are released.
I guess an idle unregister would communicate with that sending entity
to release that reference, but wouldn't it do so under the protection
of a lock that would make sure the entity wasn't currently in a call
to the receiving driver's dispatch routine?
On Sun, 17 Sep 2006 22:20:28 -0700, "Doron Holan [MS]"
<doronh@xxxxxxxxxxxxxxxxxxxx> wrote:
it is not completion here, it is arrival after IRP_MN_REMOVE_DEVICE.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.
<BubbaGump> wrote in message
news:7gerg2ljfbjj90e9uep8m96mnj9pbohato@xxxxxxxxxx
I don't understand what the problem is here. Even if the device is
unregistered, what stops the power IRP from being completed just like
any other power IRP?
On Sun, 17 Sep 2006 13:35:17 -0700, "Doron Holan [MS]"
<doronh@xxxxxxxxxxxxxxxxxxxx> wrote:
and that is why idle detection through the NT apis is totally busted. it
creates a state transition outside of the driver's control. to do idle
correctly, it needs to be implemented by the driver. i learned this
lesson
very thoroughly when implementing idle detection in KMDF
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Maxim S. Shatskih" <maxim@xxxxxxxxxxxxxxxx> wrote in message
news:%23Nk6BPk2GHA.4796@xxxxxxxxxxxxxxxxxxxxxxx
Idle detection power IRPs are out of the PPO's control. The PPO can
unregister the device from idle detection, but the D power IRP
initiated
by
this idle detection mechanism is active.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@xxxxxxxxxxxxxxxx
http://www.storagecraft.com
.
- References:
- Re: IoSkipCurrentIrpStackLocation() design flaw?
- From: Maxim S. Shatskih
- Re: IoSkipCurrentIrpStackLocation() design flaw?
- From: Doron Holan [MS]
- Re: IoSkipCurrentIrpStackLocation() design flaw?
- From: Maxim S. Shatskih
- Re: IoSkipCurrentIrpStackLocation() design flaw?
- From: Doron Holan [MS]
- Re: IoSkipCurrentIrpStackLocation() design flaw?
- From: Doron Holan [MS]
- Re: IoSkipCurrentIrpStackLocation() design flaw?
- Prev by Date: Re: Can I get the driver's INF file path from its Device ID?
- Next by Date: Limiting instace to One of Av-Stream Device Driver
- Previous by thread: Re: IoSkipCurrentIrpStackLocation() design flaw?
- Next by thread: Re: IoSkipCurrentIrpStackLocation() design flaw?
- Index(es):
Relevant Pages
|
Loading