Re: [ros-diffs] [hbirr] 14421: - Use IoBuildAsynchronousFsdRequest instead IoBuildSynchronousFsdRequest in NtRead/WriteFile.

[Gunnar Dalsnes]

[e-mail] wrote:
> Use IoBuildAsynchronousFsdRequest instead IoBuildSynchronousFsdRequest in NtRead/WriteFile.
> Guard the calls to IoBuildAsynchronousFsdRequest with an exception frame.
>
> Modified: trunk/reactos/ntoskrnl/io/rw.c

I dont understand these changes... Why did you change from sync. to 
asycn. version, and whats the point with try/except around 
IoBuildAsynchronousFsdRequest???

Gunnar

[Hartmut Birr]

Gunnar Dalsnes wrote:
> [e-mail] wrote:
> > Use IoBuildAsynchronousFsdRequest instead
> >
> > IoBuildSynchronousFsdRequest in NtRead/WriteFile.  - Guard the calls
> > to IoBuildAsynchronousFsdRequest with an exception frame.
> >
> > Modified: trunk/reactos/ntoskrnl/io/rw.c
>
> I dont understand these changes... Why did you change from sync. to
> asycn. version, and whats the point with try/except around
> IoBuildAsynchronousFsdRequest???

I've guarded the calls to IoBuildAsynchronousFsdRequest because
IoBuildAsynchronousFsdRequest calls MmProbeAndLockPages which can raise
an exception if the buffer isn't valid.

IoBuildSynchronousFsdRequest does always queue the irps to the threads
cancel/cleanup list. This isn't correct for asynchronous requests.

- Hartmut

[Gunnar Dalsnes]

> IoBuildSynchronousFsdRequest does always queue the irps to the threads
> cancel/cleanup list. This isn't correct for asynchronous requests.

Hehe, this is a know misunderstanding:
The Synchronous/Asynchronous in IoBuildXxx refers to wheter the thread 
context is non-arbitrary(synch) or arbitrary(asynch)! Yes, really! I can 
only blame microsoft for makin such bad names:-D

A syscall is always in a non-arbitrary thread context thus it should 
always use IoBuildSynchronousFsdRequest (or should it? see my other post).

Gunnar
> Hartmut
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Gunnar Dalsnes]

I googled and found some stuff:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q326315

//
// If the target device object is set up do direct i/o (DO_DIRECT_IO), then
// IoBuildAsynchronousFsdRequest creates an MDL to describe the buffer
// and locks the pages.

We also probe and lock, so it seems ros IoBuildAsynchronousFsdRequest is 
correct at this point. But the docs says nothing about 
IoBuildAsynchronousFsdRequest throwing an exception, and i have never 
seen any code guarding a call to IoBuildAsynchronousFsdRequest either...

googled some more:

http://drucifer.shackspace.com/bsod.txt

DRIVER_VERIFIER_IOMANAGER_VIOLATION (0xC9)
8. Call to IoBuildAsynchronousFsdRequest threw an exception
2 - the Device object
3 - the IRP major function
4 - the exception status

Hmm. So it seems IoBuildAsynchronousFsdRequest CAN throw and exception 
but is not allowed to do so, even thou it uses MmProbeAndLockPages! Imo, 
this can only mean that its not allowed to use 
IoBuildAsynchronousFsdRequest/IoBuildSynchronousFsdRequest with umode 
buffers! (MmProbeAndLockPages with kmode buffer will never fail)

Gunnar

Gunnar Dalsnes wrote:
> [e-mail] wrote:
> > Use IoBuildAsynchronousFsdRequest instead
> >
> > IoBuildSynchronousFsdRequest in NtRead/WriteFile.  - Guard the calls 
> > to IoBuildAsynchronousFsdRequest with an exception frame.
> >
> > Modified: trunk/reactos/ntoskrnl/io/rw.c
>
> I dont understand these changes... Why did you change from sync. to 
> asycn. version, and whats the point with try/except around 
> IoBuildAsynchronousFsdRequest???
>
> Gunnar
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev