Calling FltReferenceFileNameInformation() at elevated IRQL – nuts!
OK, what I am doing is making a copy of the pointer to the name info
structure (along with some other info) for later processing. This occurs
inside a post-write operation at elevated IRQL.
I guess I could re-synchronize back to dispatch, but this is the only thing
keeping me from queuing the operation quickly at this point. 
/ted
Ted,
Rather than calling FltReferenceFileNameInformation why don’t you not
release the FileNameInformation untill you are done with it. This will be
more efficient. We’ll take a look why FltReferenceFileNameInformation is not
callable at dispatch level’s and fix it.
This posting is provided “AS IS” with no warranties, and confers no rights.
“Ted Hess” wrote in message news:xxxxx@ntfsd…
> Calling FltReferenceFileNameInformation() at elevated IRQL – nuts!
>
> OK, what I am doing is making a copy of the pointer to the name info
> structure (along with some other info) for later processing. This occurs
> inside a post-write operation at elevated IRQL.
>
> I guess I could re-synchronize back to dispatch, but this is the only
thing
> keeping me from queuing the operation quickly at this point.
>
> /ted
>
Ted,
It turns out that you can never reference a name information structure
at DPC level because names are stored in PAGED pool. Could you please
describe what you are trying to accomplish. As Ravinder pointed out, I
don’t see why you would ever need to call the reference API.
It was good this came up because we discovered that we don’t properly
support freeing a name information structure at DPC level (like we do
with contexts). This we will fix.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravinder Thind
Sent: Monday, March 15, 2004 2:31 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
Rather than calling FltReferenceFileNameInformation why don’t you not
release the FileNameInformation untill you are done with it. This will
be
more efficient. We’ll take a look why FltReferenceFileNameInformation is
not
callable at dispatch level’s and fix it.
This posting is provided “AS IS” with no warranties, and confers no
rights.
“Ted Hess” wrote in message news:xxxxx@ntfsd…
> Calling FltReferenceFileNameInformation() at elevated IRQL – nuts!
>
> OK, what I am doing is making a copy of the pointer to the name info
> structure (along with some other info) for later processing. This
occurs
> inside a post-write operation at elevated IRQL.
>
> I guess I could re-synchronize back to dispatch, but this is the only
thing
> keeping me from queuing the operation quickly at this point.
>
> /ted
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I have a name information structure pointer in my stream context. From
time-to-time (say write activity), I want to send some information to a
user-mode component. This information currently contains a reference to the
file name information structure. I just called
FltReferenceFileNameInformation when queueing the item and then released it
when the item has been de-queued and copied to the user-mode buffer. I
suppose I could allocate another buffer and copy the name into it, but this
seemed more eloquent.
I have a number of work-arounds that could be done. One such is NOT queing
the data to the user-mode component if the write completion is at DPC level.
I could defer the queuing operation until some other IO (next pre-Write
dispatch) at non-DPC level occurs. This data is not time critical.
/ted
-----Original Message-----
From: Neal Christiansen [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, March 15, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
It turns out that you can never reference a name information structure at
DPC level because names are stored in PAGED pool. Could you please describe
what you are trying to accomplish. As Ravinder pointed out, I don’t see why
you would ever need to call the reference API.
It was good this came up because we discovered that we don’t properly
support freeing a name information structure at DPC level (like we do with
contexts). This we will fix.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravinder Thind
Sent: Monday, March 15, 2004 2:31 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
Rather than calling FltReferenceFileNameInformation why don’t you not
release the FileNameInformation untill you are done with it. This will be
more efficient. We’ll take a look why FltReferenceFileNameInformation is not
callable at dispatch level’s and fix it.
This posting is provided “AS IS” with no warranties, and confers no rights.
“Ted Hess” wrote in message news:xxxxx@ntfsd…
> Calling FltReferenceFileNameInformation() at elevated IRQL – nuts!
>
> OK, what I am doing is making a copy of the pointer to the name info
> structure (along with some other info) for later processing. This
occurs
> inside a post-write operation at elevated IRQL.
>
> I guess I could re-synchronize back to dispatch, but this is the only
thing
> keeping me from queuing the operation quickly at this point.
>
> /ted
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Ted,
That usage of the name information referencing routine sounds reasonable
since I am assuming it is possible for the stream to get closed (thus
wanting to release the name information structure) before you finishing
copying data from the name information structure.
After reviewing the code for FltReleaseFileNameInformation() we realized
that there is no point in changing this routine to allow it to be called
at DPC level. This is because the name information structure resides in
paged pool. We didn’t want them in non-paged pool because they can
consume a significant amount of memory if there are a lot of open files.
This means it is never safe to access the name information structure at
DPC level. If you don’t agree with this please let me know why.
The documentation for the naming APIs does say that you must be running
at IRQL <= APC_LEVEL but it does not specifically state that the name
information structures themselves reside in paged pool. I have filed a
doc bug to get this fixed.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, March 15, 2004 3:03 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ASSERT in FltMgr.sys (checked version)
I have a name information structure pointer in my stream context. From
time-to-time (say write activity), I want to send some information to a
user-mode component. This information currently contains a reference to
the
file name information structure. I just called
FltReferenceFileNameInformation when queueing the item and then released
it
when the item has been de-queued and copied to the user-mode buffer. I
suppose I could allocate another buffer and copy the name into it, but
this
seemed more eloquent.
I have a number of work-arounds that could be done. One such is NOT
queing
the data to the user-mode component if the write completion is at DPC
level.
I could defer the queuing operation until some other IO (next pre-Write
dispatch) at non-DPC level occurs. This data is not time critical.
/ted
-----Original Message-----
From: Neal Christiansen [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, March 15, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
It turns out that you can never reference a name information structure
at
DPC level because names are stored in PAGED pool. Could you please
describe
what you are trying to accomplish. As Ravinder pointed out, I don’t see
why
you would ever need to call the reference API.
It was good this came up because we discovered that we don’t properly
support freeing a name information structure at DPC level (like we do
with
contexts). This we will fix.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravinder Thind
Sent: Monday, March 15, 2004 2:31 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
Rather than calling FltReferenceFileNameInformation why don’t you not
release the FileNameInformation untill you are done with it. This will
be
more efficient. We’ll take a look why FltReferenceFileNameInformation is
not
callable at dispatch level’s and fix it.
This posting is provided “AS IS” with no warranties, and confers no
rights.
“Ted Hess” wrote in message news:xxxxx@ntfsd…
> Calling FltReferenceFileNameInformation() at elevated IRQL – nuts!
>
> OK, what I am doing is making a copy of the pointer to the name info
> structure (along with some other info) for later processing. This
occurs
> inside a post-write operation at elevated IRQL.
>
> I guess I could re-synchronize back to dispatch, but this is the only
thing
> keeping me from queuing the operation quickly at this point.
>
> /ted
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com To
unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Neal -
This should not be a problem. I have a couple of solutions including adding
a ref count to the stream context and queue that instead. My stream context
is in NPP.
/ted
-----Original Message-----
From: Neal Christiansen [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, March 15, 2004 8:07 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
That usage of the name information referencing routine sounds reasonable
since I am assuming it is possible for the stream to get closed (thus
wanting to release the name information structure) before you finishing
copying data from the name information structure.
After reviewing the code for FltReleaseFileNameInformation() we realized
that there is no point in changing this routine to allow it to be called at
DPC level. This is because the name information structure resides in paged
pool. We didn’t want them in non-paged pool because they can consume a
significant amount of memory if there are a lot of open files. This means it
is never safe to access the name information structure at DPC level. If you
don’t agree with this please let me know why.
The documentation for the naming APIs does say that you must be running at
IRQL <= APC_LEVEL but it does not specifically state that the name
information structures themselves reside in paged pool. I have filed a doc
bug to get this fixed.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Monday, March 15, 2004 3:03 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ASSERT in FltMgr.sys (checked version)
I have a name information structure pointer in my stream context. From
time-to-time (say write activity), I want to send some information to a
user-mode component. This information currently contains a reference to the
file name information structure. I just called
FltReferenceFileNameInformation when queueing the item and then released it
when the item has been de-queued and copied to the user-mode buffer. I
suppose I could allocate another buffer and copy the name into it, but this
seemed more eloquent.
I have a number of work-arounds that could be done. One such is NOT queing
the data to the user-mode component if the write completion is at DPC level.
I could defer the queuing operation until some other IO (next pre-Write
dispatch) at non-DPC level occurs. This data is not time critical.
/ted
-----Original Message-----
From: Neal Christiansen [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, March 15, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
It turns out that you can never reference a name information structure at
DPC level because names are stored in PAGED pool. Could you please describe
what you are trying to accomplish. As Ravinder pointed out, I don’t see why
you would ever need to call the reference API.
It was good this came up because we discovered that we don’t properly
support freeing a name information structure at DPC level (like we do with
contexts). This we will fix.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravinder Thind
Sent: Monday, March 15, 2004 2:31 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] ASSERT in FltMgr.sys (checked version)
Ted,
Rather than calling FltReferenceFileNameInformation why don’t you not
release the FileNameInformation untill you are done with it. This will be
more efficient. We’ll take a look why FltReferenceFileNameInformation is not
callable at dispatch level’s and fix it.
This posting is provided “AS IS” with no warranties, and confers no rights.
“Ted Hess” wrote in message news:xxxxx@ntfsd…
> Calling FltReferenceFileNameInformation() at elevated IRQL – nuts!
>
> OK, what I am doing is making a copy of the pointer to the name info
> structure (along with some other info) for later processing. This
occurs
> inside a post-write operation at elevated IRQL.
>
> I guess I could re-synchronize back to dispatch, but this is the only
thing
> keeping me from queuing the operation quickly at this point.
>
> /ted
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com