Fsd prefast question FsRtlFastLock

In the hopes that some FSD god could enlighten me, I ask the following
question: I ran prefast over a file system that I am working on, in doing
so I got a 28159 warning from prefast indicating that I should call
FsRtlFastLock instead of FsRtlPrivateLock. Turns out that I do indeed
call FsRtlFastLock, but it is a macro defined in ntifs.h which is calling
FsRtlPrivateLock.

So, what’s the scoop here? Is this a prefast bug or is this trying to
tell me something useful?

This looks like a bug to me, but perhaps it’s a suggestion that you
shouldn’t be using the FsRtl package for managing byte range locks
(that’s probably the only option if you are in an organization that
doesn’t allow #pragma disables of prefast detected bugs.)

Here are the definitions from Win 7 WDK version of ntifs.h:

#if (NTDDI_VERSION >= NTDDI_WIN2K)

__checkReturn

__drv_maxIRQL(APC_LEVEL)

__drv_preferredFunction(FsRtlFastLock, “Obsolete”)

NTKERNELAPI

BOOLEAN

FsRtlPrivateLock (

__in PFILE_LOCK FileLock,

__in PFILE_OBJECT FileObject,

__in PLARGE_INTEGER FileOffset,

__in PLARGE_INTEGER Length,

__in PEPROCESS ProcessId,

__in ULONG Key,

__in BOOLEAN FailImmediately,

__in BOOLEAN ExclusiveLock,

__out PIO_STATUS_BLOCK Iosb,

__in_opt PIRP Irp,

__in_opt __drv_aliasesMem PVOID Context,

__in BOOLEAN AlreadySynchronized

);

#endif

//

// BOOLEAN

// FsRtlFastLock (

// __in PFILE_LOCK FileLock,

// __in PFILE_OBJECT FileObject,

// __in PLARGE_INTEGER FileOffset,

// __in PLARGE_INTEGER Length,

// __in PEPROCESS ProcessId,

// __in ULONG Key,

// __in BOOLEAN FailImmediately,

// __in BOOLEAN ExclusiveLock,

// __out PIO_STATUS_BLOCK Iosb,

// __in PVOID Context OPTIONAL,

// __in BOOLEAN AlreadySynchronized

// );

//

#define FsRtlFastLock(A1,A2,A3,A4,A5,A6,A7,A8,A9,A10,A11) ( \

FsRtlPrivateLock( A1, /* FileLock */ \

A2, /* FileObject */ \

A3, /* FileOffset */ \

A4, /* Length */ \

A5, /* ProcessId */ \

A6, /* Key */ \

A7, /* FailImmediately */ \

A8, /* ExclusiveLock */ \

A9, /* Iosb */ \

NULL, /* Irp */ \

A10, /* Context */ \

A11 /* AlreadySynchronized */ ) \

)

I think the point in the documentation is that you should not be calling
the private lock version (so, if you have an IRP.) The rest of this
looks like what you’d want to do in a fast I/O lock function, though.

That does suggest another option - don’t support fast I/O lock. Just
support the IRP version and call FsRtlProcessFileLock. Voila! Your
prefast flagged bug is gone.

I would note that FastFAT in Win7 uses FsRtlFastLock, so that would
suggest it is not prefast clean. That surprises me, since I can’t
imagine the WDK team would ship drivers that weren’t prefast clean.

Tony

OSR