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: <20090622181832.771dac03@jbarnes-g45>
Date:	Mon, 22 Jun 2009 18:18:31 -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:04:39 +1000
Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:

> On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote:
> > 
> > On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
> > > 
> > > As far as I can remember, all fbdev operations are done under the
> > > console semaphore.
> > 
> > Yeah, and some of them are horribly broken (ie copying data from
> > user space while doing it - causing horrible things like VC
> > switching latencies and invisible printk's if an oops happens
> > during the op).
> > 
> > Or maybe that got fixed. 
> 
> Well, it does rely on userspace behaving.. ie, no accel ops are done
> by the kernel in KD_GRAPHICS and userspace is -supposed- to switch to
> KD_GRAPHICS before touching the fb.
> 
> In fact, nowdays, we do have the infrastructure to be smart and
> enforce that. IE. Instead of using a boring remap_page_ranges() in
> fb_mmap() we could use a fault handler. When in KD_TEXT, we fail
> them, when in KD_GRAPHICS, we service them, and we
> unmap_mapping_range() when switching. Something like that...
> 
> Dunno how that interacts with the new DRM thingy though.

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.

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