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 --]
next prev parent 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: linkBe 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.