Hi,
On Thursday, May 7, 2015, Daniel Vetter <daniel@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