linux-kernel - Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm

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: <20170313125004.yrqranp3sxsfkmfx@sirena.org.uk>
Date:   Mon, 13 Mar 2017 12:50:04 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
        Jaroslav Kysela <perex@...ex.cz>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org
Subject: Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free}

On Fri, Mar 10, 2017 at 04:24:07PM -0800, Brian Norris wrote:
> On Thu, Mar 09, 2017 at 12:09:18PM +0100, Mark Brown wrote:

> > Please think hard before including complete backtraces in upstream
> > reports, they are very large and contain almost no useful information
> > relative to their size so often obscure the relevant content in your
> > message. If part of the backtrace is usefully illustrative then it's
> > usually better to pull out the relevant sections.

> I did think, and I did trim the trace significantly. I believe (or
> believed; maybe incorrectly) that much of the remaining context *was*
> useful, and that it could have answered some of Kuninori's questions, if
> he chose to dig himself. As admitted in the commit message, I don't
> really understand all of the relationships here, so it's hard to
> highlight "only the relevant sections".

Any editing you'd done is really not obvious looking at the trace (the
inclusion of the top of the trace with the pgd and so on which really
need the image to be useful is a bit of a flag here, as is the bit at
the end after the end of the trace).  It's certainly not mentioned or
referenced.  At the very least for probe errors it's generally safe to
cut down to just the driver probe function is being called rather than
showing the entire device model call stack, it's vanishingly rare for
that to be adding anything and it's generally several times deeper than
what the driver is doing.

> I'm sorry that my post did not meet your standards though. Next time
> I'll just post a revert with little context and no attempt to understand
> what actually went wrong.

Providing changes with little context and no conveyed understanding of
exactly what went wrong is a very big part of the reason for complaining
about people just splatting backtraces in and certainly not what I was
asking for, it's sadly common to see a backtrace provided in lieu of any
analysis and it does make the whole thing harder to read.  That would be
even more problematic than what you sent, I wouldn't have applied such a
change at all unless I somehow reverse engineered the analysis.

You do have a reasonable analysis of your change in the first couple of
lines ("Not all platform drivers have pcm_{new,free} callbacks...")
which is why I applied it, it's at least not going to do any harm to
check that there's a function being provided.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)