On Fri, Sep 11, 2015 at 11:47 AM, David Herrmann dh.herrmann@gmail.com wrote:
On Wed, Sep 9, 2015 at 3:03 PM, Daniel Vetter daniel@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