Re: Races in power IRP handling path.

[Paul Durrant <xadimgnik@xxxxxxxxx>]

On 12/10/2022 13:11, Martin Harvey wrote:
> Okay. Well, if no-one else is covering the outstanding power issues (there are 
> a few bugchecks down the powerdown / hibernation path) then I'll address them 
> as follows:
>
> - Some revisions of the OS may have had a system power thread / and a device 
> power thread per stack, we shouldn't need to replicate that bit of structure in 
> our drivers (none of the others do).
> - It should be possible to handle power IRP's with standard dispatch and completion 
> routines most of the time. Only reason I can see to farm the work off into a separate 
> thread is if the IRQL is not suitable. In such cases, Marking IRP pending with later 
> completion should be fine, exception being blocking power-irps, where we have to 
> "continue" a completion chain. Since we can't fail power IRP's could always 
> succeed these, and pass off the real work into a work item.
> - Issues with completions not being called - perhaps multiple drivers marking 
> as pending down the stack? Hopefully an async model will help  this. I will 
> need to remove the xenfilt handling to get to the bottom of what's going on 
> here.
> - I'll have to rewrite the FDO handling before the bus drivers (I'm afraid). 
> This might or might not fix all the outstanding bugchecks (prob not).
> - An asynchronous / state driver model is to be far preferred to synchronous 
> passdown.
>
> MH.
I would very much prefer that we kept the power (and pnp) IRP handling 
as it is. It took *years* to debug this stuff and using threads for 
power IRPs was largely because there were too many mind-bending corner 
cases to do it reliably any other way.
If there are specific bugs then let's fix them with as little 
re-structuring as possible.
  Paul