When a User process sends an IOCTL to a Kernel device driver, will the
driver’s dispatch routine ALWAYS be running in the context of that User
process? (We all agree that it will be at least most of the time.)
We debated this yesterday, and aren’t sure. We’re only looking at a simple
one process / one driver model, but I imagine that filter drivers or
something could affect it. I also was concerned about the IOCTL being done
just before the quantum expires for the process, and thus, the process being
swapped before the driver gets the IOCTL. (I’m also curious if it’s true on
a multi-processor system, but we know that we’re always on a single
processor.)
This came up because we wanted to pass a user-mode pointer down and I wasn’t
convinced that the device driver could always access it. Assuming that the
driver is running at passive level, are there any issues with paging that
we’d have to worry about? I plan to validate it with MmIsAddressValid() (or
whatever that routine is), but obviously, we’d like to page it in if it’s
currently paged out.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
If the driver is the top-level driver, it can depend upon the context. All
FSDs always assume that they are called in the user’s context. Any filter
that breaks that assumption is wrong. Don’t forget that your driver’s
device object must be private. Your application could create a DosDevices
name for the kernel name only when it needs to access the driver.
----- Original Message -----
From: “Taed Nelson”
To: “NT Developers Interest List”
Sent: Saturday, March 03, 2001 10:19 PM
Subject: [ntdev] User->Kernel IOCTL always in User context?
> When a User process sends an IOCTL to a Kernel device driver, will the
> driver’s dispatch routine ALWAYS be running in the context of that User
> process? (We all agree that it will be at least most of the time.)
>
> We debated this yesterday, and aren’t sure. We’re only looking at a
simple
> one process / one driver model, but I imagine that filter drivers or
> something could affect it. I also was concerned about the IOCTL being
done
> just before the quantum expires for the process, and thus, the process
being
> swapped before the driver gets the IOCTL. (I’m also curious if it’s true
on
> a multi-processor system, but we know that we’re always on a single
> processor.)
>
> This came up because we wanted to pass a user-mode pointer down and I
wasn’t
> convinced that the device driver could always access it. Assuming that
the
> driver is running at passive level, are there any issues with paging that
> we’d have to worry about? I plan to validate it with MmIsAddressValid()
(or
> whatever that routine is), but obviously, we’d like to page it in if it’s
> currently paged out.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@mindspring.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
As long as you are the topmost driver then an IOCTL IRP, and in fact ANY
IRP, will arrive at your dispatch routines in the thread context that
initiated the request. If a filter driver is installed above your topmost
driver it MUST maintain this relationship.
I also was concerned about the IOCTL
being done
just before the quantum expires for the process, and thus, the
process being
swapped before the driver gets the IOCTL.
This doesn’t matter. First of all it is the thread not the process that is
affected by quantum expiration. Secondly, if the thread is suspended it is
suspended. Processing the IRP is also suspended because that is what the
thread was doing. When the thread resumes, it picks up where it left off,
for example in your driver processing the IOCTL IRP.
(I’m also curious if
it’s true on
a multi-processor system, but we know that we’re always on a single
processor.)
No difference.
Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
xxxxx@hollistech.com
603 321 1032
www.hollistech.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> When a User process sends an IOCTL to a Kernel device driver, will the
driver’s dispatch routine ALWAYS be running in the context of that User
process? (We all agree that it will be at least most of the time.)
We debated this yesterday, and aren’t sure. We’re only looking at a
simple
one process / one driver model, but I imagine that filter drivers or
something could affect it. I also was concerned about the IOCTL being
done
just before the quantum expires for the process, and thus, the process
being
swapped before the driver gets the IOCTL. (I’m also curious if it’s true
on
a multi-processor system, but we know that we’re always on a single
processor.)
Most of the time it will be running in the user thread context only. If u
Driver creates seperate thread for handling IOCTL paralell then it will be
in system context. Thou we cant assume anything i feel.
This came up because we wanted to pass a user-mode pointer down and I
wasn’t
convinced that the device driver could always access it. Assuming that
the
driver is running at passive level, are there any issues with paging that
we’d have to worry about? I plan to validate it with MmIsAddressValid()
(or
whatever that routine is), but obviously, we’d like to page it in if it’s
currently paged out.
The another method is to valudate user mode buffer using Try/Except for
checking validity.
Regards,
Satish K.S
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com