28 Jul
2008
28 Jul
'08
3:23 p.m.
Alex wrote:
It looks like a guarded mutex is being acquired at DPC
level. That's
pretty bad.
Well, at least it's redundant and useless. :-)
Pushlocks shouldn't be acquired at DPC level either
Indeed. If "you" are at DPC level, you have but one synchronization to
care about - SMP (i.e. CPU<->CPU).
, but there's no
ASSERTs in the pushlock code that check for that.
An oversight that should be fixed, I'm sure (even if it happened to
slow down the system by a whole order of magnitude, which it won't).
MMProbeAndLockPages should never be called for paged
pool addreses
while at DPC level,
Should MmProbeAndLock ever be called at IRQL above APC level? I mean,
what if the probing fails? Should the paging executive somehow preempt
this call and page in the missing pages (or should it simply throw a
"page not present" exception - not too great to do at DPC level I'd
say)?
which means the driver probably called it for a
non-paged pool address.
If my previous suspicion is correct, I build on that and suspect this
is an error in itself. The ProbeAndLock call should be done at APC
level (though I may be completely wrong, but do read my finishing
line).
In that case, the whole loop about checking if the page
is present
and
then faulting it in is irrelevant, and won't
happen.
Right. Page fault at DPC level == Bad Move(tm).
--
Mike