Hi,<br><br>On Thursday, May 7, 2015, Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 20, 2015 at 07:22:49PM +0100, Daniel Stone wrote:<br>
> This is the spritual successor to the modes-as-blob-properties patchset.<br>
><br>
> There are some fairly drastic differences though, namely:<br>
>   - the referenced object in this case is the blob property - being just<br>
>     a dumb chunk of data - rather than attempting to refcount modes;<br>
>     meaning that ...<br>
>   - userspace doesn't see blob mode IDs from the connector list, only<br>
>     from the current mode, so it really needs to create the mdoes again<br>
>     from the drm_mode_modeinfo it gets<br>
>   - the mode-constness series has been split out and will be sent<br>
>     separately<br>
><br>
> Actually exposing the mode property does largely seem to work, but<br>
> need to fix i915 to not copy CRTC states by value before it does.<br>
><br>
> This series still retains the concept of a type within the create blob<br>
> ioctl, on the grounds that otherwise we could allow userspace to create<br>
> unbounded allocations in the kernel with no attribution. Other than<br>
> matching size, the type has no meaning per se.<br>
<br>
Yeah I'm a bit late, but not sure whether trying to restrict the size is<br>
all that useful really. Userspace can still just create a bazillion of<br>
them and starve the kernel of memory. And as long as we use kmalloc<br>
there'll be a natural limit to how big a blob can be.<br>
<br>
I'm bringing this up since if we go with encoding size limits we'll need<br>
to add a new type of blob for each use, and with gamma tables, csc<br>
matrices and other stuff there will be lots of them.<br>
</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Daniel<span></span> </div>