linux-kernel - Re: [PATCH] vt/console: try harder to print output when panicing

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 23 Jun 2010 13:40:24 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...il.com>, linux-fbdev@...r.kernel.org,
	dri-devel@...ts.sf.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vt/console: try harder to print output when panicing

On Wed, 23 Jun 2010 13:36:37 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Wed, 23 Jun 2010 13:05:47 -0700
> Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> 
> > On Wed, 23 Jun 2010 12:56:05 -0700
> > Andrew Morton <akpm@...ux-foundation.org> wrote:
> > 
> > > On Wed, 23 Jun 2010 13:12:59 +1000
> > > Dave Airlie <airlied@...il.com> wrote:
> > > 
> > > > Jesse's initial patch commit said:
> > > > 
> > > > "At panic time (i.e. when oops_in_progress is set) we should try a bit
> > > > harder to update the screen and make sure output gets to the VT, since
> > > > some drivers are capable of flipping back to it.
> > > > 
> > > > So make sure we try to unblank and update the display if called from a
> > > > panic context."
> > > > 
> > > > I've enhanced this to add a flag to the vc that console layer can set
> > > > to indicate they want this behaviour to occur. This also adds support
> > > > to fbcon for that flag and adds an fb flag for drivers to indicate
> > > > they want to use the support. It enables this for KMS drivers.
> > > 
> > > Interesting.  Getting real oops traces from machines running X will
> > > make Rusty happy, and that's what we're all here for.
> > > 
> > > How well does this all work?  How reliable is it?  What's the success rate?
> > > 
> > > 
> > > 
> > > What's the downside here?  After all, not all oopses are catastrophic -
> > > sometimes the machine will go blurt and keep running so the user can
> > > take a look in the logs then perform an orderly reboot, etc.  As I
> > > understand it, those non-catastrophic oopses will now flip the machine
> > > from X and into the vt display, yes?  Can the user get it back to X
> > > mode?
> > 
> > No, we'll only flip from the panic notifier chain.
> 
> So we still don't get to see the output from BUGs and random oopses?  I
> don't think panics are all that common.

No, BUG() ends up in panic iirc by doing an bad pointer ref which
should fault and panic. Random oopses won't show up though (but they're
not supposed to be fatal and can be seen in the log).

> So am I correct in believing that if a user is getting invisible-oopses
> then he can set /proc/sys/kernel/panic_on_oops, and then the oops
> should be visible?

Yep.

> (Shouldn't all this stuff be explained in the changlog?)

Maybe?  Linux oops/panic handling is pretty ad-hoc, a separate document
would probably be best.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/