Denis Tonn wrote in a message to Mike Bilow:

MB> Memory which is allocated but uncommitted is handled internally 
MB> by OS/2 as "not present."  That is, an attempt to access the 
MB> memory causes a "not present" exception, which is the normal 
MB> behavior for an attempt to access committed memory that has 
MB> been swapped out.  However, the swap manager finds no table 
MB> entry for the requested page, since it is uncommitted, and 
MB> gracefully returns an error code.

 DT> Actually, it traps. Trap 000E to be exact.

Well, yes, Trap 000E is "Segment not present."  However, you get
a Ring 3 trap which affects the process, not a Ring 0 trap which kills
OS/2.  I consider this to be relatively graceful.

 DT> I have a lab for my  classes that does exactly this. You cannot 
 DT> access memory that is  uncommitted at all. If you have an 
 DT> exception handler in place, it will receive control with an 
 DT> exception report record and context record  on the stack. Your 
 DT> handler can then decide what to do.. But I  digress.. .. 

Actually, it is perfectly legal to set up a handler to intercept Trap 000E
at Ring 3 and try to commit the memory in question.

MB> This is not quite accurate.  The least significant two bits of 
MB> a selector code its privilege; any selector ending in 7h is 
MB> therefore a Ring 3 selector.  This is an Intel hardware issue, 
MB> not an 

 DT> This exactly what I mean. Here is a small cut from a dump.
 DT> You can  see the same thing under the debug kernel: 

 DT> # dg 28
 DT> 0028  LDT     Bas=a8ea7000 Lim=0000ffff DPL=0 P   

 DT> # dl 7
 DT> 0007  Data    Bas=a8ea7000 Lim=0000ffff DPL=3 P  RO        

 DT> Note that selector 7 (and it *is* an application accessable
 DT> data  descriptor, abet read only) is the same base address
 DT> at the LDT.  

Keep in mind that the debug kernel makes no attempt to validate that the
selector you are aiming for is actually a selector at all.  You can ask for
nonsense and get nonsense in reply, and it is up to you to know.  That
said, and without a debug kernel running in front of me, I would agree that
your dump above does certainly look as if 0007h is a RO Ring 3 *alias* for
the LDT.

MB> OS/2 issue.  Buffers passed from Ring 3 to Ring 0, as arise 
MB> in a DosDevIOCtl() call, will generally be mapped to 
MB> selector 0017h.  Temporary selectors mapped by 

 DT> Selector 17 will tile to a flat address of %20000 - always.

Perhaps that is true in a process context, but OS/2 uses 0017h for a number
of other things, especially inside Ring 0 code.  Several of the DevHelp
calls depend upon the 0017h being remapped.

MB> Processes are not supposed to be able to read their own LDTs.

 DT> But in fact they can. It is an analomy, but selector 7
 DT> *does* always  point to the base of the LDT. 

That's an interesting point.

 DT>   I finally did some testing on the subject. All unique
 DT> allocations  still occur on 64K boundries (at least up to
 DT> FP17) even without the  tiled bit.

It is documented that all extent versions of OS/2 on Intel allocate tiled
memory even if not specifically requested.  This is supposedly subject to
change, but certainly not in FP17 and certainly not without considerable
wailing and gnashing of teeth.

 DT> But I experimented a bit more. I allocated 3 blocks of  memory.
 DT>  The first test without the commit flag, and only 1 byte in
 DT> size.  Since the minimum allocation unit is 4K, I still one
 DT> page - but  uncommitted. I then proceeded to setmem 8 pages
 DT> without error.  Note that this goes well beyond the original
 DT> address (yes address!) allocation. 
 DT>  Then I allocated 1 byte WITH the commit flag, I had
 DT> immediate access  to the first page and was able to setmem
 DT> an additional 5 pages (as far as I tested). Still able to
 DT> setmem more than I "allocated".   Then I allocated 32K
 DT> without the commit flag, and commited the first  4 pages of
 DT> this and caused a trapdump (I am getting good at that) to 
 DT> easily see the tiled address in the LDT. The tiled addresses
 DT> only  showed 4 pages mapped in the LDT. 
 DT>  Lastly I allocated 1 byte without the commit flag, then
 DT> tried to  setmem the pages until the setmem failed. I was
 DT> able to cleanly setmem the first 16 pages of the returned
 DT> address range but failed as soon as I crossed the next 64K
 DT> boundry. 

I think what you have proven is that DosSetMem() is broken!  The real
question is not how DosSetMem() is polluting the PTEs, but rather what
happens if you actually try to access the memory supposedly being
committed.  In theory, DosSetMem() should return an outright error if you
try to commit unallocated memory, but I suspect no one made a big effort to
test this at IBM.  Among other things, the success or failure of such an
operation will depend upon the accidental or coincidental contiguity of
allocations.

 DT> Which leads me to wonder what the above comment is all
 DT> about. I  suspect that they are "preparing" us for changes
 DT> in the memory  allocation method. And possibly removing the
 DT> default (and automatic)  allocation on tiled (64K)
 DT> boundries. 

There is no important reason to remove automatic tiling under OS/2 on
Intel.  It doesn't really hurt anything, and changing it would probably
break a lot of code that is technically incorrect.  However, the reason for
the documentation warnings about automatic tiling being subject to change
was because of OS/2 for the PowerPC, where neither tiling nor 16-bit
interoperation were much of an issue.  It would have been foolish for OS/2
on PowerPC to have preserved this 64 KB tiling in order to accommodate
buggy programs which depend upon the idiosyncratic behavior of OS/2 on
Intel.
 
-- Mike


---