Re: [ros-diffs] [greatlrd] 21611: kjk_hyperion : "Breaking auditing lock for a temporary fix: allow ExEnterCriticalRegionAndAcquireFastMutexUnsafe and ExReleaseFastMutexUnsafeAndLeaveCriticalRegion to be called from any thread; fixes UserEnterShared, UserEnterExclusive and UserLeave in win32k"
greatlrd@svn.reactos.org wrote:
Author: greatlrd Date: Sun Apr 16 20:04:28 2006 New Revision: 21611
URL: http://svn.reactos.ru/svn/reactos?rev=21611&view=rev Log: kjk_hyperion : "Breaking auditing lock for a temporary fix: allow ExEnterCriticalRegionAndAcquireFastMutexUnsafe and ExReleaseFastMutexUnsafeAndLeaveCriticalRegion to be called from any thread; fixes UserEnterShared, UserEnterExclusive and UserLeave in win32k"
Modified: trunk/reactos/ntoskrnl/ex/fmutex.c
Modified: trunk/reactos/ntoskrnl/ex/fmutex.c URL: http://svn.reactos.ru/svn/reactos/trunk/reactos/ntoskrnl/ex/fmutex.c?rev=216...
This fix is broken. The real problem is win32k, you should fix that instead.
Best regards, Alex Ionescu
Alex Ionescu wrote:
This fix is broken. The real problem is win32k, you should fix that instead.
win32k has no "problem" under this point of view, and as much as we all like to blame win32k, there is nothing inherently wrong in its use of ExEnterCriticalRegionAndAcquireFastMutexUnsafe. If you want to explain, please do
KJKHyperion wrote:
Alex Ionescu wrote:
This fix is broken. The real problem is win32k, you should fix that instead.
win32k has no "problem" under this point of view, and as much as we all like to blame win32k, there is nothing inherently wrong in its use of ExEnterCriticalRegionAndAcquireFastMutexUnsafe. If you want to explain, please do _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Like I said on the PM, those functions must not be called by non-system threads.
I added those calls as a hack since win32k depended on the broken implementation of fast mutexes.
Best regards, Alex Ionescu
-
Alex Ionescu -
KJKHyperion