[Intel-gfx] [PATCH 0/5] Fixup pwrite/pread with gtt mmapped user addresses
Daniel Vetter
daniel.vetter at ffwll.ch
Sat Sep 17 20:55:44 CEST 2011
Hi all,
Original bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=38115
This bug can e.g. be hit with glBufferData(dst, glBufferMap(src))
Testcase is gem_mmap_gtt.
Neglecting the trivial cleanup patch 2, patch 1 converts the possible
deadlock in an errornous -EFAULT. I've already submitted this, but
include it here again for completeness. Patches 3-5 then fix this up.
Imo there's a bit more work left to do (like properly prefaulting,
which would have papered over this bug). But I think this is the
minimal set required to fix the bug and I've wanted to get early
feedback on the approach and on possible race issues.
I think patch 3-5 are not cc:stable material because they're too
invasive (maybe even stuff for -next). The prefaulting patch will
be much simpler, less invasive and it essentially reduces the issue to
a tiny race, so I suggest that for backporting.
So review, comments highly appreciated.
Yours, Daniel
Daniel Vetter (5):
io-mapping: ensure io_mapping_map_atomic _is_ atomic
drm/i915: drop KM_USER0 argument to k(un)map_atomic
drm/i915: fall through pwrite_gtt_slow to the shmem slow path
drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
drm/i915: rewrite shmem_pread_slow to use copy_to_user
drivers/gpu/drm/i915/i915_gem.c | 324 ++++++++++++++-------------------
drivers/gpu/drm/i915/i915_gem_debug.c | 6 +-
include/linux/io-mapping.h | 2 +
3 files changed, 140 insertions(+), 192 deletions(-)
--
1.7.6
More information about the Intel-gfx
mailing list