On Sun, Jan 19, 2014 at 12:36:20PM +0100, Daniel Vetter wrote:
On Sun, Jan 19, 2014 at 2:28 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
Testing running out of file descriptors shows a NULL pointer dereference in i915_gem_alloc_object() because base.filp ends up being NULL. So the line
mapping = file_inode(obj->base.filp)->i_mapping;will cause an oops. The call chain is
SyS_ioctl -> do_vfs_ioctl -> drm_ioctl -> i915_gem_create_ioctl -> i915_gem_create -> i915_gem_alloc_object
Now, some functions do test "base.filp" for NULL (see for example i915_gem_pread_ioctl()) so clearly people know that the filp may not exist. But that path does not.
This is unrelated since only shmem backed objects (should) have base.filp set, but other gem objects (backed by stolen mem or from dma-buf) don't have that. A bunch of gem ioclts aren't supported with these special objects (like pread/pwrite) and so we check for that and bail out.
Comments? Patches even?
If we fail to allocate the shmem file drm_gem_object_init should fail and i915_gem_alloc_object should bail out early. Apparently that doesn't work as it should. On a quick check it's not the lack of _OR_NULL in drm_gem_object_init so I'm not really sure what's going on here. I'll try to reproduce this here meanwhile.
Adding dri-devel since other gem drivers should be equally affected.
This took much longer than I'll ever dare to admit, but I think I've stitched a testcase together for this and pushed it to our i915 test repo:
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=70082e367771...
But I couldn't blow up my system here with that. Same on stable kernels, so this isn't something we've fixed by accident in drm-intel-next. -Daniel