Details
-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
0.4.15-dev-xxxxx
Description
How to reproduce: Install VBox guest additions, then try to uninstall them
Backtrace:
kd> kp
|
# ChildEBP RetAddr
|
00 f1246918 80505421 nt!_ExAcquireFastMutex(struct _FAST_MUTEX * FastMutex = 0xb8a65e2c)+0x4b [E:\amd64\reactos\ntoskrnl\include\internal\ex.h @ 1376]
|
01 f1246924 80504362 nt!_MmLockSectionSegment(struct _MM_SECTION_SEGMENT * Segment = 0xb8a65e20, char * file = 0x805a3980 "E:\amd64\reactos\ntoskrnl\mm\section.c", int line = 0n929)+0x11 [E:\amd64\reactos\ntoskrnl\mm\section.c @ 74]
|
02 f1246964 804ffdb5 nt!MmpFreePageFileSegment(struct _MM_SECTION_SEGMENT * Segment = 0xb8a65e20)+0x32 [E:\amd64\reactos\ntoskrnl\mm\section.c @ 931]
|
03 f12469a0 8050037e nt!MmDereferenceSegmentWithLock(struct _MM_SECTION_SEGMENT * Segment = 0xb8a65ba0, unsigned char OldIrql = 0x00 '')+0x215 [E:\amd64\reactos\ntoskrnl\mm\section.c @ 1060]
|
04 f1246a2c f7b93db4 nt!MmFlushImageSection(struct _SECTION_OBJECT_POINTERS * SectionObjectPointer = 0xb8b81da0, _MMFLUSH_TYPE FlushType = MmFlushForDelete (0n0))+0x40e [E:\amd64\reactos\ntoskrnl\mm\section.c @ 4279]
|
05 f1246ae0 f7b9105d fastfat!FatSetDispositionInfo(struct _IRP_CONTEXT * IrpContext = 0xb8cb2b68, struct _IRP * Irp = 0xb8b02008, struct _FILE_OBJECT * FileObject = 0xb8a62e18, struct _FCB * Fcb = 0xe172b998)+0xb4 [E:\amd64\reactos\drivers\filesystems\fastfat_new\fileinfo.c @ 2496]
|
06 f1246b90 f7b9184d fastfat!FatCommonSetInformation(struct _IRP_CONTEXT * IrpContext = 0xb8cb2b68, struct _IRP * Irp = 0xb8b02008)+0x4cd [E:\amd64\reactos\drivers\filesystems\fastfat_new\fileinfo.c @ 948]
|
07 f1246be4 8047ff27 fastfat!FatFsdSetInformation(struct _VOLUME_DEVICE_OBJECT * VolumeDeviceObject = 0xb8dfd020, struct _IRP * Irp = 0xb8b02008)+0xdd [E:\amd64\reactos\drivers\filesystems\fastfat_new\fileinfo.c @ 331]
|
08 f1246c10 8047b69b nt!IofCallDriver(struct _DEVICE_OBJECT * DeviceObject = 0xb8dfd020 Device for "\FileSystem\fastfat", struct _IRP * Irp = 0xb8b02008)+0xc7 [E:\amd64\reactos\ntoskrnl\io\iomgr\irp.c @ 1286]
|
09 f1246cec 80404040 nt!NtSetInformationFile(void * FileHandle = 0x000003d4, struct _IO_STATUS_BLOCK * IoStatusBlock = 0x0084f730, void * FileInformation = 0x0084f763, unsigned long Length = 1, _FILE_INFORMATION_CLASS FileInformationClass = FileDispositionInformation (0n13))+0x6fb [E:\amd64\reactos\ntoskrnl\io\iomgr\iofunc.c @ 3407]
|
0a f1246d10 80550b98 nt!KiSystemCallTrampoline+0x19
|
0b f1246d5c 80403e89 nt!KiSystemServiceHandler(struct _KTRAP_FRAME * TrapFrame = 0xf1246d64, void * Arguments = 0x0084f6c4)+0x278 [E:\amd64\reactos\ntoskrnl\ke\i386\traphdlr.c @ 1844]
|
0c f1246d5c 7c9379e9 (T) nt!KiFastCallEntry+0x94
|
0d 0084f6b8 7c96b78f (T) ntdll!KiFastSystemCallRet
|
0e 0084f6bc 7c65cdd8 ntdll!NtSetInformationFile+0xc
|
Problem is that MmFlushImageSection acquires the PFN lock, then calls MmDereferenceSegmentWithLock, which in turn calls MmpFreePageFileSegment, which aquires the PFN lock, if it wasn't acquired before, and also releases it before calling MmFreePageTablesSectionSegment (if it wasn't aquired before). If the loack was aquired before, MmFreePageTablesSectionSegment will be called with the lock held and then calls _MmLockSectionSegment, which tries to acquire a fast mutex.
Fix:
- Stop calling MmDereferenceSegmentWithLock while holding the PFN lock, because the function can clearly not handle, as it needs to lock the section eventually and just holding the PFN lock is not good enough, since it can be called without it held as well (should be renamed). Holding the PFN lock for such extended times is a bad idea, too.
- Add proper IRQL and lock requirements annotation to all functions involved
- Add ASSERTs to all functions involved.
Attachments
Issue Links
- duplicates
-
-
- Resolved
-