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>
