On Thu, Sep 10, 2015 at 10:44:14AM +0100, Tvrtko Ursulin wrote:
>
> On 09/09/2015 04:03 PM, Chris Wilson wrote:
> >On Wed, Sep 09, 2015 at 02:56:16PM +0100, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 08/10/2015 09:51 AM, Chris Wilson wrote:
> >>>+out:
> >>> drm_free_large(pvec);
> >>
On 09/09/2015 04:03 PM, Chris Wilson wrote:
On Wed, Sep 09, 2015 at 02:56:16PM +0100, Tvrtko Ursulin wrote:
Hi,
On 08/10/2015 09:51 AM, Chris Wilson wrote:
+out:
drm_free_large(pvec);
return ret;
+
+err:
+ /* No pages here, no need for the mmu-notifier to wake us */
+
On Wed, Sep 09, 2015 at 02:56:16PM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 08/10/2015 09:51 AM, Chris Wilson wrote:
> > +out:
> > drm_free_large(pvec);
> > return ret;
> > +
> > +err:
> > + /* No pages here, no need for the mmu-notifier to wake us */
> > + __i915_gem_userptr_set_a
Hi,
On 08/10/2015 09:51 AM, Chris Wilson wrote:
> Michał Winiarski found a really evil way to trigger a struct_mutex
> deadlock with userptr. He found that if he allocated a userptr bo and
> then GTT mmaped another bo, or even itself, at the same address as the
> userptr using MAP_FIXED, he could
Michał Winiarski found a really evil way to trigger a struct_mutex
deadlock with userptr. He found that if he allocated a userptr bo and
then GTT mmaped another bo, or even itself, at the same address as the
userptr using MAP_FIXED, he could then cause a deadlock any time we then
had to invalidate
