Skip to contentSkip to conversation

FAILED: patch "[PATCH] drm/i915/userptr: Acquire the page lock around" failed to apply to 4.19-stable tree

PATCH [email protected] 2 participants 2 messages Oct 8, 2019 – Oct 9, 2019

Subsystems (3)
Stable branch DRM drivers Intel i915
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From cb6d7c7dc7ff8cace666ddec66334117a6068ce2 Mon Sep 17 00:00:00 2001
From: Chris Wilson <[email protected]>
Date: Mon, 8 Jul 2019 15:03:27 +0100
Subject: [PATCH] drm/i915/userptr: Acquire the page lock around
set_page_dirty()

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).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317

Fixes 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")

References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")

Signed-off-by Chris Wilson <[email protected]>
Cc Tvrtko Ursulin <[email protected]>
Cc [email protected]
Reviewed-by Tvrtko Ursulin <[email protected]>
Link https://patchwork.freedesktop.org/patch/msgid/[email protected]
drivers/gpu/drm/i915/gem/i915_gem_userptr.c +9 -1
index 16ccec7fb7da..32d208ede343 100644
@@ -665,7 +665,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
 
 	for_each_sgt_page(page, sgt_iter, pages) {
 		if (obj->mm.dirty)
-			set_page_dirty(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.
+			 */
+			set_page_dirty_lock(page);
 
 		mark_page_accessed(page);
 		put_page(page);
maintainer
#1 lore raw
Quoted 29 lines · On Tue, Oct 08, 2019 at 07:25:04PM +0200, [email protected] wrote:

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From cb6d7c7dc7ff8cace666ddec66334117a6068ce2 Mon Sep 17 00:00:00 2001
From: Chris Wilson <[email protected]>
Date: Mon, 8 Jul 2019 15:03:27 +0100
Subject: [PATCH] drm/i915/userptr: Acquire the page lock around set_page_dirty()

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).

Quoted 8 lines

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317

Fixes 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")

References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")

Signed-off-by Chris Wilson <[email protected]>
Cc Tvrtko Ursulin <[email protected]>
Cc [email protected]
Reviewed-by Tvrtko Ursulin <[email protected]>
Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

File got moved around. I've fixed it up and queued for 4.19-4.4.

Signature · 2 lines
Thanks,
Sasha