[PATCH 0/7] User-created blob properties
Daniel Vetter
daniel at ffwll.ch
Thu May 7 01:34:57 PDT 2015
On Mon, Apr 20, 2015 at 07:22:49PM +0100, Daniel Stone wrote:
> Hi,
> This is the spritual successor to the modes-as-blob-properties patchset.
>
> There are some fairly drastic differences though, namely:
> - the referenced object in this case is the blob property - being just
> a dumb chunk of data - rather than attempting to refcount modes;
> meaning that ...
> - userspace doesn't see blob mode IDs from the connector list, only
> from the current mode, so it really needs to create the mdoes again
> from the drm_mode_modeinfo it gets
> - the mode-constness series has been split out and will be sent
> separately
>
> Actually exposing the mode property does largely seem to work, but
> need to fix i915 to not copy CRTC states by value before it does.
>
> This series still retains the concept of a type within the create blob
> ioctl, on the grounds that otherwise we could allow userspace to create
> unbounded allocations in the kernel with no attribution. Other than
> matching size, the type has no meaning per se.
Yeah I'm a bit late, but not sure whether trying to restrict the size is
all that useful really. Userspace can still just create a bazillion of
them and starve the kernel of memory. And as long as we use kmalloc
there'll be a natural limit to how big a blob can be.
I'm bringing this up since if we go with encoding size limits we'll need
to add a new type of blob for each use, and with gamma tables, csc
matrices and other stuff there will be lots of them.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list