Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp6014082ybc; Wed, 27 Nov 2019 13:24:40 -0800 (PST) X-Google-Smtp-Source: APXvYqwJJutcMt+lGrpucQXZLGfVFlYazM7CDxzQHnWNWYRh7+D7Ehht/M2OXgx0kcqmOd8snV/x X-Received: by 2002:aa7:c74e:: with SMTP id c14mr35070197eds.260.1574889880593; Wed, 27 Nov 2019 13:24:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574889880; cv=none; d=google.com; s=arc-20160816; b=R+gIfct1DVevrBTwxiRu1qZ9w54wRIKB9kFjTw/iV4qhwDDngID3dWVV9QElHG5XHa 68zlW4+rKuUt24D9gOD6VPZy7TIAEljIMzrEGy4+pMhSn5kYSNjSlsgG6uMS15D7FMbq gIwpFF1om4MFIYEXTOssIUYOVv3YGlKepNcpCjt0K/HEVTKk7w6Wvg1J/pvZvy+ciO/G V152JlSfDHMZIeGHpPzW5rTzHo4uF7T9ApKuKgLdKGxmt/w60ZDlHnlXYt9JefG2/ADI iBPAZs7MLr7+LurDayUrbHJ+afSIWQw6CpAPs5LQEzThh6exQuqqJxG0stitJ2KDTkEU Rv6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=EVwAWkBz7YwD7WEkwuJ8x/Z8d14if3UlGrlvEwiWFPY=; b=f/Y+/JeCNTRvch69eHvRGYhcaDz7RLk8oI6qN75a3n004kgsJ4Uk4i5encEENG4gCt Q40EPMaZ+EFDl8LnlNIy46364p9SrBY+demhVncy74yQ5bFKbvszbLbFkCab4MehY/qc K0YDY8rDk2vtECp1z5Zn4rYzn2MuBJ8hBce515b01EUjOPg36mP6aeQTFwYjtzp/b4aT syzT+Vey6MlceJMNcOje76YxEIKR0XJMubIb+e+hzZPxxjGd9AGD3hyc0mUY5jdQW65O ttTi1bdPo3av0RZzTF0VTyWEvsL9mcEMRrNiqhV4lCS+d6dwGL901N67BDZXLCHa8Val tcTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=yLh5Y6VS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z10si10335809ejr.262.2019.11.27.13.24.17; Wed, 27 Nov 2019 13:24:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=yLh5Y6VS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732915AbfK0VJl (ORCPT + 99 others); Wed, 27 Nov 2019 16:09:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:36434 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732898AbfK0VJj (ORCPT ); Wed, 27 Nov 2019 16:09:39 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 285EF21555; Wed, 27 Nov 2019 21:09:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574888978; bh=2qfpcX+cD/9Z47Vc3pIFUjPlA9Rmg+HXjRPO1wwbwXM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yLh5Y6VSv0V/4s3pcLfSsap+Go8/NEeYQ1eO5Wzn/4QVxn6xVcFfKrvRssKI+Ux7B X4OlZlKkFKnjqhkvVsNtNTQkbsN9g+nX8673NySvH1j/PkGoDGfbOK53ePTiK3nS+r DV6+nDkM/tSNRg598eASWOUee4kRH3FlzyqoaIVA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chris Wilson , Lionel Landwerlin , Tvrtko Ursulin , Joonas Lahtinen , Rodrigo Vivi Subject: [PATCH 5.3 35/95] drm/i915/userptr: Try to acquire the page lock around set_page_dirty() Date: Wed, 27 Nov 2019 21:31:52 +0100 Message-Id: <20191127202859.627144881@linuxfoundation.org> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191127202845.651587549@linuxfoundation.org> References: <20191127202845.651587549@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chris Wilson commit 2d691aeca4aecbb8d0414a777a46981a8e142b05 upstream. set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). However, following a try_to_unmap() we may want to remove the userptr and so call put_pages(). However, try_to_unmap() acquires the page lock and so we must avoid recursively locking the pages ourselves -- which means that we cannot safely acquire the lock around set_page_dirty(). Since we can't be sure of the lock, we have to risk skip dirtying the page, or else risk calling set_page_dirty() without a lock and so risk fs corruption. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012 Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Signed-off-by: Chris Wilson Cc: Lionel Landwerlin Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-1-chris@chris-wilson.co.uk (cherry picked from commit 0d4bbe3d407f79438dc4f87943db21f7134cfc65) Signed-off-by: Joonas Lahtinen (cherry picked from commit cee7fb437edcdb2f9f8affa959e274997f5dca4d) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -663,8 +663,28 @@ i915_gem_userptr_put_pages(struct drm_i9 i915_gem_gtt_finish_pages(obj, pages); for_each_sgt_page(page, sgt_iter, pages) { - if (obj->mm.dirty) + if (obj->mm.dirty && trylock_page(page)) { + /* + * As this may not be anonymous memory (e.g. shmem) + * but exist on a real mapping, we have to lock + * the page in order to dirty it -- holding + * the page reference is not sufficient to + * prevent the inode from being truncated. + * Play safe and take the lock. + * + * However...! + * + * The mmu-notifier can be invalidated for a + * migrate_page, that is alreadying holding the lock + * on the page. Such a try_to_unmap() will result + * in us calling put_pages() and so recursively try + * to lock the page. We avoid that deadlock with + * a trylock_page() and in exchange we risk missing + * some page dirtying. + */ set_page_dirty(page); + unlock_page(page); + } mark_page_accessed(page); put_page(page);