linux-kernel - Re: [git pull] drm: previous pull req + 1.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090622190712.4c0ace71@jbarnes-g45>
Date:	Mon, 22 Jun 2009 19:07:12 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Hellström 
	<thomas@...pmail.org>, Dave Airlie <airlied@...ux.ie>,
	Alex Deucher <alexdeucher@...il.com>,
	Andrew Lutomirski <luto@....edu>, dri-devel@...ts.sf.net,
	Jerome Glisse <jglisse@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm: previous pull req + 1.

On Tue, 23 Jun 2009 11:58:44 +1000
Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:

> On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote:
> > I think it could work, but ideally we'd keep the kernel fbcon object
> > pinned, and keep printing into it even while some other gfx app is
> > running.  That way we don't have to dump the whole queue into it
> > when a
> > panic occurs, we can just switch buffers (something like this would
> > also be handy for dual head debugging; one head running your desktop
> > and the other a debug console printing all the messages).  That's
> > slightly more invasive surgery though...  I should have a chance to
> > do something like that as part of the kdb/kms work I'll be doing
> > with Jason.
> > 
> Do we really need that ?
> 
> We can easily repaint (ie, regenerate the fb content from the pseudo
> vgacon image kept by the console layer).
> 
> So if we want the kernel to "take" over, it's reasonably easy to
> make it also repaint the content of the fb.

For just repainting panic messages, probably not.  For the dual head
case I talked about though it would sure be nice...

> How, of course, kicking out usespace with unmap_mapping_ranges() isn't
> going to work well from an oops or something at interrupt time, we
> do need to have a reasonably safe path for these things, which is why
> I believe that sort of emergency printing should be done without
> any acceleration, just basic manual painting in the front buffer...
> 
> Should we even bother changing the mode ? Not sure...

Yeah I don't think we should try to change the mode, unless we really
have to for whatever reason.  fbcon should generally be able to paint
to whatever we have up as long as we set it up properly.

-- 
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/