[PATCH 0/7] User-created blob properties

[Daniel Vetter]

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

[PATCH 0/7] User-created blob properties

[Daniel Stone]

Hi,

On Thursday, May 7, 2015, Daniel Vetter  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: 

[PATCH 0/7] User-created blob properties

[Daniel Stone]

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.

Cheers,
Daniel