[PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

This was only added for the drm's fbdev emulation support, so that it
would try harder to show the Oops.

Unfortunately this never really worked reliably, and in practice ended
up pushing the real Oops off the screen due to plentyfull locking,
sleep-while-atomic and other issues. So we removed all that support
from the fbdev emulation a while back. Aside: We've also removed the
kgdb support, for similar reasons.

Since it's such a small patch I figured I don't split this up into the
usual 3-phase removal.

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: David Lechner <david@lechnology.com>
Cc: nouveau@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 -
 drivers/staging/vboxvideo/vbox_fb.c     | 3 +--
 drivers/video/fbdev/core/fbcon.c        | 1 -
 include/linux/fb.h                      | 4 ----
 4 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 844498c4267c..20a260887be3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -379,7 +379,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
 		info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
 			      FBINFO_HWACCEL_FILLRECT |
 			      FBINFO_HWACCEL_IMAGEBLIT;
-	info->flags |= FBINFO_CAN_FORCE_OUTPUT;
 	info->fbops = &nouveau_fbcon_sw_ops;
 	info->fix.smem_start = fb->nvbo->bo.mem.bus.base +
 			       fb->nvbo->bo.mem.bus.offset;
diff --git a/drivers/staging/vboxvideo/vbox_fb.c b/drivers/staging/vboxvideo/vbox_fb.c
index 43c39eca4ae1..034f8ffa8f20 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -155,8 +155,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
 	 * The last flag forces a mode set on VT switches even if the kernel
 	 * does not think it is needed.
 	 */
-	info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT |
-		      FBINFO_MISC_ALWAYS_SETPAR;
+	info->flags = FBINFO_DEFAULT | FBINFO_MISC_ALWAYS_SETPAR;
 	info->fbops = &vboxfb_ops;
 
 	/*
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5fb156bdcf4e..2b5bb52b1798 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1104,7 +1104,6 @@ static void fbcon_init(struct vc_data *vc, int init)
 	if (p->userfont)
 		charcnt = FNTCHARCNT(p->fontdata);
 
-	vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT);
 	vc->vc_can_do_color = (fb_get_color_depth(&info->var, &info->fix)!=1);
 	vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
 	if (charcnt == 256) {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index aa74a228bb92..fa8c6f9c9c3a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -457,10 +457,6 @@ struct fb_tile_ops {
  */
 #define FBINFO_BE_MATH  0x100000
 
-/* report to the VT layer that this fb driver can accept forced console
-   output like oopses */
-#define FBINFO_CAN_FORCE_OUTPUT     0x200000
-
 struct fb_info {
 	atomic_t count;
 	int node;
-- 
2.18.0

[PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

This was only added for the drm's fbdev emulation support, so that it
would try harder to show the Oops.

Unfortunately this never really worked reliably, and in practice ended
up pushing the real Oops off the screen due to plentyfull locking,
sleep-while-atomic and other issues. So we removed all that support
from the fbdev emulation a while back. Aside: We've also removed the
kgdb support, for similar reasons.

Since it's such a small patch I figured I don't split this up into the
usual 3-phase removal.

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: David Lechner <david@lechnology.com>
Cc: nouveau@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 -
 drivers/staging/vboxvideo/vbox_fb.c     | 3 +--
 drivers/video/fbdev/core/fbcon.c        | 1 -
 include/linux/fb.h                      | 4 ----
 4 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 844498c4267c..20a260887be3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -379,7 +379,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
 		info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
 			      FBINFO_HWACCEL_FILLRECT |
 			      FBINFO_HWACCEL_IMAGEBLIT;
-	info->flags |= FBINFO_CAN_FORCE_OUTPUT;
 	info->fbops = &nouveau_fbcon_sw_ops;
 	info->fix.smem_start = fb->nvbo->bo.mem.bus.base +
 			       fb->nvbo->bo.mem.bus.offset;
diff --git a/drivers/staging/vboxvideo/vbox_fb.c b/drivers/staging/vboxvideo/vbox_fb.c
index 43c39eca4ae1..034f8ffa8f20 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -155,8 +155,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
 	 * The last flag forces a mode set on VT switches even if the kernel
 	 * does not think it is needed.
 	 */
-	info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT |
-		      FBINFO_MISC_ALWAYS_SETPAR;
+	info->flags = FBINFO_DEFAULT | FBINFO_MISC_ALWAYS_SETPAR;
 	info->fbops = &vboxfb_ops;
 
 	/*
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5fb156bdcf4e..2b5bb52b1798 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1104,7 +1104,6 @@ static void fbcon_init(struct vc_data *vc, int init)
 	if (p->userfont)
 		charcnt = FNTCHARCNT(p->fontdata);
 
-	vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT);
 	vc->vc_can_do_color = (fb_get_color_depth(&info->var, &info->fix)!=1);
 	vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
 	if (charcnt = 256) {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index aa74a228bb92..fa8c6f9c9c3a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -457,10 +457,6 @@ struct fb_tile_ops {
  */
 #define FBINFO_BE_MATH  0x100000
 
-/* report to the VT layer that this fb driver can accept forced console
-   output like oopses */
-#define FBINFO_CAN_FORCE_OUTPUT     0x200000
-
 struct fb_info {
 	atomic_t count;
 	int node;
-- 
2.18.0

[PATCH 2/4] vt: Remove vc_panic_force_write

[Daniel Vetter]

It was only used by the panic support in fbcon, which is now gone.
Remove this now dead code too.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Meng Xu <mengxu.gatech@gmail.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: Mike Frysinger <vapier@chromium.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: David Lechner <david@lechnology.com>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/tty/vt/vt.c              | 12 ++++--------
 drivers/video/fbdev/core/fbcon.c |  3 +--
 include/linux/console_struct.h   |  1 -
 include/linux/vt_kern.h          |  7 -------
 4 files changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 15eb6c829d39..6d41b14e4fc7 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -700,9 +700,7 @@ void redraw_screen(struct vc_data *vc, int is_switch)
 			clear_buffer_attributes(vc);
 		}
 
-		/* Forcibly update if we're panicing */
-		if ((update && vc->vc_mode != KD_GRAPHICS) ||
-		    vt_force_oops_output(vc))
+		if (update && vc->vc_mode != KD_GRAPHICS)
 			do_update_region(vc, vc->vc_origin, vc->vc_screenbuf_size / 2);
 	}
 	set_cursor(vc);
@@ -742,7 +740,6 @@ static void visual_init(struct vc_data *vc, int num, int init)
 	vc->vc_hi_font_mask = 0;
 	vc->vc_complement_mask = 0;
 	vc->vc_can_do_color = 0;
-	vc->vc_panic_force_write = false;
 	vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS;
 	vc->vc_sw->con_init(vc, init);
 	if (!vc->vc_complement_mask)
@@ -2576,7 +2573,7 @@ static void vt_console_print(struct console *co, const char *b, unsigned count)
 		goto quit;
 	}
 
-	if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
+	if (vc->vc_mode != KD_TEXT)
 		goto quit;
 
 	/* undraw cursor first */
@@ -3894,8 +3891,7 @@ void do_unblank_screen(int leaving_gfx)
 		return;
 	}
 	vc = vc_cons[fg_console].d;
-	/* Try to unblank in oops case too */
-	if (vc->vc_mode != KD_TEXT && !vt_force_oops_output(vc))
+	if (vc->vc_mode != KD_TEXT)
 		return; /* but leave console_blanked != 0 */
 
 	if (blankinterval) {
@@ -3904,7 +3900,7 @@ void do_unblank_screen(int leaving_gfx)
 	}
 
 	console_blanked = 0;
-	if (vc->vc_sw->con_blank(vc, 0, leaving_gfx) || vt_force_oops_output(vc))
+	if (vc->vc_sw->con_blank(vc, 0, leaving_gfx))
 		/* Low-level driver cannot restore -> do it ourselves */
 		update_screen(vc);
 	if (console_blank_hook)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2b5bb52b1798..4541bc17573e 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -284,8 +284,7 @@ static inline int fbcon_is_inactive(struct vc_data *vc, struct fb_info *info)
 	struct fbcon_ops *ops = info->fbcon_par;
 
 	return (info->state != FBINFO_STATE_RUNNING ||
-		vc->vc_mode != KD_TEXT || ops->graphics) &&
-		!vt_force_oops_output(vc);
+		vc->vc_mode != KD_TEXT || ops->graphics);
 }
 
 static int get_color(struct vc_data *vc, struct fb_info *info,
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index c0ec478ea5bf..c96e7f5f7c77 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -140,7 +140,6 @@ struct vc_data {
 	struct vc_data **vc_display_fg;		/* [!] Ptr to var holding fg console for this display */
 	struct uni_pagedir *vc_uni_pagedir;
 	struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
-	bool vc_panic_force_write; /* when oops/panic this VC can accept forced output/blanking */
 	/* additional information is in vt_kern.h */
 };
 
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 3fd07912909c..8dc77e40bc03 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -135,13 +135,6 @@ extern int do_unbind_con_driver(const struct consw *csw, int first, int last,
 			     int deflt);
 int vty_init(const struct file_operations *console_fops);
 
-static inline bool vt_force_oops_output(struct vc_data *vc)
-{
-	if (oops_in_progress && vc->vc_panic_force_write  && panic_timeout >= 0)
-		return true;
-	return false;
-}
-
 extern char vt_dont_switch;
 extern int default_utf8;
 extern int global_cursor_default;
-- 
2.18.0

Re: [PATCH 2/4] vt: Remove vc_panic_force_write

[Greg Kroah-Hartman]

On Wed, Aug 22, 2018 at 10:54:03AM +0200, Daniel Vetter wrote:
> It was only used by the panic support in fbcon, which is now gone.
> Remove this now dead code too.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Joe Perches <joe@perches.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Meng Xu <mengxu.gatech@gmail.com>
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Thomas Meyer <thomas@m3y3r.de>
> Cc: Mike Frysinger <vapier@chromium.org>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: David Lechner <david@lechnology.com>
> Cc: Philippe Ombredanne <pombredanne@nexb.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kate Stewart <kstewart@linuxfoundation.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 2/4] vt: Remove vc_panic_force_write

[Greg Kroah-Hartman]

On Wed, Aug 22, 2018 at 10:54:03AM +0200, Daniel Vetter wrote:
> It was only used by the panic support in fbcon, which is now gone.
> Remove this now dead code too.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Joe Perches <joe@perches.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Meng Xu <mengxu.gatech@gmail.com>
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Thomas Meyer <thomas@m3y3r.de>
> Cc: Mike Frysinger <vapier@chromium.org>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: David Lechner <david@lechnology.com>
> Cc: Philippe Ombredanne <pombredanne@nexb.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kate Stewart <kstewart@linuxfoundation.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] vt: Remove vc_panic_force_write

[Daniel Vetter]

On Wed, Aug 22, 2018 at 10:59:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 22, 2018 at 10:54:03AM +0200, Daniel Vetter wrote:
> > It was only used by the panic support in fbcon, which is now gone.
> > Remove this now dead code too.
> > 
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Joe Perches <joe@perches.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Meng Xu <mengxu.gatech@gmail.com>
> > Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> > Cc: Thomas Meyer <thomas@m3y3r.de>
> > Cc: Mike Frysinger <vapier@chromium.org>
> > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > Cc: Hans de Goede <hdegoede@redhat.com>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Cc: David Lechner <david@lechnology.com>
> > Cc: Philippe Ombredanne <pombredanne@nexb.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Kate Stewart <kstewart@linuxfoundation.org>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> 
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Queued for 4.20/5.0 in drm-misc-next together with the other patches in
this series.
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Daniel Vetter]

DRM drivers really, really, really don't want random userspace to
share buffer behind it's back, bypassing the dma-buf buffer sharing
machanism. For that reason we've ruthlessly rejected any IOCTL
exposing the physical address of any graphics buffer.

Unfortunately fbdev comes with that built-in. We could just set
smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
implementation. For good reasons many drivers do that, but
smem_start/length is still super convenient.

Hence instead just stop the leak in the ioctl, to keep fb mmap working
as-is. A second patch will set this flag for all drm drivers.

Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/video/fbdev/core/fbmem.c | 4 ++++
 include/linux/fb.h               | 7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 609438d2465b..549d0f86fcf3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
 		if (!lock_fb_info(info))
 			return -ENODEV;
 		fix = info->fix;
+		if (info->flags & FBINFO_HIDE_SMEM_START)
+			fix.smem_start = 0;
 		unlock_fb_info(info);
 
 		ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
@@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
 	if (!lock_fb_info(info))
 		return -ENODEV;
 	fix = info->fix;
+	if (info->flags & FBINFO_HIDE_SMEM_START)
+		fix.smem_start = 0;
 	unlock_fb_info(info);
 	return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
 }
diff --git a/include/linux/fb.h b/include/linux/fb.h
index fa8c6f9c9c3a..f42b09ca71f8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -456,6 +456,13 @@ struct fb_tile_ops {
  * and host endianness. Drivers should not use this flag.
  */
 #define FBINFO_BE_MATH  0x100000
+/*
+ * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern DRM
+ * drivers to stop userspace from trying to share buffers behind the kernel's
+ * back. Instead dma-buf based buffer sharing should be used.
+ */
+#define FBINFO_HIDE_SMEM_START  0x200000
+
 
 struct fb_info {
 	atomic_t count;
-- 
2.18.0

[PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Daniel Vetter]

DRM drivers really, really, really don't want random userspace to
share buffer behind it's back, bypassing the dma-buf buffer sharing
machanism. For that reason we've ruthlessly rejected any IOCTL
exposing the physical address of any graphics buffer.

Unfortunately fbdev comes with that built-in. We could just set
smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
implementation. For good reasons many drivers do that, but
smem_start/length is still super convenient.

Hence instead just stop the leak in the ioctl, to keep fb mmap working
as-is. A second patch will set this flag for all drm drivers.

Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/video/fbdev/core/fbmem.c | 4 ++++
 include/linux/fb.h               | 7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 609438d2465b..549d0f86fcf3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
 		if (!lock_fb_info(info))
 			return -ENODEV;
 		fix = info->fix;
+		if (info->flags & FBINFO_HIDE_SMEM_START)
+			fix.smem_start = 0;
 		unlock_fb_info(info);
 
 		ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
@@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
 	if (!lock_fb_info(info))
 		return -ENODEV;
 	fix = info->fix;
+	if (info->flags & FBINFO_HIDE_SMEM_START)
+		fix.smem_start = 0;
 	unlock_fb_info(info);
 	return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
 }
diff --git a/include/linux/fb.h b/include/linux/fb.h
index fa8c6f9c9c3a..f42b09ca71f8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -456,6 +456,13 @@ struct fb_tile_ops {
  * and host endianness. Drivers should not use this flag.
  */
 #define FBINFO_BE_MATH  0x100000
+/*
+ * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern DRM
+ * drivers to stop userspace from trying to share buffers behind the kernel's
+ * back. Instead dma-buf based buffer sharing should be used.
+ */
+#define FBINFO_HIDE_SMEM_START  0x200000
+
 
 struct fb_info {
 	atomic_t count;
-- 
2.18.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Daniel Vetter]

DRM drivers really, really, really don't want random userspace to
share buffer behind it's back, bypassing the dma-buf buffer sharing
machanism. For that reason we've ruthlessly rejected any IOCTL
exposing the physical address of any graphics buffer.

Unfortunately fbdev comes with that built-in. We could just set
smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
implementation. For good reasons many drivers do that, but
smem_start/length is still super convenient.

Hence instead just stop the leak in the ioctl, to keep fb mmap working
as-is. A second patch will set this flag for all drm drivers.

Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/video/fbdev/core/fbmem.c | 4 ++++
 include/linux/fb.h               | 7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 609438d2465b..549d0f86fcf3 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
 		if (!lock_fb_info(info))
 			return -ENODEV;
 		fix = info->fix;
+		if (info->flags & FBINFO_HIDE_SMEM_START)
+			fix.smem_start = 0;
 		unlock_fb_info(info);
 
 		ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
@@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
 	if (!lock_fb_info(info))
 		return -ENODEV;
 	fix = info->fix;
+	if (info->flags & FBINFO_HIDE_SMEM_START)
+		fix.smem_start = 0;
 	unlock_fb_info(info);
 	return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
 }
diff --git a/include/linux/fb.h b/include/linux/fb.h
index fa8c6f9c9c3a..f42b09ca71f8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -456,6 +456,13 @@ struct fb_tile_ops {
  * and host endianness. Drivers should not use this flag.
  */
 #define FBINFO_BE_MATH  0x100000
+/*
+ * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern DRM
+ * drivers to stop userspace from trying to share buffers behind the kernel's
+ * back. Instead dma-buf based buffer sharing should be used.
+ */
+#define FBINFO_HIDE_SMEM_START  0x200000
+
 
 struct fb_info {
 	atomic_t count;
-- 
2.18.0

Re: [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Daniel Vetter]

On Wed, Aug 22, 2018 at 10:54:04AM +0200, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address of any graphics buffer.
> 
> Unfortunately fbdev comes with that built-in. We could just set
> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
> implementation. For good reasons many drivers do that, but
> smem_start/length is still super convenient.
> 
> Hence instead just stop the leak in the ioctl, to keep fb mmap working
> as-is. A second patch will set this flag for all drm drivers.
> 
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Any comments from the fbdev side on this?
-Daniel

> ---
>  drivers/video/fbdev/core/fbmem.c | 4 ++++
>  include/linux/fb.h               | 7 +++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 609438d2465b..549d0f86fcf3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>  		if (!lock_fb_info(info))
>  			return -ENODEV;
>  		fix = info->fix;
> +		if (info->flags & FBINFO_HIDE_SMEM_START)
> +			fix.smem_start = 0;
>  		unlock_fb_info(info);
>  
>  		ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
> @@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
>  	if (!lock_fb_info(info))
>  		return -ENODEV;
>  	fix = info->fix;
> +	if (info->flags & FBINFO_HIDE_SMEM_START)
> +		fix.smem_start = 0;
>  	unlock_fb_info(info);
>  	return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
>  }
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index fa8c6f9c9c3a..f42b09ca71f8 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -456,6 +456,13 @@ struct fb_tile_ops {
>   * and host endianness. Drivers should not use this flag.
>   */
>  #define FBINFO_BE_MATH  0x100000
> +/*
> + * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern DRM
> + * drivers to stop userspace from trying to share buffers behind the kernel's
> + * back. Instead dma-buf based buffer sharing should be used.
> + */
> +#define FBINFO_HIDE_SMEM_START  0x200000
> +
>  
>  struct fb_info {
>  	atomic_t count;
> -- 
> 2.18.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Daniel Vetter]

On Wed, Aug 22, 2018 at 10:54:04AM +0200, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address of any graphics buffer.
> 
> Unfortunately fbdev comes with that built-in. We could just set
> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
> implementation. For good reasons many drivers do that, but
> smem_start/length is still super convenient.
> 
> Hence instead just stop the leak in the ioctl, to keep fb mmap working
> as-is. A second patch will set this flag for all drm drivers.
> 
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Any comments from the fbdev side on this?
-Daniel

> ---
>  drivers/video/fbdev/core/fbmem.c | 4 ++++
>  include/linux/fb.h               | 7 +++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 609438d2465b..549d0f86fcf3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>  		if (!lock_fb_info(info))
>  			return -ENODEV;
>  		fix = info->fix;
> +		if (info->flags & FBINFO_HIDE_SMEM_START)
> +			fix.smem_start = 0;
>  		unlock_fb_info(info);
>  
>  		ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
> @@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
>  	if (!lock_fb_info(info))
>  		return -ENODEV;
>  	fix = info->fix;
> +	if (info->flags & FBINFO_HIDE_SMEM_START)
> +		fix.smem_start = 0;
>  	unlock_fb_info(info);
>  	return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
>  }
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index fa8c6f9c9c3a..f42b09ca71f8 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -456,6 +456,13 @@ struct fb_tile_ops {
>   * and host endianness. Drivers should not use this flag.
>   */
>  #define FBINFO_BE_MATH  0x100000
> +/*
> + * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern DRM
> + * drivers to stop userspace from trying to share buffers behind the kernel's
> + * back. Instead dma-buf based buffer sharing should be used.
> + */
> +#define FBINFO_HIDE_SMEM_START  0x200000
> +
>  
>  struct fb_info {
>  	atomic_t count;
> -- 
> 2.18.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Daniel Vetter]

On Wed, Aug 22, 2018 at 10:54:04AM +0200, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address of any graphics buffer.
> 
> Unfortunately fbdev comes with that built-in. We could just set
> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
> implementation. For good reasons many drivers do that, but
> smem_start/length is still super convenient.
> 
> Hence instead just stop the leak in the ioctl, to keep fb mmap working
> as-is. A second patch will set this flag for all drm drivers.
> 
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Any comments from the fbdev side on this?
-Daniel

> ---
>  drivers/video/fbdev/core/fbmem.c | 4 ++++
>  include/linux/fb.h               | 7 +++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 609438d2465b..549d0f86fcf3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>  		if (!lock_fb_info(info))
>  			return -ENODEV;
>  		fix = info->fix;
> +		if (info->flags & FBINFO_HIDE_SMEM_START)
> +			fix.smem_start = 0;
>  		unlock_fb_info(info);
>  
>  		ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0;
> @@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd,
>  	if (!lock_fb_info(info))
>  		return -ENODEV;
>  	fix = info->fix;
> +	if (info->flags & FBINFO_HIDE_SMEM_START)
> +		fix.smem_start = 0;
>  	unlock_fb_info(info);
>  	return do_fscreeninfo_to_user(&fix, compat_ptr(arg));
>  }
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index fa8c6f9c9c3a..f42b09ca71f8 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -456,6 +456,13 @@ struct fb_tile_ops {
>   * and host endianness. Drivers should not use this flag.
>   */
>  #define FBINFO_BE_MATH  0x100000
> +/*
> + * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern DRM
> + * drivers to stop userspace from trying to share buffers behind the kernel's
> + * back. Instead dma-buf based buffer sharing should be used.
> + */
> +#define FBINFO_HIDE_SMEM_START  0x200000
> +
>  
>  struct fb_info {
>  	atomic_t count;
> -- 
> 2.18.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Bartlomiej Zolnierkiewicz]

On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address of any graphics buffer.
> 
> Unfortunately fbdev comes with that built-in. We could just set
> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
> implementation. For good reasons many drivers do that, but
> smem_start/length is still super convenient.
> 
> Hence instead just stop the leak in the ioctl, to keep fb mmap working
> as-is. A second patch will set this flag for all drm drivers.
> 
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag

[Bartlomiej Zolnierkiewicz]

On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address of any graphics buffer.
> 
> Unfortunately fbdev comes with that built-in. We could just set
> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
> implementation. For good reasons many drivers do that, but
> smem_start/length is still super convenient.
> 
> Hence instead just stop the leak in the ioctl, to keep fb mmap working
> as-is. A second patch will set this flag for all drm drivers.
> 
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

[PATCH 4/4] drm/fb: Stop leaking physical address

[Daniel Vetter]

For buffer sharing, use dma-buf instead. We can't set smem_start to 0
unconditionally since that's used by the fbdev mmap default
implementation. And we have plenty of userspace which would like to
keep that working.

This might break legit userspace - if it does we need to look at a
case-by-cases basis how to handle that. Worst case I expect overrides
for only specific drivers, since anything remotely modern should be
using dma-buf/prime now (which is about 7 years old now for DRM
drivers).

This issue was uncovered because Noralf's rework to implement a
generic fb_probe also implements it's own fb_mmap callback. Which
means smem_start didn't have to be set anymore, which blew up some
blob in userspace rather badly.

Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_fb_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4b0dd20bccb8..bcb78693c4f7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2673,6 +2673,8 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper,
 
 	info = fb_helper->fbdev;
 	info->var.pixclock = 0;
+	/* don't leak any physical addresses to userspace */
+	info->flags |= FBINFO_HIDE_SMEM_START;
 
 	/* Need to drop locks to avoid recursive deadlock in
 	 * register_framebuffer. This is ok because the only thing left to do is
-- 
2.18.0

Re: [PATCH 4/4] drm/fb: Stop leaking physical address

[Sean Paul]

On Wed, Aug 22, 2018 at 10:54:05AM +0200, Daniel Vetter wrote:
> For buffer sharing, use dma-buf instead. We can't set smem_start to 0
> unconditionally since that's used by the fbdev mmap default
> implementation. And we have plenty of userspace which would like to
> keep that working.
> 
> This might break legit userspace - if it does we need to look at a
> case-by-cases basis how to handle that. Worst case I expect overrides
> for only specific drivers, since anything remotely modern should be
> using dma-buf/prime now (which is about 7 years old now for DRM
> drivers).
> 
> This issue was uncovered because Noralf's rework to implement a
> generic fb_probe also implements it's own fb_mmap callback. Which
> means smem_start didn't have to be set anymore, which blew up some
> blob in userspace rather badly.
> 
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: David Airlie <airlied@linux.ie>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

After clarifying on IRC, I think this makes sense. The chance to break userspace
requires a very specific configuration that I don't expect will be common.

Acked-by: Sean Paul <seanpaul@chromium.org>

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 4b0dd20bccb8..bcb78693c4f7 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2673,6 +2673,8 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper,
>  
>  	info = fb_helper->fbdev;
>  	info->var.pixclock = 0;
> +	/* don't leak any physical addresses to userspace */
> +	info->flags |= FBINFO_HIDE_SMEM_START;
>  
>  	/* Need to drop locks to avoid recursive deadlock in
>  	 * register_framebuffer. This is ok because the only thing left to do is
> -- 
> 2.18.0
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [PATCH 4/4] drm/fb: Stop leaking physical address

[Sean Paul]

On Wed, Aug 22, 2018 at 10:54:05AM +0200, Daniel Vetter wrote:
> For buffer sharing, use dma-buf instead. We can't set smem_start to 0
> unconditionally since that's used by the fbdev mmap default
> implementation. And we have plenty of userspace which would like to
> keep that working.
> 
> This might break legit userspace - if it does we need to look at a
> case-by-cases basis how to handle that. Worst case I expect overrides
> for only specific drivers, since anything remotely modern should be
> using dma-buf/prime now (which is about 7 years old now for DRM
> drivers).
> 
> This issue was uncovered because Noralf's rework to implement a
> generic fb_probe also implements it's own fb_mmap callback. Which
> means smem_start didn't have to be set anymore, which blew up some
> blob in userspace rather badly.
> 
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: David Airlie <airlied@linux.ie>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

After clarifying on IRC, I think this makes sense. The chance to break userspace
requires a very specific configuration that I don't expect will be common.

Acked-by: Sean Paul <seanpaul@chromium.org>

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 4b0dd20bccb8..bcb78693c4f7 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2673,6 +2673,8 @@ __drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper,
>  
>  	info = fb_helper->fbdev;
>  	info->var.pixclock = 0;
> +	/* don't leak any physical addresses to userspace */
> +	info->flags |= FBINFO_HIDE_SMEM_START;
>  
>  	/* Need to drop locks to avoid recursive deadlock in
>  	 * register_framebuffer. This is ok because the only thing left to do is
> -- 
> 2.18.0
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Patchwork]

== Series Details ==

Series: series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
URL   : https://patchwork.freedesktop.org/series/48541/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9987 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/48541/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9987:

  === IGT changes ===

    ==== Possible regressions ====

    {igt@pm_rpm@module-reload}:
      fi-byt-j1900:       NOTRUN -> DMESG-WARN

    
    ==== Warnings ====

    {igt@kms_psr@primary_page_flip}:
      fi-cnl-psr:         DMESG-WARN -> DMESG-FAIL

    {igt@pm_rpm@module-reload}:
      fi-bsw-n3050:       DMESG-WARN -> DMESG-FAIL

    
== Known issues ==

  Here are the changes found in Patchwork_9987 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      fi-snb-2520m:       PASS -> INCOMPLETE (fdo#103713)

    {igt@pm_rpm@module-reload}:
      fi-cnl-psr:         PASS -> WARN (fdo#107602)

    igt@prime_vgem@basic-fence-flip:
      fi-ilk-650:         PASS -> FAIL (fdo#104008)

    
    ==== Possible fixes ====

    igt@drv_selftest@live_hangcheck:
      {fi-cfl-8109u}:     DMESG-FAIL (fdo#106560) -> PASS

    igt@kms_frontbuffer_tracking@basic:
      {fi-byt-clapper}:   FAIL (fdo#103167) -> PASS

    
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602


== Participating hosts (52 -> 45) ==

  Additional (1): fi-byt-j1900 
  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 fi-bdw-samus 


== Build changes ==

    * Linux: CI_DRM_4695 -> Patchwork_9987

  CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9987: d9f67334c780e3eaedae58d8a87aaa8d3e3574b3 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d9f67334c780 drm/fb: Stop leaking physical address
f9169b2a9d69 fbdev: Add FBINFO_HIDE_SMEM_START flag
795187808141 vt: Remove vc_panic_force_write
61a7e4303234 fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9987/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Patchwork]

== Series Details ==

Series: series starting with [1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
URL   : https://patchwork.freedesktop.org/series/48541/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9987_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

  Here are the changes found in Patchwork_9987_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_ctx_isolation@vcs1-s3:
      shard-kbl:          PASS -> INCOMPLETE (fdo#103665)

    igt@kms_available_modes_crc@available_mode_test_crc:
      shard-kbl:          NOTRUN -> FAIL (fdo#106641)

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)

    
    ==== Possible fixes ====

    igt@gem_ppgtt@blt-vs-render-ctxn:
      shard-kbl:          INCOMPLETE (fdo#106023, fdo#103665) -> PASS +1

    igt@kms_flip@flip-vs-expired-vblank:
      shard-glk:          FAIL (fdo#105363) -> PASS

    igt@kms_setmode@basic:
      shard-kbl:          FAIL (fdo#99912) -> PASS

    
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4695 -> Patchwork_9987

  CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9987: d9f67334c780e3eaedae58d8a87aaa8d3e3574b3 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9987/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Bartlomiej Zolnierkiewicz]

On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> This was only added for the drm's fbdev emulation support, so that it
> would try harder to show the Oops.
> 
> Unfortunately this never really worked reliably, and in practice ended
> up pushing the real Oops off the screen due to plentyfull locking,
> sleep-while-atomic and other issues. So we removed all that support
> from the fbdev emulation a while back. Aside: We've also removed the
> kgdb support, for similar reasons.
> 
> Since it's such a small patch I figured I don't split this up into the
> usual 3-phase removal.
> 
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: David Lechner <david@lechnology.com>
> Cc: nouveau@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Bartlomiej Zolnierkiewicz]

On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> This was only added for the drm's fbdev emulation support, so that it
> would try harder to show the Oops.
> 
> Unfortunately this never really worked reliably, and in practice ended
> up pushing the real Oops off the screen due to plentyfull locking,
> sleep-while-atomic and other issues. So we removed all that support
> from the fbdev emulation a while back. Aside: We've also removed the
> kgdb support, for similar reasons.
> 
> Since it's such a small patch I figured I don't split this up into the
> usual 3-phase removal.
> 
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: David Lechner <david@lechnology.com>
> Cc: nouveau@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Bartlomiej Zolnierkiewicz]

On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> This was only added for the drm's fbdev emulation support, so that it
> would try harder to show the Oops.
> 
> Unfortunately this never really worked reliably, and in practice ended
> up pushing the real Oops off the screen due to plentyfull locking,
> sleep-while-atomic and other issues. So we removed all that support
> from the fbdev emulation a while back. Aside: We've also removed the
> kgdb support, for similar reasons.
> 
> Since it's such a small patch I figured I don't split this up into the
> usual 3-phase removal.
> 
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: David Lechner <david@lechnology.com>
> Cc: nouveau@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> > This was only added for the drm's fbdev emulation support, so that it
> > would try harder to show the Oops.
> > 
> > Unfortunately this never really worked reliably, and in practice ended
> > up pushing the real Oops off the screen due to plentyfull locking,
> > sleep-while-atomic and other issues. So we removed all that support
> > from the fbdev emulation a while back. Aside: We've also removed the
> > kgdb support, for similar reasons.
> > 
> > Since it's such a small patch I figured I don't split this up into the
> > usual 3-phase removal.
> > 
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Hans de Goede <hdegoede@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Cc: David Lechner <david@lechnology.com>
> > Cc: nouveau@lists.freedesktop.org
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Ack for merging the entire series through drm-misc-next?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> > This was only added for the drm's fbdev emulation support, so that it
> > would try harder to show the Oops.
> > 
> > Unfortunately this never really worked reliably, and in practice ended
> > up pushing the real Oops off the screen due to plentyfull locking,
> > sleep-while-atomic and other issues. So we removed all that support
> > from the fbdev emulation a while back. Aside: We've also removed the
> > kgdb support, for similar reasons.
> > 
> > Since it's such a small patch I figured I don't split this up into the
> > usual 3-phase removal.
> > 
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Hans de Goede <hdegoede@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Cc: David Lechner <david@lechnology.com>
> > Cc: nouveau@lists.freedesktop.org
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Ack for merging the entire series through drm-misc-next?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> > This was only added for the drm's fbdev emulation support, so that it
> > would try harder to show the Oops.
> > 
> > Unfortunately this never really worked reliably, and in practice ended
> > up pushing the real Oops off the screen due to plentyfull locking,
> > sleep-while-atomic and other issues. So we removed all that support
> > from the fbdev emulation a while back. Aside: We've also removed the
> > kgdb support, for similar reasons.
> > 
> > Since it's such a small patch I figured I don't split this up into the
> > usual 3-phase removal.
> > 
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Hans de Goede <hdegoede@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Cc: David Lechner <david@lechnology.com>
> > Cc: nouveau@lists.freedesktop.org
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Ack for merging the entire series through drm-misc-next?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Bartlomiej Zolnierkiewicz]

On 09/11/2018 09:42 AM, Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
>>> This was only added for the drm's fbdev emulation support, so that it
>>> would try harder to show the Oops.
>>>
>>> Unfortunately this never really worked reliably, and in practice ended
>>> up pushing the real Oops off the screen due to plentyfull locking,
>>> sleep-while-atomic and other issues. So we removed all that support
>>> from the fbdev emulation a while back. Aside: We've also removed the
>>> kgdb support, for similar reasons.
>>>
>>> Since it's such a small patch I figured I don't split this up into the
>>> usual 3-phase removal.
>>>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Hans de Goede <hdegoede@redhat.com>
>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
>>> Cc: Kees Cook <keescook@chromium.org>
>>> Cc: Thierry Reding <treding@nvidia.com>
>>> Cc: David Lechner <david@lechnology.com>
>>> Cc: nouveau@lists.freedesktop.org
>>> Cc: linux-fbdev@vger.kernel.org
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>
>> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> 
> Ack for merging the entire series through drm-misc-next?

Yes, thanks for taking care of this.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Bartlomiej Zolnierkiewicz]

On 09/11/2018 09:42 AM, Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
>>> This was only added for the drm's fbdev emulation support, so that it
>>> would try harder to show the Oops.
>>>
>>> Unfortunately this never really worked reliably, and in practice ended
>>> up pushing the real Oops off the screen due to plentyfull locking,
>>> sleep-while-atomic and other issues. So we removed all that support
>>> from the fbdev emulation a while back. Aside: We've also removed the
>>> kgdb support, for similar reasons.
>>>
>>> Since it's such a small patch I figured I don't split this up into the
>>> usual 3-phase removal.
>>>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Hans de Goede <hdegoede@redhat.com>
>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
>>> Cc: Kees Cook <keescook@chromium.org>
>>> Cc: Thierry Reding <treding@nvidia.com>
>>> Cc: David Lechner <david@lechnology.com>
>>> Cc: nouveau@lists.freedesktop.org
>>> Cc: linux-fbdev@vger.kernel.org
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>
>> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> 
> Ack for merging the entire series through drm-misc-next?

Yes, thanks for taking care of this.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Bartlomiej Zolnierkiewicz]

On 09/11/2018 09:42 AM, Daniel Vetter wrote:
> On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
>>> This was only added for the drm's fbdev emulation support, so that it
>>> would try harder to show the Oops.
>>>
>>> Unfortunately this never really worked reliably, and in practice ended
>>> up pushing the real Oops off the screen due to plentyfull locking,
>>> sleep-while-atomic and other issues. So we removed all that support
>>> from the fbdev emulation a while back. Aside: We've also removed the
>>> kgdb support, for similar reasons.
>>>
>>> Since it's such a small patch I figured I don't split this up into the
>>> usual 3-phase removal.
>>>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Hans de Goede <hdegoede@redhat.com>
>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
>>> Cc: Kees Cook <keescook@chromium.org>
>>> Cc: Thierry Reding <treding@nvidia.com>
>>> Cc: David Lechner <david@lechnology.com>
>>> Cc: nouveau@lists.freedesktop.org
>>> Cc: linux-fbdev@vger.kernel.org
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>
>> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> 
> Ack for merging the entire series through drm-misc-next?

Yes, thanks for taking care of this.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [Intel-gfx] [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

On Tue, Sep 11, 2018 at 10:47:34AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On 09/11/2018 09:42 AM, Daniel Vetter wrote:
> > On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> >>> This was only added for the drm's fbdev emulation support, so that it
> >>> would try harder to show the Oops.
> >>>
> >>> Unfortunately this never really worked reliably, and in practice ended
> >>> up pushing the real Oops off the screen due to plentyfull locking,
> >>> sleep-while-atomic and other issues. So we removed all that support
> >>> from the fbdev emulation a while back. Aside: We've also removed the
> >>> kgdb support, for similar reasons.
> >>>
> >>> Since it's such a small patch I figured I don't split this up into the
> >>> usual 3-phase removal.
> >>>
> >>> Cc: Ben Skeggs <bskeggs@redhat.com>
> >>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>> Cc: Hans de Goede <hdegoede@redhat.com>
> >>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> >>> Cc: Kees Cook <keescook@chromium.org>
> >>> Cc: Thierry Reding <treding@nvidia.com>
> >>> Cc: David Lechner <david@lechnology.com>
> >>> Cc: nouveau@lists.freedesktop.org
> >>> Cc: linux-fbdev@vger.kernel.org
> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>
> >> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > 
> > Ack for merging the entire series through drm-misc-next?
> 
> Yes, thanks for taking care of this.

Thanks, all merged into drm-misc-next for 4.20.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

On Tue, Sep 11, 2018 at 10:47:34AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On 09/11/2018 09:42 AM, Daniel Vetter wrote:
> > On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> >>> This was only added for the drm's fbdev emulation support, so that it
> >>> would try harder to show the Oops.
> >>>
> >>> Unfortunately this never really worked reliably, and in practice ended
> >>> up pushing the real Oops off the screen due to plentyfull locking,
> >>> sleep-while-atomic and other issues. So we removed all that support
> >>> from the fbdev emulation a while back. Aside: We've also removed the
> >>> kgdb support, for similar reasons.
> >>>
> >>> Since it's such a small patch I figured I don't split this up into the
> >>> usual 3-phase removal.
> >>>
> >>> Cc: Ben Skeggs <bskeggs@redhat.com>
> >>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>> Cc: Hans de Goede <hdegoede@redhat.com>
> >>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> >>> Cc: Kees Cook <keescook@chromium.org>
> >>> Cc: Thierry Reding <treding@nvidia.com>
> >>> Cc: David Lechner <david@lechnology.com>
> >>> Cc: nouveau@lists.freedesktop.org
> >>> Cc: linux-fbdev@vger.kernel.org
> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>
> >> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > 
> > Ack for merging the entire series through drm-misc-next?
> 
> Yes, thanks for taking care of this.

Thanks, all merged into drm-misc-next for 4.20.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag

[Daniel Vetter]

On Tue, Sep 11, 2018 at 10:47:34AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On 09/11/2018 09:42 AM, Daniel Vetter wrote:
> > On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> >>> This was only added for the drm's fbdev emulation support, so that it
> >>> would try harder to show the Oops.
> >>>
> >>> Unfortunately this never really worked reliably, and in practice ended
> >>> up pushing the real Oops off the screen due to plentyfull locking,
> >>> sleep-while-atomic and other issues. So we removed all that support
> >>> from the fbdev emulation a while back. Aside: We've also removed the
> >>> kgdb support, for similar reasons.
> >>>
> >>> Since it's such a small patch I figured I don't split this up into the
> >>> usual 3-phase removal.
> >>>
> >>> Cc: Ben Skeggs <bskeggs@redhat.com>
> >>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>> Cc: Hans de Goede <hdegoede@redhat.com>
> >>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
> >>> Cc: Kees Cook <keescook@chromium.org>
> >>> Cc: Thierry Reding <treding@nvidia.com>
> >>> Cc: David Lechner <david@lechnology.com>
> >>> Cc: nouveau@lists.freedesktop.org
> >>> Cc: linux-fbdev@vger.kernel.org
> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>
> >> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > 
> > Ack for merging the entire series through drm-misc-next?
> 
> Yes, thanks for taking care of this.

Thanks, all merged into drm-misc-next for 4.20.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch