All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, Jaroslav Kysela <perex@perex.cz>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Takashi Iwai <tiwai@suse.com>,
	alsa-devel@alsa-project.org
Subject: Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free}
Date: Mon, 13 Mar 2017 12:50:04 +0000	[thread overview]
Message-ID: <20170313125004.yrqranp3sxsfkmfx@sirena.org.uk> (raw)
In-Reply-To: <20170311002406.GA4586@google.com>

[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: alsa-devel@alsa-project.org,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.com>
Subject: Re: [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free}
Date: Mon, 13 Mar 2017 12:50:04 +0000	[thread overview]
Message-ID: <20170313125004.yrqranp3sxsfkmfx@sirena.org.uk> (raw)
In-Reply-To: <20170311002406.GA4586@google.com>


[-- Attachment #1.1: Type: text/plain, Size: 2388 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2017-03-13 12:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-08 23:18 [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free} Brian Norris
2017-03-08 23:18 ` Brian Norris
2017-03-09  0:17 ` Kuninori Morimoto
2017-03-09  0:17   ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free} Kuninori Morimoto
2017-03-09  0:21   ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free} Brian Norris
2017-03-09  0:53     ` Kuninori Morimoto
2017-03-09  0:53       ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free} Kuninori Morimoto
2017-03-11  0:39       ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free} Brian Norris
2017-03-13  3:46         ` Kuninori Morimoto
2017-03-13  3:46           ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free} Kuninori Morimoto
2017-03-13 21:41           ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free} Brian Norris
2017-03-14  1:07             ` Kuninori Morimoto
2017-03-14  1:07               ` Kuninori Morimoto
2017-03-09 11:09 ` Mark Brown
2017-03-09 11:09   ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free} Mark Brown
2017-03-11  0:24   ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free} Brian Norris
2017-03-13 12:50     ` Mark Brown [this message]
2017-03-13 12:50       ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free} Mark Brown
2017-03-13 21:52       ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new,free} Brian Norris
2017-03-14 13:36         ` Mark Brown
2017-03-14 13:36           ` [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free} Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170313125004.yrqranp3sxsfkmfx@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=briannorris@chromium.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.