I have seen discussions that using #pragma alloc_text(PAGE, …) can do more
harm than good if not done right.
Can someone in the know give some rules of thumb as when it might be
helpful, if ever? Particularly in a FSFD.
Thanks.
I have seen discussions that using #pragma alloc_text(PAGE, …) can do more
harm than good if not done right.
Can someone in the know give some rules of thumb as when it might be
helpful, if ever? Particularly in a FSFD.
Thanks.
If the FSFD is a legacy driver, then probably only the DriverEntry() path is
good for paging. If you are using C++, then never use paged code or data.
The placement of functions called from C++ is very unpredictable and one
might get placed in paged memory where it might be referenced in the paging
path. If your driver was to only attach to volumes that cannot contain the
page file, then paging might work, but analyze carefully.
If it is a minifilter, I guess most of the same rules apply. Watch out for
function that can be called on a volume that can contain a page file. Also
watch out for use of C++. Create a .map file and see where each function
gets placed. All this can be done and will have to be done with each
build - automate with python, if you like.
“Neil Weicher” wrote in message news:xxxxx@ntfsd…
>I have seen discussions that using #pragma alloc_text(PAGE, …) can do
>more
> harm than good if not done right.
>
> Can someone in the know give some rules of thumb as when it might be
> helpful, if ever? Particularly in a FSFD.
>
> Thanks.
>
>
> Can someone in the know give some rules of thumb as when it might be
helpful, if ever? Particularly in a FSFD.
ANY pageable function can cause deadlock
if it handles something in the paging I/O path.
You must carefully consider which functions
is called from paging I/O request handlers
(IRP_MJ_READ, IRP_MJ_WRITE, maybe also IRP_MJ_SET_INFORMATION),
and not to put such function in PAGE section.
L.
Thanks, Ladislav,
What about IRP_MJ_FILE_SYSTEM_CONTROL, particularly mount and load?
I also read that the sum total of pageable code had to be at least 4096
bytes or it would not ever be paged, but I might have misunderstood that.
Any insight into that?
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, March 27, 2007 2:45 AM
Subject: Re: [ntfsd] PAGE code sections
>> Can someone in the know give some rules of thumb as when it might be
>> helpful, if ever? Particularly in a FSFD.
>
> ANY pageable function can cause deadlock
> if it handles something in the paging I/O path.
>
> You must carefully consider which functions
> is called from paging I/O request handlers
> (IRP_MJ_READ, IRP_MJ_WRITE, maybe also IRP_MJ_SET_INFORMATION),
> and not to put such function in PAGE section.
>