Bug 8258

Summary:	drm_handle_t isn't 64bit safe
Product:	DRI	Reporter:	Andres Salomon <dilinger>
Component:	libdrm	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	high
Version:	XOrg git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Andres Salomon 2006-09-13 15:34:47 UTC

On linux, drm_handle_t is typedef'd to an unsigned int; on other platforms, it
is typedef'd to an unsigned long.  On 64bit systems, this causes problems due to
casting; it ends up being used as an off_t, which is 8 bytes; an unsigned int is
only 4.

You can see gcc spitting up warnings during the build here:
http://bugs.debian.org/324560

Comment 1 Paul Mackerras 2006-09-13 16:09:19 UTC

drm_handle_t is deliberately 32-bit so that it is compatible between 32-bit and
64-bit servers, clients and the kernel.  The kernel DRM code goes to some
lengths to produce drm_handle_t values that fit in 32 bits even on 64 bit systems.

drm_handle_t is not a pointer and should not be being cast to/from a pointer.

Comment 2 Andres Salomon 2006-09-23 00:09:46 UTC

While it is nice that the kernel ensures that drm_map_t handles (and other
handles) all fit within a 32bit integer so we can have a functional 32bit
userspace with a 64bit kernel, I think it's a bit shortsighted to have the
userspace library simply assume that this will always be the case in the kernel
code.  Why not have drm_handle_t be a 64bit integer on platforms that support
it?  Alternatively, why use a void* for drm_map_t and drm_ctx_priv_map_t's
handles when you could use a drm_handle_t, an unsigned int, an unsigned long
int, or an off_t?

Comment 3 chemtech 2013-03-15 14:21:41 UTC

Andres Salomon 
Do you still experience this issue with newer soft ?
Please check the status of your issue.

Comment 4 Adam Jackson 2019-05-29 17:21:53 UTC

drm_handle_t is still 'unsigned int', but it's also only present in legacy (pre-KMS) APIs, so, meh.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.