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]
Date:	Thu, 20 Dec 2012 21:30:59 +0100
From:	Thierry Reding <>
To:	Terje Bergström <>
Cc:	Stephen Warren <>,
	"" <>,
	"" <>,
	"" <>,
	Arto Merilainen <>
Subject: Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

On Thu, Dec 20, 2012 at 08:01:43PM +0200, Terje Bergström wrote:
> On 20.12.2012 19:55, Stephen Warren wrote:
> > So it's fine for the tegradrm driver to manipulate the tegradrm
> > (virtual) device's drvdata pointer.
> > 
> > It's not fine for tegradrm to manipulate the drvdata pointer of other
> > devices; the host1x children. The drvdata pointer for other devices is
> > reserved for those devices' driver's use only.
> They're all tegradrm drivers, so tegradrm can manipulate its drvdata.
> The other simple way is global pointer. Let's aim now for a simple
> solution, and if later we find out it causes problems, let's fix it then.

The problem with your proposed solution is that, even any of Stephen's
valid objections aside, it won't work. Once the tegra-drm module is
unloaded, the driver's data will be left in the current state and the
link to the dummy device will be lost.

I don't think waiting for things to fail is the right option here. If we
can make out this problem now, then now is the time to fix it. No

And quite frankly given how all the various host1x components are
interlinked I think having a single function that gets the DRM dummy
device for DRM-related clients isn't that bad.


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists