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: <1245715063.4017.12.camel@pasglop>
Date:	Tue, 23 Jun 2009 09:57:43 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Lutomirski <luto@....edu>, Dave Airlie <airlied@...ux.ie>,
	dri-devel@...ts.sf.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jerome Glisse <jglisse@...hat.com>,
	Alex Deucher <alexdeucher@...il.com>
Subject: Re: [git pull] drm: previous pull req + 1.

On Sun, 2009-06-21 at 12:47 -0700, Linus Torvalds wrote:
> 
> What *has* changed is that we have a newradeon driver, and it looks
> like 
> that new radeon driver is crap, and does this:
> 
>         info->fix.smem_start = (unsigned long)fbptr;
> 
> which is totally screwed up. It assigns a _virtual_ address to that 
> "smem_start" thing, even though it should be a physical one. 

BTW. While we are at it that there's an additional problem (old fbdev
design issue) with that which is smem_start is an unsigned long, which
is too small to hold a physical address on a variety of 32-bit
platforms.

Dave, what about we split those structures into a "sane" in-kernel one
and a "user visible" one ? At that point, we can create new saner
variants of the user ones using separate ioctls ...

> I don't know the radeon driver, so I don't know where to find the
> physical  address.  It's also possible that there is no good single
> physical  address, and the radeon driver should implement a "fb_mmap"
> function.
> 
> Does this patch make the warning and the oops at least go away?
> Obviously  it won't result in a working frame buffer, but that's a
> separate issue

There should be a physical address but it's nasty to let userspace map
it directly without using the DRM for access control, not sure what
David plans here, but it may need surface control set properly etc...

Dave ? Should the fbdev mmap go down the DRM object map path or
similar ?

Cheers,
Ben.

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