[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