linux-kernel - Re: [patch 1/3] drm/fb-helper: don't sleep for screen unblank when an oops is in progress

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 22 Jan 2014 09:44:56 +0100
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...ux.ie>, Dave Airlie <airlied@...il.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	"Clark, Rob" <robdclark@...il.com>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/3] drm/fb-helper: don't sleep for screen unblank when an
 oops is in progress

On Tue, Jan 21, 2014 at 11:34 PM,  <akpm@...ux-foundation.org> wrote:
> From: Daniel Vetter <daniel.vetter@...ll.ch>
> Subject: drm/fb-helper: don't sleep for screen unblank when an oops is in progress
>
> Otherwise the system will burn even brighter and worse, leave the user
> wondering what's going on exactly.
>
> Since we already have a panic handler which will (try) to restore the
> entire fbdev console mode, we can just bail out.  Inspired by a patch from
> Konstantin Khlebnikov.  The callchain leading to this, cut&pasted from
> Konstantin's original patch:
>
> callstack:
> panic()
> bust_spinlocks(1)
> unblank_screen()
> vc->vc_sw->con_blank()
> fbcon_blank()
> fb_blank()
> info->fbops->fb_blank()
> drm_fb_helper_blank()
> drm_fb_helper_dpms()
> drm_modeset_lock_all()
> mutex_lock(&dev->mode_config.mutex)
>
> Note that the entire locking in the fb helper around panic/sysrq and kdbg
> is ...  non-existant.  So we have a decent change of blowing up
> everything.  But since reworking this ties in with funny concepts like the
> fbdev notifier chain or the impressive things which happen around
> console_lock while oopsing, I'll leave that as an exercise for braver
> souls than me.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
> Cc: Konstantin Khlebnikov <khlebnikov@...nvz.org>
> Cc: Dave Airlie <airlied@...il.com>
> Reviewed-by: Rob Clark <robdclark@...il.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>

We've merged this twic already in 1b1d5397058f06b and
928c2f0c006bf7f381f58 and then had to take out the superflous hunk
again in ecc7e6f3bb8ad56764

For some oddball reason git/patch _really_ gets confused here and
loves to readd that hunk a few more times (iirc one of my own trees
once even ended up with 3 copies ...). No idea what's going on, but we
can drop this on here ;-)

Or what exactly was the point of this patch submission, I didn't spot
a "dropped from -mm" or similar note, and it doesn't seem to be cc'ed
to lists.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/