linux-kernel - Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

Open Source and information security mailing list archives

Message-ID: <CAF6AEGtLP=S12tbiWSuHTGOrPEwftBC4ayxRRPhOL=2kEsi0DQ@mail.gmail.com>
Date:	Thu, 12 Sep 2013 20:59:16 -0400
From:	Rob Clark <robdclark@...il.com>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
Cc:	DRI Development <dri-devel@...ts.freedesktop.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: kill set_need_resched

hmm, looks like I cargo-cult'd the same into msm.

I guess in i915 (and ttm) case, the issue arises due to need for CPU
access to buffer via GTT?  In which case I should be safe to drop the
set_need_resched() as well? (Since CPU always has direct access to the
pages.)  Or am I missing something about the original issue that
necessitated set_need_resched()?

BR,
-R

On Thu, Sep 12, 2013 at 11:57 AM, Daniel Vetter <daniel.vetter@...ll.ch> wrote:
> This is just a remnant from the old days when our reset handling was
> horribly racy, suffered from terribly locking issues and often happily
> live-locked. Those days are now gone so we can drop the hacks and just
> rip the reschedule-point out.
>
> Reported-by: Peter Zijlstra <peterz@...radead.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d80f33d..3871060 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1389,14 +1389,11 @@ out:
>                 if (i915_terminally_wedged(&dev_priv->gpu_error))
>                         return VM_FAULT_SIGBUS;
>         case -EAGAIN:
> -               /* Give the error handler a chance to run and move the
> -                * objects off the GPU active list. Next time we service the
> -                * fault, we should be able to transition the page into the
> -                * GTT without touching the GPU (and so avoid further
> -                * EIO/EGAIN). If the GPU is wedged, then there is no issue
> -                * with coherency, just lost writes.
> +               /*
> +                * EAGAIN means the gpu is hung and we'll wait for the error
> +                * handler to reset everything when re-faulting in
> +                * i915_mutex_lock_interruptible.
>                  */
> -               set_need_resched();
>         case 0:
>         case -ERESTARTSYS:
>         case -EINTR:
> --
> 1.8.4.rc3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@...ts.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives