On Fri, Jun 29, 2018 at 07:38:32PM +0300, Ville Syrjälä wrote: > On Fri, Jun 29, 2018 at 06:27:28PM +0200, Michel Dänzer wrote: > > On 2018-06-29 06:12 PM, Ville Syrjälä wrote: > > > On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel Dänzer wrote: > > >> From: Michel Dänzer <michel.daenzer@xxxxxxx> > > >> > > >> The property size may be controlled by userspace, can be large (I've > > >> seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be > > >> physically contiguous. > > > > > > I wonder if we should enforce some kind of reasonable limit > > > on the blob size. Looks like we allow anything up to > > > ULONG_MAX currently. We can't tell at createblob time how > > > the thing is going to be used, so can't have any kind > > > of property specific limit unfortunately. > > > > The failure I was seeing was for a gamma LUT, so a size limit alone > > cannot solve the issue. > > Sure. I was just thinking that maybe we shouldn't allow someone to > allocate unlimited amounts of kernel memory via this interface. But > to do that effectively we'd also need to limit the total amount used > by all blobs. People with drm master rights are allowed to pin enormous amounts of memory (through pinning of display buffers) ... I think simply requiring DRM_MASTER for the ioctl would be good enough. Atm anyone can abuse createblob to waste memory, which is a bit much. We haven't marked it with DRM_RENDER_ALLOW, so I think this is just an oversight really. I'll type a patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
