On Sun, Jan 19, 2014 at 9:31 AM, Daniel Vetter <daniel@xxxxxxxx> wrote:
>
> 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:
So I was testing a patch that limits one user to fewer than the global
system resource files, and the oops happened just once, so it might
have been a lucky fluke, with the failure *usually* happening
somewhere else.
And I'm beginning to think I misread the oops. I was *assuming* it was
due to a NULL file pointer access in that function because of the way
I triggered it, but now that I look closer at the disassembly, what
seems to actually be happening is that the (inlined)
i915_gem_object_free() function does
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
kmem_cache_free(dev_priv->slab, obj);
and it's "base.dev" that is NULL, so the dev_private access is the one
that oopses.
And it is related to running out of file descriptors, but indirectly:
the lack of file descriptors is making drm_gem_object_init() fail
(correctly), but it has failed *before* it has done the
drm_gem_private_object_init(dev, obj, size);
which is why that oops then happens.
So my suggestion is that drm_gem_object_init() should do that
drm_gem_private_object_init() part regardless of whether the
shm_file_setup() failed or not.
Makes sense?
Linus
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
