linux-kernel - Re: [PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm

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: <20141203163009.GG11285@n2100.arm.linux.org.uk>
Date:	Wed, 3 Dec 2014 16:30:10 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Philipp Zabel <p.zabel@...gutronix.de>
Cc:	Andy Yan <andy.yan@...k-chips.com>, airlied@...ux.ie,
	heiko@...ech.de, fabio.estevam@...escale.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Shawn Guo <shawn.guo@...aro.org>,
	Josh Boyer <jwboyer@...hat.com>,
	Sean Paul <seanpaul@...omium.org>,
	Inki Dae <inki.dae@...sung.com>,
	Dave Airlie <airlied@...hat.com>,
	Arnd Bergmann <arnd@...db.de>,
	Lucas Stach <l.stach@...gutronix.de>,
	Zubair.Kakakhel@...tec.com, djkurtz@...gle.com, ykk@...k-chips.com,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	devel@...verdev.osuosl.org, devicetree@...r.kernel.org,
	linux-rockchip@...ts.infradead.org, jay.xu@...k-chips.com,
	Pawel Moll <pawel.moll@....com>, mark.yao@...k-chips.com,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	vladimir_zapolskiy@...tor.com, Kumar Gala <galak@...eaurora.org>
Subject: Re: [PATCH v16 03/12] drm: imx: imx-hdmi: convert imx-hdmi to
 drm_bridge mode

On Wed, Dec 03, 2014 at 05:20:15PM +0100, Philipp Zabel wrote:
> Hi Andy,
> 
> It would be better if the bind function would not have to care about
> platform resources, that should be handled in the probe function. I had
> a patch to move them:
> 
> http://lists.freedesktop.org/archives/dri-devel/2014-May/059630.html
> 
> Maybe you could incorporate something like this?

Personally, I hate this idea.  Having a two-layered setup means that
the when the bind() method is called, the state of struct imx_hdmi is
indeterminant.

If it's called immediately from probe, most of the structure will be
zeroed, and only those members initialised by the probe function will
be set to non-zero values.

However, if the HDMI interface has been previously bound, and is
subsequently re-bound, then the structure will most definitely no
longer be in a known state on the second bind() call.

This is fragile.

Now, people have tried to tell me that this isn't fragile, but, I now
have proof that it is as fragile as I fear.  The component helper
doesn't yet have that many users, and already we have one user (okay,
it's not part of the mainline kernel - it's etnaviv) which contained
exactly this kind of bug: it expected its private structures to be
zeroed on the bind() call.

So, I /really/ hate this idea.  If you really want to do this, then
please ensure that the bind() call explicitly zeros the bits of the
struct which aren't initialised by the probe() call, so we know that
the driver will always start off with a known initial state.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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/