On Thu, Sep 04, 2014 at 09:11:23AM +0200, Daniel Vetter wrote:
> In
> 
> commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c
> Author: Daniel Vetter <[email protected]>
> Date:   Thu Nov 15 17:17:22 2012 +0100
> 
>     drm/i915: clear up wedged transitions
> 
> I've accidentally inverted the EIO/wedged handling in the fault
> handler: We want to return the EIO as a SIGBUS only if it's not
> because of the gpu having died, to prevent userspace from unduly
> dying.
> 
> In my defence the comment right above is completely misleading, so fix
> both.
> 
> v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO
> when swap-in fails.

You mean drop the WARN_ON and the if...
 
> Reported-by: Chris Wilson <[email protected]>
> Cc: Chris Wilson <[email protected]>
> Cc: [email protected]
> Signed-off-by: Daniel Vetter <[email protected]>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6c685708a516..247ad18b8c3e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1596,9 +1596,12 @@ unlock:
>  out:
>       switch (ret) {
>       case -EIO:
> -             /* If this -EIO is due to a gpu hang, give the reset code a
> -              * chance to clean up the mess. Otherwise return the proper
> -              * SIGBUS. */
> +             /*
> +              * We eat errors when the gpu is terminally wedged to avoid
> +              * userspace unduly crashing (gl has no provisions for mmaps to
> +              * fail). But any other -EIO isn't ours (e.g. swap in failure)
> +              * and so needs to be reported.
> +              */
>               if (i915_terminally_wedged(&dev_priv->gpu_error)) {

Because you didn't actually make the change you set out to do :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to