In Walter Oney’s driver programming book, the author mentions that even
the best cancelation logic is flawed due to a rare coincidence in pointer
values. I was wondering if anyone can explain that in more detail.
Thanks.
Joe Black
Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434
Promote security and make money with the Hushmail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427
I would read the NTInsider article on cancel. It can be found at
www.osronline.com. Search for The Truth About Cancel - IRP Cancel
Operations .
–Mark
–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
wrote in message news:xxxxx@ntdev…
> In Walter Oney’s driver programming book, the author mentions that even
> the best cancelation logic is flawed due to a rare coincidence in pointer
> values. I was wondering if anyone can explain that in more detail.
>
> Thanks.
>
> Joe Black
>
>
>
>
> Concerned about your privacy? Follow this link to get
> FREE encrypted email: https://www.hushmail.com/?l=2
>
> Free, ultra-private instant messaging with Hush Messenger
> https://www.hushmail.com/services.php?subloc=messenger&l=434
>
> Promote security and make money with the Hushmail Affiliate Program:
> https://www.hushmail.com/about.php?subloc=affiliate&l=427
>
On Mon, 2004-02-09 at 07:32, Mark Cariddi wrote:
wrote in message news:xxxxx@ntdev…
> > In Walter Oney’s driver programming book, the author mentions that
even
> > the best cancelation logic is flawed due to a rare coincidence in
pointer
> > values. I was wondering if anyone can explain that in more detail.
>
> I would read the NTInsider article on cancel. It can be found at
> www.osronline.com. Search for The Truth About Cancel - IRP Cancel
> Operations
That article doesn’t mention the race Oney refered to. Does that mean
that this logic is definitely not flawed, or that you don’t know if it
is?
Also, I have a question about another possible race in your code. In
part 2, you list three scenarios, and refer to #1 as “not optimal”, saying
that your cancel routine will never run. You’re right, the way that
it is coded, and the IRP is in limbo until the driver gets around to
completing it normally.
Instead of doing things that way, if you set a cancel routine, queued
the irp, and then tested the cancel flag, one of two things will be true.
If the flag is true, the IO manager has tried to cancel you, so you
set a null cancel routine and see if it returns null. If it does, your
cancel routine is already running (waiting on your queue lock), so you
can let it go, comfortable that it will be completed. If you get back
a cancel routine, you de-queue the IRP and complete it yourself.
Is there a flaw in that logic?
Also, you mention testing the cancel flag is useless due to another race.
That’s true, but couldn’t you set a null cancel routine, as I described
above, to know for sure whether or not your routine is already running
elsewhere? It doesn’t seem lik holding the cancel lock makes much sense
given that method. Of course, all this depends on the cancel routine
exchanging as an atomic operation, which it looks like is the case, at
least on x86 (ref ntddk.h).
Anyway, this seems to me to close that phase 1 cancel race you refer
to in part 2.
Joe
Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434
Promote security and make money with the Hushmail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427