Question about 64-bit code safety

[Philip Prindeville]

Dave Airlie wrote:

>>If you're using a pointer as a nonce, don't you want to be sure that
>>it's unique?  Do you ever need to convert the handle back into a
>>pointer?
>>    
>>
>
>You know you could read the code and I think the mailing list history..
>  
>

You're right, I could... if I had a lot more time.  I try to follow 11
high volume mailing lists and a couple dozen minor ones in
addition to that...  Looking for any information about porting
code into the environment we're developing, picking up fixes,
etc.

Unfortunately, I have to skim based on subject lines, and often
times threads will go off onto a complete tangent that, while
extreme pertinent, is belied by the old subject line.

And if I had to read all of the tens of thousands of lines of code
that I'll need to port over the next few weeks... well, I'd still
be working on the first project.

>32-bits should be quite enough, its a handle, nothing else, the
>pointer gets hashed and sent to userspace and when sent back it gets
>unhashed and used.. in fact we don't have 32-bits, I think we actually
>only have 28-bits as mmap knocks of the bottom few bits....
>  
>

I was going by the warnings from gcc about pointers being
converted to integers with a loss of precision...  It's one of the
few useful tools to detect suspect code when trying to
ensure that outside code will compile and run in an AMD64
environment (or MIPS64 environment).

There have been in the past, and probably will be again, various
memory management schemes that interlace allocations across a
large address space (with unmapped gaps between allocations)
as a way of detecting various memory leaks...  as well as a way
to profile locality of access, perform rapid garbage collection,
etc. (see Mach, Purify, etc).

With a lot of small allocations, you can easily exceed a 32-bit
address space.

In my experience, for what it's worth, just about every assumption
eventually breaks...  Some with spectacular results.

You know the code better than I do.  There might be reasons
this won't happen that I'm unaware of.

-Philip


>no matter its enough for the DRM, we create at the moment about 5
>maps, so I'd hope we don't suddenly required 64-bits of map storage...
>
>  
>
>>In either case, you wouldn't want to drop the upper bits and lose
>>precision.
>>    
>>
>
>Why wouldn't we? we designed it like that.. 3 people involved all
>agreed this was a correct solution...
>
>Dave.
>  
>