FastIo call context

NTFSD
1

Hi all,

Looking at the FastIo File Lock routines, I saw one of the parameters is the process ID. I know FastIo doesn’t support asynchronous call, but it doesn’t hurt asking anyway.

  1. Is there any chance of having a call to FastIoLock routine relative to a process other than the current one? I mean, having the process ID parameter different from PsGetCurrentProcessId().

You guys might be thinking: “Why don’t you use the parameter anyway?” On my case, I’d need to build a file lock IRP and send it to a different file system driver, but to do so, I’d need the ETHREAD pointer to fill into the Irp->Tail.Overlay.Thread, which is the way a file system driver obtains the requester process for that lock request.

  1. Can I just get this ETHREAD pointer by calling PsGetCurrentThread() or is there any chance of having a FastIoLock call regarding to a thread other than the current one?

Regards,

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br

2

Note that the native APIs do not take a PID as a parameter:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff566474(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff567118(v=vs.85).aspx

Thus, there’s an implicit assumption that the I/O Manager will perform these
operations for the current process. Therefore, the PID parameter will be the
current process and the execution context will be the requesting (i.e.
current) thread.

Note that if you returned FALSE here, the I/O Manager would fill in
Irp->Tail.Overlay.Thread with the return value of PsGetCurrentThread and
send the IRP. So you’re not doing anything different than the I/O Manager by
using the current thread.

Any reason why you don’t just disable this path? Seems to me like it would
be easier to just handle all of this in the IRP path.

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Hi all,

Looking at the FastIo File Lock routines, I saw one of the parameters is the
process ID. I know FastIo doesn’t support asynchronous call, but it doesn’t
hurt asking anyway.

  1. Is there any chance of having a call to FastIoLock routine relative to a
    process other than the current one? I mean, having the process ID parameter
    different from PsGetCurrentProcessId().

You guys might be thinking: “Why don’t you use the parameter anyway?” On my
case, I’d need to build a file lock IRP and send it to a different file
system driver, but to do so, I’d need the ETHREAD pointer to fill into the
Irp->Tail.Overlay.Thread, which is the way a file system driver obtains the
requester process for that lock request.

  1. Can I just get this ETHREAD pointer by calling PsGetCurrentThread() or is
    there any chance of having a FastIoLock call regarding to a thread other
    than the current one?

Regards,

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br

3

Hi Scott,

No reason for not disabling this path. I was just trying to do the best effort to make it work through FastIo as well.

Thanks,

Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br