On Thu, Oct 08, 2015 at 03:31:08PM +0100, Tvrtko Ursulin wrote:
>
> On 08/10/15 12:09, Chris Wilson wrote:
> >On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote:
> >>>-struct drm_i915_gem_object *
> >>>-i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
> >>>+static bool
> >>>+mark_free(struct drm_i915_gem_object *obj, struct list_head *unwind)
> >>>+{
> >>>+ BUG_ON(obj->stolen == NULL);
> >>
> >>I am fundamentally opposed to BUG_ONs which can be avoided. In this
> >>I see no value in hanging the machine while we could WARN_ON and
> >>return false.
> >
> >Don't bother with the WARN_ON. Either take the BUG_ON or accept that to
> >get to this point the machine is dead anyway and a warning here doesn't
> >help identify the root cause (better off with list debugging and memory
> >debugging). I have personally been converting these asserts over to a
> >dev-only compiletime option as I still find the BUGs more useful than
> >WARNs in the GEM code.
>
> This is one of the ones which are to be expected in development
> only. At that time I much prefer a WARN_ON since it potentially
> saves you one reboot cycle and there aren't really any downsides to
> it. Especially if, as you say, machine is dead already.
panic-on-oops ftw :-p
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
