[PATCH 0/7] User-created blob properties

[Daniel Stone]

Hi,

On Thursday, May 7, 2015, Daniel Vetter <daniel at ffwll.ch> wrote:

> On Mon, Apr 20, 2015 at 07:22:49PM +0100, Daniel Stone wrote:
> > 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.
>

Fair enough. My thinking is that it would be easier to catch a userspace in
the act of gradually starving memory with a billion ioctls than all in one
big go, but see the argument.

Will drop that (nearly resolving Maarten's -E2BIG correction), and also dig
out the single-alloc patch I had earlier, but must've lost during rebase.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/e42b0404/attachment.html>