On Mon, May 6, 2013 at 7:59 PM, Ben Widawsky <b...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
