On Wed, 25 Mar 2009 14:45:05 -0700 Eric Anholt <e...@anholt.net> wrote:
> Since the pagefault path determines that the lock order we use has to > be mmap_sem -> struct_mutex, we can't allow page faults to occur > while the struct_mutex is held. To fix this in pwrite, we first try > optimistically to see if we can copy from user without faulting. If > it fails, fall back to using get_user_pages to pin the user's memory, > and map those pages atomically when copying it to the GPU. > > Signed-off-by: Eric Anholt <e...@anholt.net> > --- > + /* Pin the user pages containing the data. We can't fault > while > + * holding the struct mutex, and all of the pwrite > implementations > + * want to hold it while dereferencing the user data. > + */ > + first_data_page = data_ptr / PAGE_SIZE; > + last_data_page = (data_ptr + args->size - 1) / PAGE_SIZE; > + num_pages = last_data_page - first_data_page + 1; > + > + user_pages = kcalloc(num_pages, sizeof(struct page *), > GFP_KERNEL); > + if (user_pages == NULL) > + return -ENOMEM; If kmalloc limits us to a 128k allocation (and maybe less under pressure), then we'll be limited to 128k/8 page pointers on 64 bit, or 64M per pwrite... Is that ok? Or do we need to handle multiple passes here? Looks good other than that. Reviewed-by: Jesse Barnes <jbar...@virtuousgeek.org> -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
