Could calling IoReleaseCancelSpinLock twice in a row be bad?

NTDEV
1

We just found a bug today and we’ll fix it, but we have to decide if it’s
worth creating a hotfix for our customers. We’re just about to release the
product, and it has passed QA without any problems, but since it hasn’t gone
to the field, we don’t have a huge amount of bake time that would enable us
to assess it better. So, I’m looking for some advice.

The bug is that we end up executing code that looks basically like this:
IoAcquireCancelSpinLock(&oldIrql);
// stuff
IoReleaseCancelSpinLock(oldIrql);
IoCompleteRequest(CurrentIrp, IO_NO_INCREMENT);
IoReleaseCancelSpinLock(oldIrql);

Namely, IoReleaseCancelSpinLock is getting called twice.

Now of course, we’ll remove the second call for the future releases. But
does it REALLY hurt anything? If not, then we won’t do a hotfix, and if so,
then we would.

Looking at the assembly, it looks like all IoReleaseCancelSpinLock actually
does is:
IoSavedCancelCaller = NULL;
KeLowerIrql (oldIrql);

I know that calling KeLowerIrql twice with the same IRQL value won’t hurt
anything on a single-processor machine (I don’t know if it would on a
multi-pocessor, but that’s moot).

But setting IoSavedCancelCaller to NULL twice – the second one when not
protected by a higher IRQL – seems like it could be bad, but I don’t know
how that variable is really used by the system, so I’m not sure.

Does anyone have any insight into this?

We control the hardware, by the way, so I know FOR SURE that the hardware is
always a single-processor system.

Thanks for any advice in advance!

2

It will only hurt when some other processor owns the spin lock. THEN it
will cause fascinating failures that will be a total nightmare to debug.
On UP systems, you won’t see an issue here (since this turns into IRQL
changes only). On MP systems, the more your code paths get hit, the
more likely you will see this cause problems.

I’d certainly fix it and I’d have that hot-fix ready for anyone on an MP
system…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class October
18, 2004 in Silicon Valley!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Taed Wynnell
Sent: Wednesday, August 25, 2004 1:15 PM
To: ntdev redirect
Subject: [ntdev] Could calling IoReleaseCancelSpinLock twice in a row be
bad?

We just found a bug today and we’ll fix it, but we have to decide if
it’s
worth creating a hotfix for our customers. We’re just about to release
the
product, and it has passed QA without any problems, but since it hasn’t
gone
to the field, we don’t have a huge amount of bake time that would enable
us
to assess it better. So, I’m looking for some advice.

The bug is that we end up executing code that looks basically like this:
IoAcquireCancelSpinLock(&oldIrql);
// stuff
IoReleaseCancelSpinLock(oldIrql);
IoCompleteRequest(CurrentIrp, IO_NO_INCREMENT);
IoReleaseCancelSpinLock(oldIrql);

Namely, IoReleaseCancelSpinLock is getting called twice.

Now of course, we’ll remove the second call for the future releases.
But
does it REALLY hurt anything? If not, then we won’t do a hotfix, and if
so,
then we would.

Looking at the assembly, it looks like all IoReleaseCancelSpinLock
actually
does is:
IoSavedCancelCaller = NULL;
KeLowerIrql (oldIrql);

I know that calling KeLowerIrql twice with the same IRQL value won’t
hurt
anything on a single-processor machine (I don’t know if it would on a
multi-pocessor, but that’s moot).

But setting IoSavedCancelCaller to NULL twice – the second one when not
protected by a higher IRQL – seems like it could be bad, but I don’t
know
how that variable is really used by the system, so I’m not sure.

Does anyone have any insight into this?

We control the hardware, by the way, so I know FOR SURE that the
hardware is
always a single-processor system.

Thanks for any advice in advance!

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

What if someone else has acquired the cancel spinlock in between your
first and second release? You’ll be dropping someone else’s lock, which
will have very hard to diagnose side-effects.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Taed Wynnell
Sent: Wednesday, August 25, 2004 10:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Could calling IoReleaseCancelSpinLock twice
in a row be bad?

We just found a bug today and we’ll fix it, but we have to
decide if it’s worth creating a hotfix for our customers.
We’re just about to release the product, and it has passed QA
without any problems, but since it hasn’t gone to the field,
we don’t have a huge amount of bake time that would enable us
to assess it better. So, I’m looking for some advice.

The bug is that we end up executing code that looks basically
like this:
IoAcquireCancelSpinLock(&oldIrql);
// stuff
IoReleaseCancelSpinLock(oldIrql);
IoCompleteRequest(CurrentIrp, IO_NO_INCREMENT);
IoReleaseCancelSpinLock(oldIrql);

Namely, IoReleaseCancelSpinLock is getting called twice.

Now of course, we’ll remove the second call for the future
releases. But does it REALLY hurt anything? If not, then we
won’t do a hotfix, and if so, then we would.

Looking at the assembly, it looks like all
IoReleaseCancelSpinLock actually does is:
IoSavedCancelCaller = NULL;
KeLowerIrql (oldIrql);

I know that calling KeLowerIrql twice with the same IRQL
value won’t hurt anything on a single-processor machine (I
don’t know if it would on a multi-pocessor, but that’s moot).

But setting IoSavedCancelCaller to NULL twice – the second
one when not protected by a higher IRQL – seems like it
could be bad, but I don’t know how that variable is really
used by the system, so I’m not sure.

Does anyone have any insight into this?

We control the hardware, by the way, so I know FOR SURE that
the hardware is always a single-processor system.

Thanks for any advice in advance!

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To unsubscribe send a blank
email to xxxxx@lists.osr.com

4

Yes, I considered that, but I couldn’t figure out any way that (on a
single-processor system) another thread could be running and holding the
cancel spinlock (and thus running at IRQL DISPATCH_LEVEL) while another
thread is able to call the second IoReleaseCancelSpinLock. The second
thread would not be able to run during the time that the cancel spinlock is
held by the first thread, or is there some subtle case that I’m missing?

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
> What if someone else has acquired the cancel spinlock in between your
> first and second release? You’ll be dropping someone else’s lock, which
> will have very hard to diagnose side-effects.

5

Well the OP insists that he controls the hardware and it will only ever ever
ever run on UP platforms (without HT of course) so really it is only a
redundant call to set his IRQL back to where it already is. He also
recognized that he needs to fix it. His question was can he get away with
not fixing it in the field for his current customer base (who will only ever
ever run his driver on UP systems with no HT ever they promise) and given
those restrictions and perhaps dubious claims, he can probably avoid a field
update.

Calling Murphy! Call for Mr. Murphy!

=====================
Mark Roddy

-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, August 25, 2004 2:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Could calling IoReleaseCancelSpinLock twice in a row be
bad?

What if someone else has acquired the cancel spinlock in between your first
and second release? You’ll be dropping someone else’s lock, which will have
very hard to diagnose side-effects.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Taed Wynnell
Sent: Wednesday, August 25, 2004 10:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Could calling IoReleaseCancelSpinLock twice in a row
be bad?

We just found a bug today and we’ll fix it, but we have to decide if
it’s worth creating a hotfix for our customers.
We’re just about to release the product, and it has passed QA without
any problems, but since it hasn’t gone to the field, we don’t have a
huge amount of bake time that would enable us to assess it better.
So, I’m looking for some advice.

The bug is that we end up executing code that looks basically like
this:
IoAcquireCancelSpinLock(&oldIrql);
// stuff
IoReleaseCancelSpinLock(oldIrql);
IoCompleteRequest(CurrentIrp, IO_NO_INCREMENT);
IoReleaseCancelSpinLock(oldIrql);

Namely, IoReleaseCancelSpinLock is getting called twice.

Now of course, we’ll remove the second call for the future releases.
But does it REALLY hurt anything? If not, then we won’t do a hotfix,
and if so, then we would.

Looking at the assembly, it looks like all IoReleaseCancelSpinLock
actually does is:
IoSavedCancelCaller = NULL;
KeLowerIrql (oldIrql);

I know that calling KeLowerIrql twice with the same IRQL value won’t
hurt anything on a single-processor machine (I don’t know if it would
on a multi-pocessor, but that’s moot).

But setting IoSavedCancelCaller to NULL twice – the second one when
not protected by a higher IRQL – seems like it could be bad, but I
don’t know how that variable is really used by the system, so I’m not
sure.

Does anyone have any insight into this?

We control the hardware, by the way, so I know FOR SURE that the
hardware is always a single-processor system.

Thanks for any advice in advance!

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Hi!

xxxxx@windows.microsoft.com wrote:

What if someone else has acquired the cancel spinlock in between your
first and second release? You’ll be dropping someone else’s lock, which
will have very hard to diagnose side-effects.

Maybe I get this wrong, but … since we’re talking about a uniprocessor
system…

  1. There is only one active thread at any time
  2. A context-switch can only happen on IRQL < DISPATCH_LEVEL
  3. While the cancel-spinlock is held IRQL will be = DISPATCH_LEVEL

-> The original thread can only run after the “someone else” thread has
released the cancel-spinlock again…

Please correct me if I’m wrong.

Regards,

Paul Groke