Messages in this thread | | | Subject | Re: [PATCH 1/6] drm/i915: Fix lock order reversal in GTT pwrite path. | From | Peter Zijlstra <> | Date | Sat, 28 Mar 2009 01:54:32 +0100 |
| |
On Thu, 2009-03-26 at 17:43 -0700, Jesse Barnes wrote: > On Wed, 25 Mar 2009 14:45:05 -0700 > Eric Anholt <eric@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 <eric@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?
While officially supported, a 128k kmalloc is _very_ likely to fail, it would require an order 5 page allocation to back that, and that is well outside of comfortable.
| |