On Mon, 5 Dec 2011 22:40:53 +0100, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > The gtt_pwrite slowpath grabs the userspace memory with > get_user_pages. This will not work for non-page backed memory, like a > gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit > -EFAULT in the gtt paths. > > Now the shmem paths have exactly the same problem, but this way we > only need to rearrange the code in one write path. > > v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed. > > v3: Make the codeflow around phys_pwrite clearer as suggested by Chris > Wilson. > > Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch> For the series, Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk> (Just a shame about the alignment of the if() ;-) We've discussed this series (of which these are the pure bug fixes) a lot over IRC and the extra complication of dropping the lock during the slow copy does seem to be the simplest approach. And with the prefault patch, we can ignore the extra complication almost all the time. -Chris -- Chris Wilson, Intel Open Source Technology Centre
