linux-kernel - Re: [PATCH v1] ASoC: tlv320aic32x4: handle regmap

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]

Date:   Thu, 9 Jan 2020 20:35:47 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Peter Seiderer <ps.report@....net>
Cc:     linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
        Annaliese McDermond <nh6z@...z.net>,
        Takashi Iwai <tiwai@...e.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH v1] ASoC: tlv320aic32x4: handle regmap_read error
 gracefully

On Mon, Jan 06, 2020 at 09:45:34PM +0100, Peter Seiderer wrote:
> On Fri, 27 Dec 2019 22:52:04 +0000, Mark Brown <broonie@...nel.org> wrote:
> > On Fri, Dec 27, 2019 at 04:20:56PM +0100, Peter Seiderer 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.

> Thanks for review..., but a little disagree here, do not know much which
> is more informative than a complete back trace for a division by zero (and
> which is the complete information/starting point for investigating the
> reason therefore) and it would be a pity to loose this valuable information?

Right, some backtrace is definitely often useful for understanding where
things broke and helping people search for problems - it's just
providing the *full* backtrace that can be an issue as a lot of it can
end up being redundant.  As a rule of thumb I'd tend to say that once
you get out of the driver or subsystem you're starting to loose
relevance.  For example with a probe failure like this once you get out
of the driver probe function it almost never matters exactly what the
stack in the device model core is, it's not adding anything and it's
usually more than a screenful that needs to be paged through.  Cutting
that out helps people focus on the bits that matter.

> Maybe I should have added more information about why and how the failing
> regmap_read() call leads to a division by zero?

Any analysis you've done about why things got confused and broken is
definitely good to include!

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