[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ysw2mzhw4pyrxirc@sirena.org.uk>
Date: Mon, 11 Jul 2022 15:41:31 +0100
From: Mark Brown <broonie@...nel.org>
To: Alexandru Elisei <alexandru.elisei@....com>
Cc: lgirdwood@...il.com, perex@...ex.cz, tiwai@...e.com,
heiko@...ech.de, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
alsa-devel@...a-project.org, judyhsiao@...omium.org
Subject: Re: [PATCH] ASoC: rockchip: i2s: Fix NULL pointer dereference when
pinctrl is not found
On Mon, Jul 11, 2022 at 02:40:08PM +0100, Alexandru Elisei wrote:
> On Mon, Jul 11, 2022 at 02:23:59PM +0100, Mark Brown wrote:
> > Please think hard before including complete backtraces in upstream
> > reports, they are very large and contain almost no useful information
> I'm at a loss here. Are you saying that those 4 lines represent a complete
> backtrace and they are very large? Or are you talking about the panic log
> that I've included in the commit message?
I'm talking about the entire log that that was the start of, I deleted
the bulk of it due to the excessive size.
> > relative to their size so often obscure the relevant content in your
> > message. If part of the backtrace is usefully illustrative (it often is
> > for search engines if nothing else) then it's usually better to pull out
> > the relevant sections.
> Would you mind pointing out what you think the relevant sections are? I
> would also find it very useful (for future patches) if you can explain why
> they are relevant, and why those parts you've left out aren't. It's not
> very easy to figure out what is relevant when you're not familiar with a
> subsystem.
It really depends what the information you're trying to convey with the
backtrace is, in general a couple of frames of context might be useful
if there's something interesting about the context from which things
were called since that's the unique bit that people might search for.
For example things like the standard set of generic functions you'd see
when probing a device is rarely going to convey anything meaningful, and
similarly the standard kernel entry backtrace for something triggered
from a system call. The full register state is also commonly not of any
great relevance if it's not illustrating something in the rest of the
message.
If you are just including an entire splat on the off chance that it
might be relevant consider just not including it rather than including
everything.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists