On Sat, 9 Jul 2011 09:38:51 +0100, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > These paths hold onto the struct mutex whilst accessing pages. In > order, to prevent a recursive dead-lock should we fault-in a GTT mapped > page we need to return -EFAULT and fallback to the slow path. > > Lockdep has complained before about the potential dead-lock, but rvis is > the first application found to sufficiently abuse the API to trigger it. > > Cursory performance regression testing on a 1GiB PineView system using > x11perf, cairo-perf-trace, glxgears and a few game benchmarks suggested > no large regressions with just a 2% slowdown for firefox. The caveat is > that this was an otherwise idle system and that for 32-bit systems > io_mapping_map_atomic_wc() already disabled page-faults. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115 > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > --- > drivers/gpu/drm/i915/i915_gem.c | 22 ++++++++++++++++++++-- > 1 files changed, 20 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 2fce620..ecb27fd 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c
> - vaddr = kmap_atomic(page, KM_USER0); > + vaddr = kmap_atomic(page); > + /* We have to disable faulting here in case the user address > + * is really a GTT mapping and so we can not enter > + * i915_gem_fault() whilst already holding struct_mutex. > + */ > + pagefault_disable(); > ret = __copy_from_user_inatomic(vaddr + page_offset, > user_data, > page_length); > - kunmap_atomic(vaddr, KM_USER0); > + pagefault_enable(); > + kunmap_atomic(vaddr); does this even compile? Looks like you dropped an arg. Looks like a reasonable fix for the problem, though.
pgpZ1NyUHCi5n.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
