Hi!
I saw in the documentation that FltPerformSynchronousIo &
FltPerformAsynchronousIo can be used to perform I/O from minifilter.
Basically their usage is recommended for situations, where we can not use
other Fltxxx functions for doing things like reading, writing, querying,
etc. because of constraints that they can be called only at PASSIVE_LEVEL.
I wanted to know when should we use FltPerformSynchronousIo & when should we
use FltPerformAsynchronousIo?
I understand the basic difference that one is to perform I/O synchronously
and the other one to perform it asynchronously.
I want to know more deeply, whether they are any specific conditions in
which to prefer one over the other?
Or what makes one preferable over other?
Should i use FltPerformSynchronousIo, for example, when i am in a pre
callback routine of a synchronous paging I/O ? and use
FltPerformAsynchronousIo when i am in a pre callback routine of an
asynchronous paging I/O ?
It would be really helpful if anyone can give me an insight on the topic.
Thanks!
Be aware these functions have horrible documentation! You can have a valid
callback data structure that will fail with these functions, in fact the
list of functions in the documentation where it says use these calls if
“cannot be used” are about the only IRP’s that they can be used for!
As far as differences, note that FltPerformAsynchronousIo can only be
called at APC level if the IRP_PAGING_IO flag is set and valid, otherwise
you need to use FltPerformSynchronousIo to call at APC level.
I’m far from an expert in these, since I ran into enough problems with
them, that in my filter in the end I rarely used them (even though I had a
number of places that it would have been desirable).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Kernel Developer” wrote in message
news:xxxxx@ntfsd…
> Hi!
> I saw in the documentation that FltPerformSynchronousIo &
> FltPerformAsynchronousIo can be used to perform I/O from minifilter.
> Basically their usage is recommended for situations, where we can not use
> other Fltxxx functions for doing things like reading, writing, querying,
> etc. because of constraints that they can be called only at
> PASSIVE_LEVEL.
> I wanted to know when should we use FltPerformSynchronousIo & when should
> we use FltPerformAsynchronousIo?
> I understand the basic difference that one is to perform I/O
> synchronously and the other one to perform it asynchronously.
> I want to know more deeply, whether they are any specific conditions in
> which to prefer one over the other?
> Or what makes one preferable over other?
> Should i use FltPerformSynchronousIo, for example, when i am in a pre
> callback routine of a synchronous paging I/O ? and use
> FltPerformAsynchronousIo when i am in a pre callback routine of an
> asynchronous paging I/O ?
>
> It would be really helpful if anyone can give me an insight on the topic.
>
> Thanks!
>
>
Thanks Don!
Some questions:
Be aware these functions have horrible documentation! You can have a
valid callback data structure that will fail with these functions, in fact
the list of functions in the documentation where it says use these calls
if “cannot be used” are about the only IRP’s that they can be used for!
But i cannot use the normal Fltxxx functions like FltReadFile,
FltQueryinformationFile, etc., on a Paging I/O path since all of them should
be called at PASIVE_LEVEL.
So, i think the only way to do something in that situation is to create a
callback data and issue FltPerformAsynhronousIo?
Am i correct?
As far as differences, note that FltPerformAsynchronousIo can only be
called at APC level if the IRP_PAGING_IO flag is set and valid, otherwise
you need to use FltPerformSynchronousIo to call at APC level.
What if it is a IRP_SYNCHRONOUS_PAGING_IO?
If i have to use FltPerformAsynchronousIo can i do the following?
PreWriteCallback() {
// i get a paging i/o write
FltAllocateCallbackdata()
FltPerformAsynchronousIo(…,CallbackRoutine,…)
KeWaitForSingleObject(event,INFINITE TIME);
}
Callback(){
KeSetEvent(event);
}
Afaik if you cannot use normal Fltxxx function you cannot circumvent it by
calling FltPerformxxxIo. FltPerformxxIo should be used only for situations
when there is no Fltxxx equivalent. If FltQueryinformationFile must be
running at passive level, there is good reason for it and I quess there is
no way how to write same functionality that could be running in upper level.
Jan
“Kernel Developer” wrote in message
news:xxxxx@ntfsd…
>
> Thanks Don!
> Some questions:
>
> > Be aware these functions have horrible documentation! You can have a
> > valid callback data structure that will fail with these functions, in
fact
> > the list of functions in the documentation where it says use these calls
> > if “cannot be used” are about the only IRP’s that they can be used for!
>
> But i cannot use the normal Fltxxx functions like FltReadFile,
> FltQueryinformationFile, etc., on a Paging I/O path since all of them
should
> be called at PASIVE_LEVEL.
> So, i think the only way to do something in that situation is to create a
> callback data and issue FltPerformAsynhronousIo?
> Am i correct?
>
> >
> > As far as differences, note that FltPerformAsynchronousIo can only be
> > called at APC level if the IRP_PAGING_IO flag is set and valid,
otherwise
> > you need to use FltPerformSynchronousIo to call at APC level.
> >
>
> What if it is a IRP_SYNCHRONOUS_PAGING_IO?
> If i have to use FltPerformAsynchronousIo can i do the following?
>
> PreWriteCallback() {
>
> // i get a paging i/o write
>
> FltAllocateCallbackdata()
> FltPerformAsynchronousIo(…,CallbackRoutine,…)
> KeWaitForSingleObject(event,INFINITE TIME);
> }
>
> Callback(){
> KeSetEvent(event);
> }
>
>
>
“Jan Milan” wrote in message news:xxxxx@ntfsd…
> Afaik if you cannot use normal Fltxxx function you cannot circumvent it
> by
> calling FltPerformxxxIo. FltPerformxxIo should be used only for
> situations
> when there is no Fltxxx equivalent.
>
Sorry, but the above statement if WRONG. FltPerformXxxIo only works for
things with Fltxxx and a small additional subset. What FltPerformXxxIo
does is provide some slight additional flexibility in options, and the
“potential” for calling at APC level. I say potential since the underlying
implementation may or may not be happy at that level.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
So its still like I said. If FltXxx does not provide functionality you need
you could try FltPerformXxxIo. Also it could be used for some io that is not
implemented by FltXxx at all (SetQuota, …). But is there some example that
you could use FltPerformXxxIo instead of FltXxx to make sth working on
higher level? For instance QueryInformation routine should be called at
passive level so there cant be way to write equivalent of
FltQueryInformationFile at apc level and it is what kernel developer has
been asking.
Sorry, but the above statement if WRONG. FltPerformXxxIo only works for
things with Fltxxx and a small additional subset. What FltPerformXxxIo
does is provide some slight additional flexibility in options, and the
“potential” for calling at APC level. I say potential since the
underlying
implementation may or may not be happy at that level.
“Jan Milan” wrote in message news:xxxxx@ntfsd…
> So its still like I said. If FltXxx does not provide functionality you
> need
> you could try FltPerformXxxIo. Also it could be used for some io that is
> not
> implemented by FltXxx at all (SetQuota, …). But is there some example
> that
> you could use FltPerformXxxIo instead of FltXxx to make sth working on
> higher level? For instance QueryInformation routine should be called at
> passive level so there cant be way to write equivalent of
> FltQueryInformationFile at apc level and it is what kernel developer has
> been asking.
>
WRONG! WRONG! WRONG! As I said in my original post, FltPerformXxxIo is
horribly documented, things like SetQuota DO NOT WORK WITH
FltPerformXxxIo!!! Also, where is it documented that
IRP_MJ_QUERY_INFORMATION requires PASSIVE_LEVEL? ZwQueryInformationFile
does because of mechanisms in the Zw handling not in the IRP. I am not
saying it will work, since unfortunately way too many filters and
developers assume that the IRP will be called only at PASSIVE_LEVEL.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
In my minifilter I assume that create, setinfo and cleanup is called at
passive level. What is wrong about it? I do some tests on beginning of
preoperation routines of course.
http://msdn2.microsoft.com/en-us/library/ms790762.aspx
http://msdn2.microsoft.com/en-us/library/ms794997.aspx
WRONG! WRONG! WRONG! As I said in my original post, FltPerformXxxIo is
horribly documented, things like SetQuota DO NOT WORK WITH
FltPerformXxxIo!!! Also, where is it documented that
IRP_MJ_QUERY_INFORMATION requires PASSIVE_LEVEL? ZwQueryInformationFile
does because of mechanisms in the Zw handling not in the IRP. I am not
saying it will work, since unfortunately way too many filters and
developers assume that the IRP will be called only at PASSIVE_LEVEL.
Don…
Is it fine to call FltPerformAsynchronousIo in a pre paging write callback
and then wait for an object using KeWaitForSingleObject.
Then set the event from a completion routine passed in
FltPerformAsynchronousIo?
----- Original Message -----
From: “Don Burn”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, July 24, 2007 5:16 PM
Subject: Re:[ntfsd] Re:When to use what: FltPerformSynchronousIo &
FltPerformAsynchronousIo?
>
> “Jan Milan” wrote in message news:xxxxx@ntfsd…
>> So its still like I said. If FltXxx does not provide functionality you
>> need
>> you could try FltPerformXxxIo. Also it could be used for some io that is
>> not
>> implemented by FltXxx at all (SetQuota, …). But is there some example
>> that
>> you could use FltPerformXxxIo instead of FltXxx to make sth working on
>> higher level? For instance QueryInformation routine should be called at
>> passive level so there cant be way to write equivalent of
>> FltQueryInformationFile at apc level and it is what kernel developer has
>> been asking.
>>
> WRONG! WRONG! WRONG! As I said in my original post, FltPerformXxxIo is
> horribly documented, things like SetQuota DO NOT WORK WITH
> FltPerformXxxIo!!! Also, where is it documented that
> IRP_MJ_QUERY_INFORMATION requires PASSIVE_LEVEL? ZwQueryInformationFile
> does because of mechanisms in the Zw handling not in the IRP. I am not
> saying it will work, since unfortunately way too many filters and
> developers assume that the IRP will be called only at PASSIVE_LEVEL.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
As I have tried to warn it depends on the Io function you want to perform.
You might consider queuing the work to a worker thread (your own or the
systems) and then waiting, since that will give you a PASSIVE_LEVEL
environment, that is the safest.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Kernel Developer” wrote in message
news:xxxxx@ntfsd…
> Don…
>
> Is it fine to call FltPerformAsynchronousIo in a pre paging write
> callback
> and then wait for an object using KeWaitForSingleObject.
> Then set the event from a completion routine passed in
> FltPerformAsynchronousIo?
>
> ----- Original Message -----
> From: “Don Burn”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Tuesday, July 24, 2007 5:16 PM
> Subject: Re:[ntfsd] Re:When to use what: FltPerformSynchronousIo &
> FltPerformAsynchronousIo?
>
>
>>
>> “Jan Milan” wrote in message news:xxxxx@ntfsd…
>>> So its still like I said. If FltXxx does not provide functionality you
>>> need
>>> you could try FltPerformXxxIo. Also it could be used for some io that
>>> is not
>>> implemented by FltXxx at all (SetQuota, …). But is there some example
>>> that
>>> you could use FltPerformXxxIo instead of FltXxx to make sth working on
>>> higher level? For instance QueryInformation routine should be called at
>>> passive level so there cant be way to write equivalent of
>>> FltQueryInformationFile at apc level and it is what kernel developer
>>> has
>>> been asking.
>>>
>> WRONG! WRONG! WRONG! As I said in my original post, FltPerformXxxIo is
>> horribly documented, things like SetQuota DO NOT WORK WITH
>> FltPerformXxxIo!!! Also, where is it documented that
>> IRP_MJ_QUERY_INFORMATION requires PASSIVE_LEVEL? ZwQueryInformationFile
>> does because of mechanisms in the Zw handling not in the IRP. I am not
>> saying it will work, since unfortunately way too many filters and
>> developers assume that the IRP will be called only at PASSIVE_LEVEL.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>>You might consider queuing the work to a worker thread (your own or the
>systems) and then waiting
Queuing ?? Are you proposing to queue the paging i/o write? I think thats not safe…
Or are you proposing to queue just the “work” that i have to do?
The important thing is that i want to be sure that the “WORK” that i want to do gets completed before the original paging write I/O gets processed.
that is why i had asked whether the following steps are correct:
PreWriteCallback() {
// i get a paging i/o write
FltAllocateCallbackdata()
FltPerformAsynchronousIo(…,CallbackRoutine,…)
KeWaitForSingleObject(event,INFINITE TIME);
}
Callback(){
KeSetEvent(event);
}
> The important thing is that i want to be sure that the “WORK” that i want
to do gets completed before the original paging write I/O gets processed.
that is why i had asked whether the following steps are correct:
PreWriteCallback() {
// i get a paging i/o write
FltAllocateCallbackdata()
FltPerformAsynchronousIo(…,CallbackRoutine,…)
KeWaitForSingleObject(event,INFINITE TIME);
}
Callback(){
KeSetEvent(event);
}
The consruction is nearly correct, it will work( but with obvious problems
mentioned later ) if CallbackRoutine doesn’t use cached write through
(Zw)(Nt)WriteFile or some other Zw* or Nt* functions which call
CcCanIWrite() function, the same for the cached read.
The problem of your solution - you stop Modified Page Writer or Mapped Page
Writer so the number of modified pages can growth enormously( up to more
than 50% of all available physical memory, in that case the system stops to
respond to user applications’ requests ) and you might aggravate the
sutuation by your CallbackRoutine, for example if you write in the cache or
mapped file the large amount of data thus generating new durty pages or read
in the cache or mapped file requiring to free new pages by flushing the old
one ). If you stop both Modified Page Writer and Mapped Page Writer the
system will hang with a great probability, if you stop only one thread the
probability is significantly lower.
–
Slava Imameyev, xxxxx@hotmail.com
wrote in message news:xxxxx@ntfsd…
>>>You might consider queuing the work to a worker thread (your own or the
>>>systems) and then waiting
>
> Queuing ?? Are you proposing to queue the paging i/o write? I think thats
> not safe…
> Or are you proposing to queue just the “work” that i have to do?
>
> The important thing is that i want to be sure that the “WORK” that i want
> to do gets completed before the original paging write I/O gets processed.
>
> that is why i had asked whether the following steps are correct:
> PreWriteCallback() {
>
> // i get a paging i/o write
>
> FltAllocateCallbackdata()
> FltPerformAsynchronousIo(…,CallbackRoutine,…)
> KeWaitForSingleObject(event,INFINITE TIME);
> }
>
> Callback(){
> KeSetEvent(event);
> }
>
>
>
Also, remember that if top level Irp is not NULL( this is the case for
nearly all paging write requests ) then you should be careful with issuing
new request in the same thread.
–
Slava Imameyev, xxxxx@hotmail.com
“Slava Imameyev” wrote in message news:xxxxx@ntfsd…
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>
> The consruction is nearly correct, it will work( but with obvious problems
> mentioned later ) if CallbackRoutine doesn’t use cached write through
> (Zw)(Nt)WriteFile or some other Zw* or Nt* functions which call
> CcCanIWrite() function, the same for the cached read.
> The problem of your solution - you stop Modified Page Writer or Mapped
> Page Writer so the number of modified pages can growth enormously( up to
> more than 50% of all available physical memory, in that case the system
> stops to respond to user applications’ requests ) and you might aggravate
> the sutuation by your CallbackRoutine, for example if you write in the
> cache or mapped file the large amount of data thus generating new durty
> pages or read in the cache or mapped file requiring to free new pages by
> flushing the old one ). If you stop both Modified Page Writer and Mapped
> Page Writer the system will hang with a great probability, if you stop
> only one thread the probability is significantly lower.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> wrote in message news:xxxxx@ntfsd…
>>>>You might consider queuing the work to a worker thread (your own or the
>>>>systems) and then waiting
>>
>> Queuing ?? Are you proposing to queue the paging i/o write? I think thats
>> not safe…
>> Or are you proposing to queue just the “work” that i have to do?
>>
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>>
>>
>>
>
>
>
Thanks Slava!
But in the documentation it is mentioned that FltPerformAsynchronousIo can be used in paging i/o path with APC_LEVEL.
Assuming that most of the Paging I/O requests come with toplevelirp !=NULL, should we use it?
I suppose that we cannot issue File system calls, but we can build our own IRP.
And FltPerformAsynchronousIo ultimately gets converted into IRP by the Filter Manager itself.
Slava Imameyev wrote:
Also, remember that if top level Irp is not NULL( this is the case for
nearly all paging write requests ) then you should be careful with issuing
new request in the same thread.
–
Slava Imameyev, xxxxx@hotmail.com
“Slava Imameyev” wrote in message news:xxxxx@ntfsd…
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>
> The consruction is nearly correct, it will work( but with obvious problems
> mentioned later ) if CallbackRoutine doesn’t use cached write through
> (Zw)(Nt)WriteFile or some other Zw* or Nt* functions which call
> CcCanIWrite() function, the same for the cached read.
> The problem of your solution - you stop Modified Page Writer or Mapped
> Page Writer so the number of modified pages can growth enormously( up to
> more than 50% of all available physical memory, in that case the system
> stops to respond to user applications’ requests ) and you might aggravate
> the sutuation by your CallbackRoutine, for example if you write in the
> cache or mapped file the large amount of data thus generating new durty
> pages or read in the cache or mapped file requiring to free new pages by
> flushing the old one ). If you stop both Modified Page Writer and Mapped
> Page Writer the system will hang with a great probability, if you stop
> only one thread the probability is significantly lower.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> wrote in message news:xxxxx@ntfsd…
>>>>You might consider queuing the work to a worker thread (your own or the
>>>>systems) and then waiting
>>
>> Queuing ?? Are you proposing to queue the paging i/o write? I think thats
>> not safe…
>> Or are you proposing to queue just the “work” that i have to do?
>>
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>>
>>
>>
>
>
>
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Once upon a time there was 1 GB storage in your inbox. Click here for happy ending.
I think Kernel dev can use this method for his work.
Slava Imameyev wrote:
Also, remember that if top level Irp is not NULL( this is the case for
nearly all paging write requests ) then you should be careful with issuing
new request in the same thread.
–
Slava Imameyev, xxxxx@hotmail.com
“Slava Imameyev” wrote in message news:xxxxx@ntfsd…
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>
> The consruction is nearly correct, it will work( but with obvious problems
> mentioned later ) if CallbackRoutine doesn’t use cached write through
> (Zw)(Nt)WriteFile or some other Zw* or Nt* functions which call
> CcCanIWrite() function, the same for the cached read.
> The problem of your solution - you stop Modified Page Writer or Mapped
> Page Writer so the number of modified pages can growth enormously( up to
> more than 50% of all available physical memory, in that case the system
> stops to respond to user applications’ requests ) and you might aggravate
> the sutuation by your CallbackRoutine, for example if you write in the
> cache or mapped file the large amount of data thus generating new durty
> pages or read in the cache or mapped file requiring to free new pages by
> flushing the old one ). If you stop both Modified Page Writer and Mapped
> Page Writer the system will hang with a great probability, if you stop
> only one thread the probability is significantly lower.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> wrote in message news:xxxxx@ntfsd…
>>>>You might consider queuing the work to a worker thread (your own or the
>>>>systems) and then waiting
>>
>> Queuing ?? Are you proposing to queue the paging i/o write? I think thats
>> not safe…
>> Or are you proposing to queue just the “work” that i have to do?
>>
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>>
>>
>>
>
>
>
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Get the freedom to save as many mails as you wish. Click here to know how.
>Also, remember that if top level Irp is not NULL( this is the case for
nearly all paging write requests ) then you should be careful with issuing
new request in the same thread.
As Slava mentioned, do not issue a cached request, that can be dangerous.
If you are writing to some file, ensure that it is opened in NON CACHED
MODE.
Otherwise, your call will take the same path and come back to you again as a
paging i/o. If not handled properly, this will lead to deadlock.
Slava, why will " top level Irp != NULL" cause a problem in this case?
Ayush Gupta
K7 Computing Private Limited
>Slava, why will " top level Irp != NULL" cause a problem in this case?
Because there is a strong possibility( nearly 100%) that some resources of the FSD driver have been already acquired thus a set of allowed requests has been reduced because of a possible deadlock in the FSD driver( this set strongly depends on FSD ).
–
Slava Imameyev, xxxxx@hotmail.com
Slava, you mentioned that:
“Because there is a strong possibility( nearly 100%) that some resources of
the
FSD driver have been already acquired thus a set of allowed requests has
been
reduced because of a possible deadlock in the FSD driver( this set strongly
depends on FSD ).”
I am new in this field and AFAIK, TopLevelIrp is used as a locking hierarchy
between FSD, Cache Manager and Memeory Manager.
But if i use Non Cached I/O, as mentioned by Ayush, should this be a
problem?
Also, what are the limited calls that i can make?
>But in the documentation it is mentioned that FltPerformAsynchronousIo can be used in paging i/o path with APC_LEVEL.
Assuming that most of the Paging I/O requests come with toplevelirp !=NULL, should we use it?
IRQL and FSD’s lock hierarchy have a very weak relation( if any ), top level IRP is usually used to notify others that some FSD’s resource have been acquired, so be cautious. If you are allowed to use function at APC_LEVEL this doen’t mean that it preserves the FSD’s lock hierarchy.
I suppose that we cannot issue File system calls, but we can build our own IRP.
Hmmm, not clear. What is “File system calls”? If you build an IRP and send(!) it to an FSD you make a “File system call”.
–
Slava Imameyev, xxxxx@hotmail.com
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
Thanks Slava!
But in the documentation it is mentioned that FltPerformAsynchronousIo can be used in paging i/o path with APC_LEVEL.
Assuming that most of the Paging I/O requests come with toplevelirp !=NULL, should we use it?
I suppose that we cannot issue File system calls, but we can build our own IRP.
And FltPerformAsynchronousIo ultimately gets converted into IRP by the Filter Manager itself.
Slava Imameyev wrote:
Also, remember that if top level Irp is not NULL( this is the case for
nearly all paging write requests ) then you should be careful with issuing
new request in the same thread.
–
Slava Imameyev, xxxxx@hotmail.com
“Slava Imameyev” wrote in message news:xxxxx@ntfsd…
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>
> The consruction is nearly correct, it will work( but with obvious problems
> mentioned later ) if CallbackRoutine doesn’t use cached write through
> (Zw)(Nt)WriteFile or some other Zw* or Nt* functions which call
> CcCanIWrite() function, the same for the cached read.
> The problem of your solution - you stop Modified Page Writer or Mapped
> Page Writer so the number of modified pages can growth enormously( up to
> more than 50% of all available physical memory, in that case the system
> stops to respond to user applications’ requests ) and you might aggravate
> the sutuation by your CallbackRoutine, for example if you write in the
> cache or mapped file the large amount of data thus generating new durty
> pages or read in the cache or mapped file requiring to free new pages by
> flushing the old one ). If you stop both Modified Page Writer and Mapped
> Page Writer the system will hang with a great probability, if you stop
> only one thread the probability is significantly lower.
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> wrote in message news:xxxxx@ntfsd…
>>>>You might consider queuing the work to a worker thread (your own or the
>>>>systems) and then waiting
>>
>> Queuing ?? Are you proposing to queue the paging i/o write? I think thats
>> not safe…
>> Or are you proposing to queue just the “work” that i have to do?
>>
>> The important thing is that i want to be sure that the “WORK” that i want
>> to do gets completed before the original paging write I/O gets processed.
>>
>> that is why i had asked whether the following steps are correct:
>> PreWriteCallback() {
>>
>> // i get a paging i/o write
>>
>> FltAllocateCallbackdata()
>> FltPerformAsynchronousIo(…,CallbackRoutine,…)
>> KeWaitForSingleObject(event,INFINITE TIME);
>> }
>>
>> Callback(){
>> KeSetEvent(event);
>> }
>>
>>
>>
>
>
>
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com
------------------------------------------------------------------------------
Once upon a time there was 1 GB storage in your inbox. Click here for happy ending.
> AFAIK, TopLevelIrp is used as a locking hierarchy
between FSD, Cache Manager and Memeory Manager.
But if i use Non Cached I/O, as mentioned by Ayush, should this be a
problem?
Your might face problems with FSD’s lock hierarchy if you issue requests to
FSD when TopLevelIrp is not NULL. If you issue a request( especially
non-paging ) to FSD when TopLevelIrp is not NULL then you should be ready to
deal with deadlocks, because you might violate the FSD’s lock hierarchy. The
most dangerous thing is to issue a request for a data stream different from
those used for the original request( i.e. the paging write request in your
case ).
–
Slava Imameyev, xxxxx@hotmail.com
“Kernel Developer” wrote in message
news:xxxxx@ntfsd…
> Slava, you mentioned that:
> “Because there is a strong possibility( nearly 100%) that some resources
> of the
> FSD driver have been already acquired thus a set of allowed requests has
> been
> reduced because of a possible deadlock in the FSD driver( this set
> strongly
> depends on FSD ).”
>
> I am new in this field and AFAIK, TopLevelIrp is used as a locking
> hierarchy between FSD, Cache Manager and Memeory Manager.
> But if i use Non Cached I/O, as mentioned by Ayush, should this be a
> problem?
> Also, what are the limited calls that i can make?
>