Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

[Robert K. <ro...@ko...>]

sorry for asking...
but is this solution also SMP capable. AFAIK raising IRQL is processor local ?
And may other CPUs run other processes' threads therewhile?

David Welch schrieb:

> On Thu, May 16, 2002 at 08:58:56PM +0200, Hartmut Birr wrote:
> > I doesn't understand your answer. I'm not sure, if my description of the
> > problem was right. The problem is the corrupted memory area queue from
> > kernel address space. Corruption of the queue is only possible, if there
> > occur two calls to a function which manipulate the queue (adding or
> > removing of entries). The queue is protected with a fast mutex of the
> > address space. This means, the corruption can only occur, if the calls
> > comes from the same thread. It is possible that a thread has locked the
> > address space and than a dpc or apc from the same thread is delivered
> > (completion function after a call to a device driver). This dpc or apc can
> > also lock the address space and manipulate the memory area queue. This does
> > corrupt the queue. The solution is to raise the irql at each manipulation
> > of the kernel address space. This disables the delivering of any dcp or apc
> > and the thread switching from irq 0.
> >
> I think I understand the description of the problem: the solution I am
> proposing if the locking is changed to a FASTMUTEX (so a thread holding
> the lock can't be interrrupted for an APC) and the functions that need to
> do address space operations from DISPATCH_LEVEL operate without touching
> the address space lock or any of the structures that are guarded by it
> then there is no need to go to DISPATCH_LEVEL (effectively a spinlock)
> when locking the address space.
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel