[Intel-gfx] [PATCH 01/12] drm/i915: Assert mutex_is_locked on context lookup

[Daniel Vetter]

On Mon, May 6, 2013 at 7:59 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
>
> Why I wanted a BUG: When you get a ref to an object without holding a
> lock you get a potentially unsafe pointer (to which we will be writing).
> If the context object memory is freed, and we write to it, we have a
> potential to late scribble over <insert your file system of choice>
> memory. There is probably a similar security implication there as well.
> Many of us are used to, and capable of recovering from GPU hangs, but
> less of us like to deal with FS recovery.
>
> I actually believe all "get" code like this (backed with refcounts)
> should BUG and not WARN.

Historically we've screwed up locking in the driver load/teardown,
suspend/resume and panic paths. Blowing up with a BUG_ON in there
tends to be pretty bad for debugging. And there's pretty much no
chance of a hostile party being able to exploit a race.

So _especially_ for locking checks imo only WARN is acceptable.

Otoh if such a race is indeed expoitable from userspace and it escaped
into a released kernel that means we have a pretty gapping hole in our
test coverage. Fixing that sounds more fruitful to me than making bug
reporter's life harder.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch