[Intel-gfx] drm modeset identifiers and xf86-video-intel

[Mark Kettenis]

> Date: Thu, 7 Apr 2016 21:49:22 +0100
> From: Chris Wilson <chris at chris-wilson.co.uk>
> 
> On Thu, Apr 07, 2016 at 08:20:15PM +0200, Mark Kettenis wrote:
> > On OpenBSD I implemented idr_alloc() to return random IDs.  While the
> > xf86-video-modesetting driver is perfectly happy with this, the
> > xf86-video-intel driver doesn't like it very much.  I quickly figured
> > out that that driver truncates the identifiers to 8-bits when it
> > stores the values in its sna_crtc data structure.  But the modeset
> > identifiers are clearly 32-bit in the drm API, and the idr_alloc()
> > call that allocates them doesn't limit their values in any way.  So
> > I'd say this is a bug in the xf86-video-intel driver.  Or do people
> > consider it reasonable for the driver to expect the values to be
> > smaller than 256?  Then the drm kernel code should probably specify an
> > upper limit in the idr_alloc call.
> > 
> > Fixing the xf86-video-intel driver isn't completely trivial.  But of
> > people do agree this is something that should be fixed, I'll give it a
> > go.
> 
> Neither does it limit the kernel ABI since it is using inside knowledge
> of how linux works, nor is it difficult to change if you really want to use
> randomised numbers and a hash lookup in the kernel.
> -Chris

Hi Chris,

The main motivation for using the randomised IDs is to make the
numbers returned by the DRM_IOCTL_GEM_FLINK ioctl a little bit harder
to guess.  It seems that in other places, sequential IDs make more
sense.  I do however wonder if it is possible to end up creating more
than 255 modeset objects.  That would cause problems even on Linux.
If there is no such risk, I'll probably change the OpenBSD
implementation of idr_alloc() to do sequential allocations, and use
the randomising allocator only for the identifiers returned by the
DRM_IOCTL_GEM_FLINK ioctl.

Thanks,

Mark