On Thu, Nov 28, 2019 at 11:09:46AM +0200, Jani Nikula wrote:

quoted

On Wed, 27 Nov 2019, Daniel Vetter [off-list ref] wrote:

quoted

On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:

quoted

On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:

quoted

Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
and then resetting it to NULL afterwards causes problems all over the
place. First, it prevents making the fbops member of struct fb_info a
const pointer, which means we can't make struct fb_ops const
anywhere. Second, a few places have to go out of their way to restore
the original fb_mmap pointer that gets reset to NULL.

Preserve the passed in fb_ops by making a copy of it and modifying that
instead. Add a deferred_io_private member to struct fb_info to store the
pointer to the old fb_ops, and restore that at cleanup.

Cc: Jaya Kumar <jayalk@intworks.biz>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Jani Nikula <redacted>

---

Note: If the approach is acceptable, we'll also need to handle the error
returns on memory allocation failures at fb_deferred_io_init() call
sites. There are 13.

it's fbdev defio, I think we can do worse with less effort. Just embed a
copy of fb_ops into fb_info, and use that, and tada! no memory allocation
needed :-)

I'd totally r-b that patch.

Or do what Ville suggested, add an fb_info->fbdefio.enabled, set that in
the _init function and in fb_mmap call fb_deferred_io_mmap for that case
instead of the driver's fb_ops->fb_mmap. There's only one caller of that
in the entire tree, in fbmem.c. Also, we could/should nuke the
EXPORT_SYMBOL(fb_deferred_io_mmap) I think.

I just realized that fb_info->fbdefio is a pointer, so this would be
really simple to pull off I think.

Heh, having a

	int (*fb_deferred_io_mmap)(struct fb_info *, struct vm_area_struct *);

member in struct fb_info, and using that in fbmem.c if non-NULL, was
actually my first idea. I didn't think it was particularly pretty, but
if we don't care about aesthetics...

Would you like that instead of the patch at hand?

diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index 82c20c6047b0..9275c6bd71da 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c

@@ -206,13 +206,11 @@ void fb_deferred_io_init(struct fb_info *info)
 
 	BUG_ON(!fbdefio);
 	mutex_init(&fbdefio->lock);
-	info->fbops->fb_mmap = fb_deferred_io_mmap;
 	INIT_DELAYED_WORK(&info->deferred_work, fb_deferred_io_work);
 	INIT_LIST_HEAD(&fbdefio->pagelist);
 	if (fbdefio->delay = 0) /* set a default of 1 s */
 		fbdefio->delay = HZ;
 }
-EXPORT_SYMBOL_GPL(fb_deferred_io_init);
 
 void fb_deferred_io_open(struct fb_info *info,
 			 struct inode *inode,

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 86b06a599f96..6af627f281c3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c

@@ -1341,7 +1341,16 @@ fb_mmap(struct file *file, struct vm_area_struct * vma)
 		return -ENODEV;
 	fb = info->fbops;
 	mutex_lock(&info->mm_lock);
-	if (fb->fb_mmap) {
+	if (fb->fbdefio) {
+		/*
+		 * The framebuffer needs to be accessed decrypted, be sure
+		 * SME protection is removed ahead of the call
+		 */
+		vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+		res = fb_deferred_io_mmap(info, vma);
+		mutex_unlock(&info->mm_lock);
+		return res;
+	} else if (fb->fb_mmap) {
 		int res;
 
 		/*

Is what I was thinking off as the pretty solution. Add an explicit
fb_info->fbdefio_enabled boolean if you don't feel like auditing all the
drivers for whether they really call defio_init() every time they assign
something to that pointer. A quick scan brought some nasties to light in
that area.