[SRU][Vivid][Wily]drm/fbdev: Return -EBUSY when oopsing

[Zhang, Xiong Y]

BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520427

Issue:
Between upstream kernel v3.19 and v4.2,when Intel SMEP/SMAP protection was triggered by some wild function call or data access, the screen would be frozen and never come back, but the system does not hang.
Generally, an SMEP/SMAP violation should cause the involved process killed, an oops from page fault exception generated to the syslog, and the system survived.
Fix: one commit in 4.3 kernel.
commit c50bfd08d60cefbe1714c4a53b1c325982858549
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date:   Tue Jul 28 13:18:40 2015 +0200

    drm/fbdev: Return -EBUSY when oopsing

    Trying to do anything with kms drivers when oopsing has become a
    failing proposition. But since we can end up in the fbdev code simply
    due to the console unblanking that's done unconditionally just
    removing our panic handler isn't enough. We need to block all fbdev
    callbacks when oopsing.

    There was already one in the blank handler, but it failed silently.
    That makes it impossible for drivers (like i915) who subclass these
    functions to figure this out.

    Instead consistently return -EBUSY so that everyone knows that we
    really don't want to be bothered right now. This also allows us to
    remove a pile of FIXMEs from the i915 fbdev code (since due to the
    failure code they now won't attempt to grab dangerous locks any more).

    Cc: Dave Airlie <airlied at gmail.com>
    Cc: Rodrigo Vivi <rodrigo.vivi at gmail.com>
    Reviewed-by: Rob Clark <robdclark at gmail.com>
Signed-off-by: Daniel Vetter daniel.vetter at intel.com<mailto:daniel.vetter at intel.com>

thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20151127/76690798/attachment.html>