From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tvrtko Ursulin Subject: Re: [PATCH 2/2] drm/i915: Serialise userptr gup with mmu-notifier Date: Thu, 10 Jul 2014 13:30:20 +0100 Message-ID: <53BE875C.2070202@linux.intel.com> References: <1404984104-27169-1-git-send-email-chris@chris-wilson.co.uk> <1404984104-27169-2-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 2431F6E075 for ; Thu, 10 Jul 2014 05:30:32 -0700 (PDT) In-Reply-To: <1404984104-27169-2-git-send-email-chris@chris-wilson.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Chris Wilson , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On 07/10/2014 10:21 AM, Chris Wilson wrote: > Jerome Glisse pointed out that get_user_pages() does not synchronize > with concurrent invalidations of the VMA. As such if the backing vma is > changed whilst the pages for the object are being grabbed for use by the > GPU, we may end up with a random mixture of page references being held. > Worse still as the mmu-notifier will believe that the VMA invalidation > was complete and the old page references dropped. > > In order to serialise gup with mmu-notifier, we use a seqlock to detect > when an invalidation has occurred in parallel to our gup and if so cancel > the gup. The detection is a little coarse, but hopefully we never see > contention here! Looks good to me, but as we discussed on IRC all get_user_pages users have this "problem" and I don't understand why it matters to us? How would someone hit/exploit the race? By one thread manically modifying mappings while another is creating userptr objects? Is there some other legitimate way of it happening? Tvrtko