linux-kernel - Re: [PATCH v2 9/9] ASoC: tegra_sgtl5000: fix platform name vs. of

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

Message-ID: <1539811978.6233.63.camel@toradex.com>
Date:   Wed, 17 Oct 2018 21:33:00 +0000
From:   Marcel Ziswiler <marcel.ziswiler@...adex.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jonathanh@...dia.com" <jonathanh@...dia.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        "kuninori.morimoto.gx@...esas.com" <kuninori.morimoto.gx@...esas.com>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "perex@...ex.cz" <perex@...ex.cz>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
Subject: Re: [PATCH v2 9/9] ASoC: tegra_sgtl5000: fix platform name vs.
 of_node assignement

On Wed, 2018-10-17 at 20:16 +0100, Mark Brown wrote:
> On Wed, Oct 17, 2018 at 02:28:22PM +0000, Marcel Ziswiler wrote:
> 
> > Some questions:
> > - How exactly are devm allocations supposed to work concerning
> > probe
> > deferrals?
> 
> Probe deferrals are just normal probe errors, any devm_ allocated
> stuff
> gets unwound.

OK, that is where my understanding was weary. So you are saying
anything should really get allocated again upon the second time.

> > - Does or should the platform get cleared during a probe deferral
> > cycle?
> > - If so, why does that not work?
> 
> Is something writing to static data when it should be writing to
> dynamically allocated data?  That's what this sounds like, we
> shouldn't
> be modifying any static data and any data dynamically allocated
> during
> probe ought to be being discarded.

OK, I believe I start to see what you are saying. I guess the bug lays
in soc-core then not properly discarding the platform and the second
time around it is using a stale pointer to that which now of course
points to whatever happens to be there! Let me try a few more things
and I will cook up a proper patch to fix that...

> > - Or is some special implicit probe deferral handling missing in
> > soc-
> > core?
> 
> Like I say a probe deferral is just a normal error.

Yeah, right. Thanks!