[PATCH 5/5] drm: allocate kernel mode-object IDs in cyclic fashion

[Daniel Vetter]

On Fri, Sep 11, 2015 at 11:47 AM, David Herrmann <dh.herrmann at gmail.com> wrote:
> On Wed, Sep 9, 2015 at 3:03 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Wed, Sep 09, 2015 at 02:21:33PM +0200, David Herrmann wrote:
>>> Now that we support connector hotplugging, user-space might see
>>> mode-object IDs coming and going asynchronously. Therefore, we must make
>>> sure to not re-use object IDs, so to not confuse user-space and introduce
>>> races. Therefore, all kernel-allocated objects will no longer recycle
>>> IDs. Instead, we use the cyclic idr allocator (which performs still fine
>>> for reasonable allocation schemes).
>>>
>>> However, for user-space allocated objects like framebuffers, we don't
>>> want to risk allowing malicious users to screw with the ID space.
>>> Furthermore, those objects happen to not be subject to ID hotplug races,
>>> as they're allocated and freed explicitly. Hence, we still recycle IDs
>>> for these objects (which are just framebuffers so far).
>>
>> Since atomic also blob properties can be created by userspace. And there
>> has actually been trouble once with some attempt in SNA to cache the edid
>> blob without realizing that they get reused. So working userspace _always_
>> has to re-read the blob prop to make sure it has the current one anyway.
>
> I see. So lets include the blobs in recycle, too? This makes the patch
> a bit more clunky as we need to distinguish kernel-generated blobs and
> user-space generated blobs. I'll see how that works out.

What I meant to say is that userspace already must be able to cope
with kernel-generated edid blobs recycling ids. Which means you
actually don't need to make this distinction. We just need to add
blobs to the type of objects where we should recycle. Aside from that
we also have kernel-generated framebuffers (e.g. fbdev or takeover
from bios or universal cursors) with the same problems of potentially
confusing userspace. So blobs aren't really any different than
framebuffers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch