Prev: kernel mode proxy driver
Next: WDM USB driver trouble under vista
From: Hugo gleaves on 11 May 2008 05:51
Hi
This isnt strictly about a driver issue, but many driver coders may have
insights.

Basically we plan to user some of the Interlock functions (exchange,
exchange compare etc) as the basis for a simple fast lock (not in driver code
though).

However, we are also placing the integer values in pages that have had their
access set to Read Only. Currently when code attempts to write to such a page
we trap the exception, run a few checks and then update the page to have
Write access.

This is all standard stuff, BUT if we locate an integer in such a page AND
try to use an interlock exchnage kind of function on it, it raises an
interesting question.

The interlock operations are defined as being uniterruptible BUT if they are
in a ReadOnly page the operation WILL be interrupted (by the exception that
prevents writes to read only pages).

So would it work or not??

Any insights much appreciated.

PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.

From: Pavel A. on 11 May 2008 11:48
"Hugogleaves(a)hotmail.com>" <hugh<underbar> wrote in message
news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E(a)microsoft.com...
> Hi
> This isnt strictly about a driver issue, but many driver coders may have
> insights.
>
> Basically we plan to user some of the Interlock functions (exchange,
> exchange compare etc) as the basis for a simple fast lock (not in driver
> code
> though).
>
> However, we are also placing the integer values in pages that have had
> their
> access set to Read Only. Currently when code attempts to write to such a
> page
> we trap the exception, run a few checks and then update the page to have
> Write access.
>
> This is all standard stuff, BUT if we locate an integer in such a page AND
> try to use an interlock exchnage kind of function on it, it raises an
> interesting question.
>
> The interlock operations are defined as being uniterruptible BUT if they
> are
> in a ReadOnly page the operation WILL be interrupted (by the exception
> that
> prevents writes to read only pages).
>
> So would it work or not??
>
> Any insights much appreciated.
>
> PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.

Ok I'll try to answer this, as there's still no other replies.

Interlocked... functions do work with variables in pageable memory.
If these can be interrupted by paging operations, they can be
interrupted by other resumable exceptions as well;
so it will work exactly in same way.

Regards,
--PA


From: David Craig on 11 May 2008 13:50
Here are the comments from InterlockedExchange which can be used to do
almost any interlocked operation.

InterlockedExchange should be used instead of ExInterlockedExchangeUlong,
because it is both faster and more efficient.

InterlockedExchange is implemented inline by the compiler when appropriate
and possible. It does not require a spin lock and can therefore be safely
used on pageable data.

A call to InterlockedExchange routine is atomic only with respect to other
InterlockedXxx calls.

Callers of InterlockedExchange can be running at any IRQL.

End comments.

If the data types are simple such as 32 or 64 bits depending upon the OS
target, this is a simple solution. The data item will reside within one
page unless you attempt some weird packing in structures. Creating the
source with code listing from the compiler can allow you to verify that one
instruction is used to update the data item. The interlocked operation will
be uninterruptable since the entire data item is updated at once. The fact
that the data is located in a read only page has no impact on the
uninterruptible-ness of the instruction as the instruction will not being
until the data can be written. Yes, another processor could come along
after the page has been changed to writable and it would get the operation
to complete before the thread that started the sequence can actually get
back to trying the interlocked operation. I would think long and hard about
just making pages read only when they must be written to with any frequency.

"Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message
news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E(a)microsoft.com...
> Hi
> This isnt strictly about a driver issue, but many driver coders may have
> insights.
>
> Basically we plan to user some of the Interlock functions (exchange,
> exchange compare etc) as the basis for a simple fast lock (not in driver
> code
> though).
>
> However, we are also placing the integer values in pages that have had
> their
> access set to Read Only. Currently when code attempts to write to such a
> page
> we trap the exception, run a few checks and then update the page to have
> Write access.
>
> This is all standard stuff, BUT if we locate an integer in such a page AND
> try to use an interlock exchnage kind of function on it, it raises an
> interesting question.
>
> The interlock operations are defined as being uniterruptible BUT if they
> are
> in a ReadOnly page the operation WILL be interrupted (by the exception
> that
> prevents writes to read only pages).
>
> So would it work or not??
>
> Any insights much appreciated.
>
> PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
>


From: Alexander Grigoriev on 11 May 2008 14:16
An operation that involves memory modification will only start if the
destination is writeable, no matter if it's interlocked or not. An operation
won't be interrupted in between and then resumed.

I'm not sure why you want to modify page protection on the fly. If this is
for debugging, it's OK. If you base your design on this, it won't work
reliably.

"Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message
news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E(a)microsoft.com...
> Hi
> This isnt strictly about a driver issue, but many driver coders may have
> insights.
>
> Basically we plan to user some of the Interlock functions (exchange,
> exchange compare etc) as the basis for a simple fast lock (not in driver
> code
> though).
>
> However, we are also placing the integer values in pages that have had
> their
> access set to Read Only. Currently when code attempts to write to such a
> page
> we trap the exception, run a few checks and then update the page to have
> Write access.
>
> This is all standard stuff, BUT if we locate an integer in such a page AND
> try to use an interlock exchnage kind of function on it, it raises an
> interesting question.
>
> The interlock operations are defined as being uniterruptible BUT if they
> are
> in a ReadOnly page the operation WILL be interrupted (by the exception
> that
> prevents writes to read only pages).
>
> So would it work or not??
>
> Any insights much appreciated.
>
> PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
>


From: Hugo gleaves on 11 May 2008 14:22


"David Craig" wrote:

> Here are the comments from InterlockedExchange which can be used to do
> almost any interlocked operation.
>
> InterlockedExchange should be used instead of ExInterlockedExchangeUlong,
> because it is both faster and more efficient.
>
> InterlockedExchange is implemented inline by the compiler when appropriate
> and possible. It does not require a spin lock and can therefore be safely
> used on pageable data.
>
> A call to InterlockedExchange routine is atomic only with respect to other
> InterlockedXxx calls.
>
> Callers of InterlockedExchange can be running at any IRQL.
>
> End comments.
>
> If the data types are simple such as 32 or 64 bits depending upon the OS
> target, this is a simple solution. The data item will reside within one
> page unless you attempt some weird packing in structures. Creating the
> source with code listing from the compiler can allow you to verify that one
> instruction is used to update the data item. The interlocked operation will
> be uninterruptable since the entire data item is updated at once. The fact
> that the data is located in a read only page has no impact on the
> uninterruptible-ness of the instruction as the instruction will not being
> until the data can be written. Yes, another processor could come along
> after the page has been changed to writable and it would get the operation
> to complete before the thread that started the sequence can actually get
> back to trying the interlocked operation. I would think long and hard about
> just making pages read only when they must be written to with any frequency.
>
> "Hugo gleaves(a)hotmail.com>" <hugh<underbar> wrote in message
> news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E(a)microsoft.com...
> > Hi
> > This isnt strictly about a driver issue, but many driver coders may have
> > insights.
> >
> > Basically we plan to user some of the Interlock functions (exchange,
> > exchange compare etc) as the basis for a simple fast lock (not in driver
> > code
> > though).
> >
> > However, we are also placing the integer values in pages that have had
> > their
> > access set to Read Only. Currently when code attempts to write to such a
> > page
> > we trap the exception, run a few checks and then update the page to have
> > Write access.
> >
> > This is all standard stuff, BUT if we locate an integer in such a page AND
> > try to use an interlock exchnage kind of function on it, it raises an
> > interesting question.
> >
> > The interlock operations are defined as being uniterruptible BUT if they
> > are
> > in a ReadOnly page the operation WILL be interrupted (by the exception
> > that
> > prevents writes to read only pages).
> >
> > So would it work or not??
> >
> > Any insights much appreciated.
> >
> > PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
> >
>
>
> Firstly, thanks to Pavel A, and David Craig for responding, it is appreciated.

It seems from what you both say, that this will work in a predictable and
intuitive way; of course I will test the code heavily but I agree that it
should operate "as expected" under these circumstances.

In response to David's point, we do this to meet a design objective. We must
prevent errant user code from writing to pages that (may) contain system
structures. When a "user" calls one of our API functions all pages (in the
managed area) are ReadOnly (so that any errant code cannot trash system data)
but when API code attempts to update system data an exception is raised.

The exception handler runs and examines the details about what kind of data
was being written to and why, if this is determined to be valid we make the
page ReadWrite and record this fact.

Because API calls may be nested arbitrarily, we have logic to track the
"depth" of such calls, when the "outermost" API exits, this to ois detected
and the page (all impacted pages in fact) are reset to ReadOnly so that any
attempt by user (calling) code to write to such pages is trapped.

This works and means that NO erroneous code can ever inadvertently damage
system structures in shared memory.

Because our custom read/write spinlock code refers to fields in system
structures that are (therefore) in ReadOnly pages, we have do deal with this
question.

Anyway...I will now code up some formal test code and stress this out.

Thanks again to both of you for your comments.

Hugh

 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: kernel mode proxy driver
Next: WDM USB driver trouble under vista