[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200103005424.GF3897@sirena.org.uk>
Date: Fri, 3 Jan 2020 00:54:24 +0000
From: Mark Brown <broonie@...nel.org>
To: Dmitry Osipenko <digetx@...il.com>
Cc: Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Jaroslav Kysela <perex@...ex.cz>,
Bard Liao <bardliao@...ltek.com>,
Oder Chiou <oder_chiou@...ltek.com>,
Liam Girdwood <lgirdwood@...il.com>,
Takashi Iwai <tiwai@...e.com>, linux-tegra@...r.kernel.org,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] ASoC: rt5640: Fix NULL dereference on module unload
On Thu, Jan 02, 2020 at 06:57:14PM +0300, Dmitry Osipenko wrote:
> 31.12.2019 03:17, Mark Brown пишет:
> > 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.
> Yeah, perhaps it's not really useful to have backtrace in the commit's
> description for the case of this patch in particular. But in general it
> is very useful to have backtraces somewhere near the patch such that
> online search engines, like google, could pick it up. I'll move the
> backtrace below --- in v2, thanks.
Right, this is more directed at just pasting in the entire
backtrace (which can be huge with lots of generic bits before the
small number that are relevant) but some edited highlights can
definitely be helpful for search engines and for explaining the
problem. I'll modify what I'm saying there to clarify this.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists