Re: interrupt routine and application pages

I am able to see the right
application stack in the interrupt context.

Indeed, you should be able to see it from ISR - for the time being, you
are still in the context of interrupted thread. However, by the time
DPC routine gets executed, you will be already in context of Idle
thread......

But the problem is that when lots
of page swapping happens, I get bugcheck xD1.

This is understandable......


So I am looking for way to
validate address, before actual read operation.

The "golden rule" of accessing memory at IRQL >=DISPATCH_LEVEL is that
you cannot assume *ANYTHING* about memory that you haven't locked in
advance. This is particularly true on SMP machines. On UP machine you
can try MmIsAddressValid(), because you can be 100% sure that, once
your code runs at raised IRQL, Memory Manager just had no chance to
swap the page in the period between MmIsAddressValid() had read the
page table
and the moment you tried to access it. However, it does not work this
way on SMP machine, for understandable reasons....

In fact, according to Doron, MmIsAddressValid() is Memory Manager's
internal function that should not be called by drivers



As you can see, there is no easy solution to your problem. What are
you trying to do, in the first place????? If you tell us more about
your objectives, probably, we will be able to propose you some
alternative solution.


Anton Bassov


RJ wrote:
I didn't see his reply, when I sent my email. I am able to see the right
application stack in the interrupt context. But the problem is that when lots
of page swapping happens, I get bugcheck xD1. So I am looking for way to
validate address, before actual read operation.
Thanks
RJ

"soviet_bloke@xxxxxxxxxxx" wrote:

I appreciate your advice.DPC is also okay for me

It looks like Skywing was just wasting his time, explaining to you that
DPCs run in context of Idle thread, rather than interrupted one (which
means that your DPC routine has no chance to be *EVER* executed in
context of the thread you are interested in).....



Anton Bassov


RJ wrote:
Hi Pavel/Don,
I appreciate your advice.DPC is also okay for me. Also if the stack pages
are paged out, I can ignore this situation. I only need to check the stack if
the pages are still available. So I need a mechanism to check if a particular
stack address is valid, if yes, read the address. If no, ignore.The situation
I need to protect is time between the validity check and read operation.

Thanks,
RJ




"Pavel A." wrote:

"RJ" <RJ@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:C60CC328-2272-45D7-9611-DC859F738C1F@xxxxxxxxxxxxxxxx
Hello,
I have a requirement to examine currently running application stack on an
interrupt routine. Is it safe to read application memory on an interrupt
routine? What is IRQL at which page swapping happens? What is the mechanism
that can be used to make sure that memory area is safe to read?

I would like to use "MmProbeAndLockPages", but it can be used only <=
APC_LEVEL


Speaking of requirements... hmm... you don't have to do this in
the ISR at DIRQL. A DPC allows much more and is suitable for the task,
because the app won't have chance to run before the DPC exits.
Also, consider that the app and the ISR can run on different CPUs.

--PA






.

Relevant Pages

  • Re: VxWorks Interrupts
    ... Where could find the memory map when VxWorks is running or booting... ... Some of this gets changed for cpu's that don't have interrupt stacks, ... and gets permuted for cpu's where the stack grows upwards toward higher ...
    (comp.os.vxworks)
  • Re: Network Stack Locking
    ... Instead of saving and restoring the interrupt ... > to basically create a context (by pushing a procedure call on the stack) ... parallel to concepts in Mach. ...
    (freebsd-arch)
  • Re: interrupt routine and application pages
    ... I have a kernel mode driver that collects profiling information from CPU ... collect application stack during the profile interrupt. ... I need to grab the stack data upto 1K of user stack ... are still in the context of interrupted thread. ...
    (microsoft.public.development.device.drivers)
  • Re: Concurrent Sequential
    ... Our "trick" lets you remove a whack of context switch overhead. ... instructions to perform the interrupt service. ... "Context" does not need to be stored on the stack, ...
    (comp.arch)
  • Re: Why cant we sleep in an ISR?
    ... interrupt is not associated with any context in the first place. ... includes the kernel and userspace stack pointers, the register set, ... this, an interrupt, depending on the version of your kernel and arch, ...
    (Linux-Kernel)