[PATCH 0/7] User-created blob properties
daniel at fooishbar.org
Thu May 7 02:15:26 PDT 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dri-devel