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;
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;
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
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.
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;
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;} 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
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
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
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
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
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
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
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
dri-devel@lists.freedesktop.org
-
Bartlomiej Zolnierkiewicz -
Daniel Vetter -
Daniel Vetter -
Greg Kroah-Hartman -
Sean Paul